Working With Services In Kubernetes

Working with services in Kubernetes

It is not only sufficient to have skilled individuals who know their job better, how these talented individuals communicate and help each other out as a team player which makes productive work happen, is what matters the most.

In a similar fashion, deploying different types of front-end and backend applications on the server is not sufficient, it is how these applications will exchange data with each other is what makes the client server-based ecosystem function effectively. In Kubernetes, we deploy all kinds of Pods which can be concerned with backend, front-end, and external data sources These logical sets of Pods are exposed to the external world to be discovered by Kubernetes services.

So with this basic understanding let’s define

What Is Kubernetes Service?

In Kubernetes, a Service is an abstraction that defines a logical set of Pods and a policy by which to access them, this kind of patterns is also sometimes called a micro-service.

Each pod in the Kubernetes cluster has got the cluster IP and Network IP, but these pods cannot be directly accessed externally as those IPs are not exposed outside the cluster without a Service. Kubernetes services allow our applications to be exposed to receive external world traffic, it does this in three different ways, let’s see what ar those methodologies

How Kubernetes Services Are Exposed?

To understand how a service is exposed to the outer world so that outer world solutions can connect with applications lying as a pod in the cluster node. Let’s me give you a visual explanation below

Fig 1.0 Internal POD being connected to eternal mobile app via kubernetes service

Explanation:

As can be seen in fig 1.0, our mobile app is lying outside the cluster, wants to connect with the backend application pod. When it comes to the cluster-level pod, every pod has its own network IP, which in the case of the backend pod here is: 10.144.10.3. Now for an external mobile app to communicate with this pod, it can’t directly make an IP call to 10.144.10.3, it has to come up with some other mechanism.

Here, our external app is lying on the same network on which our Node is also available, so the only way our external app can connect is by this network IP where cluster node is also accessible. So in order to make our mobile app talk to the backend pod, Kubernetes has a service module that is exposed to the outer world and is listening to the node port 30038. This service is connected to POD level Network IP via pod level port.

Thus mobile app will make a curl request using node-level network IP and connecting to Node port 30038, as shown below

$curl>http://192/168.1.4:30038

This is one way our Kubernetes service enables an external level connection for the applications pods lying inside the Nodes.

Now it's time to get into the depth of what are the ways in which Kubernetes exposes the services, for which we need to understand what are the services types and how these services are defined in the pod definition.

Types of Kubernetes Service:

Kubernetes Services can be exposed in different ways by specifying a type in the ServiceSpec: which are

• ClusterIP
• NodePort
• LoadBalancer

NodePort Kubernetes Service:

In our fig 1.0 explanation, we saw a glimpse of how Node Port is used to expose the pod to the outer mobile app. Let us get into the details of the same by revisiting fig 1.0 below:

Fig 2.0 : Ports in Cluster Node

Explanation Fig 2.0:

There can be seen 3 different ports

• NodePort: 30038
• Service Port : 80
• Target Port(Pod level): 80

NodePort :

Kubernetes service of type NodePort, which exposes the application pod on a port across each of our cluster nodes, It is a kind of open port available on every Kubernetes nodes of the cluster and it is responsible to route all the inbound traffic towards the service lying inside the nodes.

A NodePort is an open port on every node of your cluster. Kubernetes transparently routes incoming traffic on the NodePort, to your service, even if your application is running on a different node.

NodePort is assigned from a pool of cluster-configured NodePort ranges which typically lies in the range of 30000–32767.

Putting NodePort To Work :

Let’s create a service and define NodePort to understand how it works in Kubernetes to expose our services

Let’s create service-demo.yaml:(Referring our Fig 2.0)

apiVersion: v1
kind: Service
metadata:
  name: my-service-demo
spec:
  type: NodePort
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30038

Remember!

Out of all ports, parameter only mandatory field is port, so if we don’t provide targetPort, it will by defualt consider the port no defined in port section. And If we don’t specify the nodePort field, any free nodePort value between 30000- 32767 will be allocated by Kubernetes.

What do you think? What is missing in the service definition file above? Well if you carefully examine you will see that there is no mentioning of which pod to map the target port to, our service has not been allocated which pod to connect to on the given target port, so in order to enable it, let’s write a simple pod file below and map it with service-demo.yaml, file

my-test-pod.yaml file:

apiVersion: v1
kind: Pod
metadata:
  name: my-test-pod
  labels:
    app: my-test-pod 
    type: mobile-front-end-app  
spec:
  containers:
  - name: nginx-container
    image: nginx

Now we have a pod, with the label: my-test-pod, let’s map this label to our service definition file to create our services, in order to do so we will have to define a new parameter called node Selector, in the spec section, and pull the label parameter and place it under selector field

my-test-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-service-demo
spec:
  type: NodePort
  
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30038
  
  selector:
    
      name: my-test-pod 
      type: mobile-front-end-app

This way we have now connected the service to the pod.

So let’s first create a pod file as defined in our, my-test-pod.yaml file above

• Create my-test-pod.yaml using cat command
• Copy-paste the YAML code defined my-test-pod.yaml file
• create the pod using the command below

$ kubectl apply -f test-pod.yaml

Output: You can see from the highlighted string, which shows that my-test-pod has been created successfully and running.

Now that we have our pod file up and running, it’s time to create service as defined in our “my-test-service.yaml file “

• create my-test-service.yaml using cat command
• copy paste the yaml code defined in my-test-service.yaml file
• create the pod using the command below

$ kubectl create -f my-test-service.yaml

See the output below:

The string highlighted shows clearly that our service has been created as NodePort type and has a cluster IP: 10.111.50.10(this will differ in your case), this service is running on Node Port: 30038

So now that service has been deployed let’s access the Nginx web app which we deployed in our pod using the NodePort: 30038

For that first get the IP address of your minikube cluster :

$ minikube IP 

for me, IP address is: 192.168.99.102

so to access the Nginx web app, type http://192.168.99.102:30038

you will see the following output:

This shows that the pod deployed in the cluster node is being accessed by our service exposed by NodePort: 30038.

What’s Next?

We will look into other types of services

• Cluster IP
• Load Balancer

and will see how they work to expose our node level application to the outer world