Understanding Services in Kubernetes with Examples!

Table of contents

Reading Time: 4 minutes

What is Service?

Service is an abstraction level that Kubernetes uses to make a deployed application accessible from the internal and external of the cluster.

Think time…

Imagine that, you have been asked to deploy a web app
How front-end web app is exposed to the outside world ?
In what way will we connect front-end with back-end and database?
How do we resolve Pod IP changes ,when they die?

Stick here for a while and you will be able to answer these questions!

Why Services?

Pods are the most basic entities inside our Kubernetes cluster. We can host our applications inside the pods with the help of containers. A Service inside the Kubernetes cluster acts as a layer above the pods. Communication between different pods in a cluster can be enabled with the help of Services.

Consider the following example: we created a web application, our application has groups of pods running various sections such as first group for serving front-end, second group for running back-end processes and a third group for connecting to external data source.

Therefore, services enables connectivity between these group of pods. Services helps front-end apps to be made available to end users, facilitates communication between back-end pods and front-end pods and also helps in establishing connectivity to an external data source.

Which pods to select?

In the spec part of the service yml file we define a “selector”. This is where we inform the service which pods will come under its control. Any pod that has a label “app=nginx-appp” will be handled by our service.

Types of Services in Kubernetes

Kubernetes supports three different types of services:

Cluster IP
NodePort
Load Balancer

Cluster IP vs NodePort vs LoadBalancer

Cluster IP Service

ClusterIP service is the default Kubernetes service. Kubernetes will assign an internal IP address to your service. This IP address is reachable only from inside the cluster and can only be accessed by other pods in that cluster. Therefore we use this type of service when we want to expose a service to other pods within the same cluster.

With the help of above diagram we can clearly see that an application App2 can internally communicate with the application App1 via the Cluster IP.

The YAML for a ClusterIP service looks like this:

apiVersion: v1
kind: Service
metadata:
    name: my-clusterIP-service
spec:
    selector:
        app: nginx-appp
    type: ClusterIP
    ports:
    - name: http
      port: 80
      targetPort: 80 
      protocol: TCP

NodePort Service

A NodePort service is the most easiest way to get the external traffic directly to your service. NodePort, as the name implies, opens a specific port on all the Nodes inside the cluster. So, any traffic that comes to this port is forwarded to the service.

With the help of above picture we can clearly see that external traffic can arrive on the IP of one of the three nodes on port 30036, it will arrive to the NodePort service and then that will forward the traffic to a specific Pod.

The YAML for a NodePort service looks like this:

apiVersion: v1
kind: Service
metadata:
    name: my-nodeport-service
spec:
    selector:
        app: nginx-appp
    type: NodePort
    ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30036
      protocol: TCP

In the YAML file, the service will map the HTTP port 80 to the container port 80 (targetPort). So, External users can access it using IP:PORT, where IP is one of the Worker Node (VMs) IP and PORT is the nodePort. If we don’t specify the nodePort field then Kubernetes will assign a value to it.

LoadBalancer Service

A LoadBalancer service is the standard way to expose a service to the internet. This service type works when you are using a cloud provider to host your Kubernetes cluster.

All the traffic on the port which you specify will be forwarded to the service. There is no filtering, no routing, etc. Therefore you can send almost any kind of traffic to it, like HTTP, TCP, UDP, Websockets, gRPC, or whatever.

The big cons of having a LoadBalancer as a service is that each service which we expose with a LoadBalancer will get its own IP address so it can get expensive.

Kubernetes - LoadBalancer Service — LoadBalancer Service Workflow

The YAML for a LoadBalancer service looks like this:

apiVersion: v1
kind: Service
metadata:
  name: loadbalancerservice
  labels:
    app: nginx-appp
spec:
  selector:
    app: nginx-appp
  type: LoadBalancer
  ports:
   - nodePort: 31001
     targetPort: 80
     port: 80

Conclusion

In conclusion, we discussed why we use services in kubernetes, how exactly pods are mapped with the service and about different type of services offered by the kubernetes. I hope it’s enough to give you a head start to services in K8s!

“That’s all folks!”