Kubernetes Service Types with Diagrams

Hey guys, thanks for taking the time to read the following blog post. I hope it will benefit you in your Kubernetes learning path and help you create a positive impact in your organization.

Let's get into it…

One of the core features that we enjoy when using Kubernetes is auto discovery. Kubernetes implements a logical entity called service, which provides a single entry for a set of pods.

By nature, pods are unstable, and service acts as a stable endpoint that can be used to reference underlying pods he is associated with. The kubernetes service is able to load balance requests to the pods and has a number of implementations that we need to be aware of.

In the post, we will cover the following:

How service associates with a set of pods
Kubernetes Service types
1. ClusterIP
2. NodePort
3. LoadBalancer
4. External Name
Headless Service

How service associates with a set of pods

The association with the set of pods is being implemented with labels in the pods and selectors in the Service. The service forwards traffic from its exposed port to a target port in the pods. All pods associated with a service are listed under endpointSlice resource. For every 100 pods that are associated with a service, kubernetes will create another endpointSlice and add the new pods over there.

For example, let’s review the following YAML definition:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: proxy
spec:
 containers:
 - name: nginx
   image: nginx:stable
   ports:
     - containerPort: 80
       name: http-web-svc
---
apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
  clusterIP: None
  selector:
    app: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort

In the Pod YAML defination, we will highlight the following:

spec:labels - defines a label on the pod in our example the label is app:proxy

spec:containers[0]:ports[0]:containerPort - The port on which the pod will accept traffic. In the example, it’s port 80

spec:containers[0]:ports[0]:Name - The name of the port which can be referred in the service definition. In our example it’s http-web-svc

In the Service YAML defination, we will highlight the following:

spec:Selector - identify which pods to associate with by their labels. In the example, the selector is app:proxy
spec:ports[0]:port - The port on which the service accepts traffic on. In the example it’s port 80

spec:ports[0]:targetPort - The name or port number in the pods. In our example its http-web-svc

Although we haven’t created the endpointSlice object, kubernetes will create the endpointSlice automaticly and associate the relevant pods with it.

ClusterIP

ClusterIP is the default service type. The service is being provided with cluster IP, and his underlying pods can be accessed only from within the cluster.

!Tip! In case you want to access endpoints from within your local pc, you can execute the following command

Manifest Example:

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
  selector:
    app: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort

NodePort

NodePort service type builds upon the clusterIP service type. With NodePort Kubernetes, the service is exposed to a static port on each node's IP, making the service accessible outside the cluster. The static ports that are used by kubernetes on each node are between the range of 30000-32767.

This type of service allows external users to reach specific applications within the cluster from any node that is associated with the cluster. Kube-proxy, behind the scenes, implements forwarding rules that are responsible for forwarding the traffic to the pods.

Manifest example:

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
  type: NodePort
  selector:
    app: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc
    nodePort: 30000

LoadBalancer

The loadbalancer service type builds upon NodePort. The following service type is dependent on external load balancer providers like F5, AWS, and so on to create the relevant load balancer for it. This type simplifies exposing applications to external traffic because it’s a static resource that exposes nodes that can be removed and joined to the cluster.

Note: In cloud providers such as AWS, we can reference directly to the pods because they have their own IP provision from the VPC CIDR range.

Manifest example:

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort

ExternalName

The ExternalName service type is a unique approach to service discovery in kubernetes. Rather than route traffic to internal pod endpoints, ExternalName redirects service requests to a specified external DNS name. This type allows pods in the cluster to access external resources in a native Kubernetes way.

Manifest example:

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
  type: ExternalName
  externalName

Headless Service

Headless service is a service type clusterIP in which we specify “None” for its clusterIP field. Headless service is used for scenarios where you want to access pods via DNS names directly. It’s perfectly suited for stateful applications such as Postgres and other a like where there is need to be pod to pod communication based on stable dns entries.

Example Manifest:

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
  clusterIP: None
  selector:
    app: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort