Headless services concept in Kubernetes - Commands & Configuration

Introduction

Sometimes you want to connect directly to individual pods in Kubernetes instead of through a load balancer. Headless services let you do this by removing the usual IP address and load balancing, so you get the real pod addresses.

When you want to discover and connect to each pod directly for custom routing or stateful apps.

When you run databases or caches that need to talk to specific pods instead of any pod.

When you want to manage your own load balancing outside Kubernetes.

When you need to use StatefulSets that require stable network IDs for each pod.

When you want to expose pods without a cluster IP to reduce network overhead.

Config File - headless-service.yaml

headless-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
  namespace: default
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

This YAML defines a headless service named my-headless-service in the default namespace.

The key part is clusterIP: None, which disables the usual cluster IP and load balancing.

The selector matches pods with label app: my-app, so this service tracks those pods.

The ports section exposes port 80 on the service, forwarding to port 8080 on the pods.

Commands

This command creates the headless service in Kubernetes using the YAML file. It sets up the service without a cluster IP.

Terminal

kubectl apply -f headless-service.yaml

Expected Output

service/my-headless-service created

This command checks the service details to confirm it is headless by showing clusterIP as None.

Terminal

kubectl get svc my-headless-service

Expected Output

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE

my-headless-service  ClusterIP   None         <none>        80/TCP    10s

This command shows the actual pod IP addresses that the headless service points to, allowing direct pod access.

Terminal

kubectl get endpoints my-headless-service

Expected Output

NAME                 ENDPOINTS                         AGE

my-headless-service  10.244.1.5:8080,10.244.1.6:8080  15s

Key Concept

If you remember nothing else from this pattern, remember: setting clusterIP to None creates a headless service that exposes pod IPs directly without load balancing.

Common Mistakes

Not setting clusterIP to None in the service spec.

The service will get a normal cluster IP and load balance traffic, not exposing individual pod IPs.

Always include 'clusterIP: None' in the service spec to make it headless.

Using a selector that does not match any pods.

The service will have no endpoints, so no pod IPs will be exposed.

Ensure the selector labels exactly match the pods you want to expose.

Summary

Create a service YAML with 'clusterIP: None' to make it headless.

Apply the YAML to create the headless service in Kubernetes.

Use 'kubectl get endpoints' to see the pod IPs exposed by the headless service.

Practice

1. What is the main purpose of a headless service in Kubernetes?

easy

A. To connect directly to pods without using a load balancer

B. To expose a service externally via a cloud provider

C. To automatically scale pods based on traffic

D. To create a persistent volume for storage

Solution

1. Step 1: Understand service types in Kubernetes

   Regular services use a load balancer or cluster IP to route traffic to pods.

2. Step 2: Identify the role of headless services

   Headless services remove the cluster IP, allowing direct pod connections without load balancing.

3. Final Answer:

   To connect directly to pods without using a load balancer -> Option A

4. Quick Check:

   Headless service = direct pod connection [OK]

Hint: Headless means no cluster IP, direct pod access [OK]

Common Mistakes:

• Confusing headless service with external load balancer
• Thinking headless services scale pods automatically
• Assuming headless services provide storage

2. Which YAML field must be set to create a headless service in Kubernetes?

easy

A. type: Headless

B. externalTrafficPolicy: Local

C. clusterIP: None

D. loadBalancerIP: 0.0.0.0

Solution

1. Step 1: Recall the service spec for headless services

   Headless services are defined by setting clusterIP to None in the service spec.

2. Step 2: Check other options for correctness

   type: Headless is invalid; loadBalancerIP and externalTrafficPolicy relate to load balancers, not headless services.

3. Final Answer:

   clusterIP: None -> Option C

4. Quick Check:

   clusterIP None = headless service [OK]

Hint: Set clusterIP to None for headless service [OK]

Common Mistakes:

• Using type: Headless instead of clusterIP: None
• Confusing loadBalancerIP with clusterIP
• Setting externalTrafficPolicy for headless service

3. Given this service YAML snippet, what will be the DNS behavior?

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

medium

A. DNS returns multiple pod IPs matching the selector

B. DNS returns a single IP of a load balancer

C. DNS returns no IP because clusterIP is None

D. DNS returns the external IP of the cluster

Solution

1. Step 1: Analyze clusterIP: None effect on DNS

   With clusterIP set to None, DNS returns the IPs of all pods matching the selector, not a single IP.

2. Step 2: Understand DNS response for headless services

   DNS returns multiple A records, one per pod IP, enabling direct pod access.

3. Final Answer:

   DNS returns multiple pod IPs matching the selector -> Option A

4. Quick Check:

   Headless DNS = multiple pod IPs [OK]

Hint: Headless service DNS returns pod IPs, not one IP [OK]

Common Mistakes:

• Thinking DNS returns a load balancer IP
• Assuming no IP is returned when clusterIP is None
• Confusing external IP with pod IPs

4. You created a headless service but your pods are not reachable via DNS. What is a likely cause?

medium

A. You forgot to set clusterIP: None in the service spec

B. Your pods do not have matching labels for the service selector

C. You used type: LoadBalancer instead of clusterIP: None

D. You exposed the service with NodePort instead of ClusterIP

Solution

1. Step 1: Check service selector and pod labels

   If pods do not match the service selector labels, the service cannot route traffic to them.

2. Step 2: Verify clusterIP and service type correctness

   clusterIP: None is required for headless service; type LoadBalancer or NodePort changes service behavior but won't cause DNS pod reachability issues if labels match.

3. Final Answer:

   Your pods do not have matching labels for the service selector -> Option B

4. Quick Check:

   Selector mismatch = pods unreachable [OK]

Hint: Check pod labels match service selector [OK]

Common Mistakes:

• Ignoring pod labels and selector mismatch
• Confusing service type with label issues
• Assuming NodePort affects headless DNS reachability

5. You want to deploy a stateful app that requires direct pod access and custom load balancing. Which Kubernetes service setup is best?

hard

A. Create a ClusterIP service with externalTrafficPolicy set to Local

B. Use a LoadBalancer service with multiple replicas

C. Use a NodePort service with a Deployment

D. Create a headless service with clusterIP: None and use StatefulSet pods

Solution

1. Step 1: Understand requirements for stateful apps

   Stateful apps often need stable network IDs and direct pod access for custom load balancing.

2. Step 2: Match Kubernetes service type to requirements

   Headless services (clusterIP: None) combined with StatefulSets provide stable pod identities and direct access.

3. Step 3: Evaluate other options

   LoadBalancer and NodePort services use load balancing and do not provide stable pod DNS; ClusterIP with externalTrafficPolicy affects routing but not pod identity.

4. Final Answer:

   Create a headless service with clusterIP: None and use StatefulSet pods -> Option D

5. Quick Check:

   Stateful + headless + StatefulSet = best fit [OK]

Hint: StatefulSet + headless service = stable pod access [OK]

Common Mistakes:

• Using LoadBalancer for stateful direct pod access
• Confusing NodePort with headless service benefits
• Ignoring StatefulSet for stable pod identities