Kubernetes is a powerful platform for managing containerized applications. And one of its crucial components is the Service object, which enables communication (networking) between different parts of an application.

In this blog post, we will dive into the concept of headless Services. We will find out what they are, how they work, and some of their common use cases. So, let's jump right in!

What Is Kubernetes Headless Service?

In Kubernetes, Services provide a stable IP address for clients to connect to Pods. A client makes a request to the Service. Then the Service forwards that request to one of the Pods associated with it. The client does not know which Pod it is connected to, nor does it care about it.

But what if the client wants to see the Pods’ IP addresses, so that it has complete control over which Pod(s) it can connect to? In such cases, Kubernetes provides the concept of headless Services.

A Kubernetes headless Service allows a client to connect to whichever Pod it prefers, directly. It doesn’t route the client request like a regular Service does.

Next, let’s explore how to create such a Service and understand what actually happens behind the scenes.

How to Configure a Kubernetes Headless Service?

Here is an example of a YAML file for a regular Kubernetes Service:

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  selector:
    app: my-web-app
  ports:
    port: 80
    targetPort: 8080

This creates a ClusterIP Service called "my-web-app" that routes incoming traffic to Pods that have the label "app: my-web-app". The Service listens on port 80 and forwards traffic to the Pods' port 8080.

Note: The default Service type in Kubernetes, if no type is specified, is "ClusterIP".

To make this Service headless, we need to add the "clusterIP" field and set its value to "None".

apiVersion: v1
kind: Service
metadata:
  name: my-web-app
spec:
  selector:
    app: my-web-app
  clusterIP: None
  ports:
    port: 80
    targetPort: 8080

This YAML configuration creates a headless Service that represents Pods that have the label "app: my-web-app".

The Service does not have a cluster IP, which means that it does not load balance traffic across any Pods. Instead of forwarding traffic, the Service behaves differently.

When a client sends a request to a headless Service, it will get back a list of all Pods that this Service represents (in this case, the ones with the label "all: my-web-app"). Basically, the Service now lets the client decide on how it wants to connect to the Pods.

In a simplified form, the ClusterIP Service tells the client "Let me take care of routing that request for you." In contrast, a headless Service says "Here is a list of all the Pods that I know about and their IP addresses. Send and route your network requests however you want."

Try the Kubernetes Services Lab for free

3 Common Use Cases of Kubernetes Headless Service

Here are the 3 most common use cases of Kubernetes headless Service:

Stateful Applications

Stateful applications are programs or software that need to remember information or data (known as "state") over time. Here's one example:

Certain operations can progress slowly. And we'd want partial progress to be preserved, at least until the entire job is finished. This is a scenario where we need to remember "state".

Imagine a client using Pod33 out of 100 to render a 3D image. In case the client gets disconnected, we wouldn't want it to lose progress. If it rendered 60% of the image, we'd want that client/program to continue from 60% progress when it reconnects.

With a temporary network hiccup, this reconnection can happen in mere seconds. If progress is temporarily saved on Pod33, we need to make sure the client reconnects to the same Pod.

A typical ClusterIP Service might forward the client connection to a random Pod, say 48. And the in-progress render operation would not be found there. With the help of a headless Service, we can make sure a certain client lands on the same Pod33, if they have work in progress on that Pod.

Advanced Health Checks

When a regular Service redirects an incoming request to a Pod, it has to make sure the Pod is healthy (working correctly). These health checks are usually rather basic.

For example, for a database Pod, it might only check "Does this database return an answer when queried?" If it does, it is considered healthy. But what if 10 Pods return an answer in 0.1 seconds and one Pod returns the answer in 3 seconds? That's 30 times slower. It's a signal that the Pod has an issue. But the Service might not catch that. And any client connecting to that Pod will get answers very slowly. This can lead to very poor user experience for those unlucky to have requests served by that Pod.

With a headless Service, a client app can interact with Pods directly. And it can periodically check for the ones that perform best (provide super fast answers). It can then avoid using slow Pods, leading to a much better user experience.

Custom Load-Balancing Logic

A ClusterIP Service does very simple load balancing. For every request it gets, it usually redirects it to a Pod it picks randomly.

With a headless Service, however, a client app can actually "see" all the Pods that are available. And it can implement more advanced load-balancing if programmed to do so. The load-balancing would be done by the app, instead of the Service.

For example, it could load balance based on how "heavy" the request is. If the request needs to process 10MB of data, it can send it to a Pod hosted on a more powerful worker node (server). If the request needs to process only 1MB, it can send it to a Pod hosted on a less powerful worker node.

Conclusion

To sum up, a headless Service in Kubernetes is a useful feature that provides more control over communication with the Pods. This makes it suitable for stateful applications and other use cases.

If you're looking to learn more about Kubernetes, be sure to check out our courses:

• Certified Kubernetes Administrator
• Certified Kubernetes Application Developer