Headless services concept in Kubernetes - Step-by-Step Execution

Process Flow - Headless services concept

Create Headless Service

↓

No Cluster IP assigned

↓

DNS returns Pod IPs directly

↓

Clients connect directly to Pods

↓

Pod IPs update as Pods change

↓

Service discovery without load balancer

This flow shows how a headless service skips assigning a cluster IP and returns pod IPs directly for clients to connect.

Execution Sample

Kubernetes

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

Defines a headless service with no cluster IP that selects pods labeled 'app: myapp' on port 80.

Process Table

Step	Action	Result	Effect
1	Create Service with clusterIP: None	No cluster IP assigned	Service is headless
2	Pods with label app=myapp start	Pods get IPs assigned	Pods ready to receive traffic
3	DNS query for service name	DNS returns list of pod IPs	Clients get direct pod IPs
4	Client connects to one pod IP	Connection established directly	Bypasses load balancer
5	Pod IP changes or pods scale	DNS updates with new pod IPs	Clients get updated pod list
6	Service deleted	No DNS entries for service	Connections stop
Exit	No cluster IP means no virtual IP routing	Clients connect directly to pods	Headless service ends

💡 Headless service stops when deleted or no pods match selector

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
clusterIP	None	None	None	None	None
Pod IPs	None	10.1.1.5, 10.1.1.6	10.1.1.5, 10.1.1.6	10.1.1.5, 10.1.1.7	None
DNS Response	None	None	10.1.1.5, 10.1.1.6	10.1.1.5, 10.1.1.7	None

Key Moments - 3 Insights

Why does the headless service have clusterIP set to None?

Setting clusterIP to None disables the virtual IP, so DNS returns pod IPs directly as shown in execution_table step 1 and 3.

How do clients find pods if there is no load balancer?

Clients get pod IPs directly from DNS (step 3), then connect to pods without a load balancer (step 4).

What happens when pods scale up or down?

DNS updates with new pod IPs (step 5), so clients always get current pod IPs.

Visual Quiz - 3 Questions

Look at the execution table, what is the DNS response at step 3?

A Cluster IP address

B List of pod IPs

C Empty response

D Service name only

💡 Hint

Check the 'DNS Response' variable in variable_tracker after step 3

At which step does the client connect directly to a pod IP?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' and 'Effect' columns in execution_table for direct connection

If clusterIP was not set to None, what would change in the execution?

A DNS would return cluster IP instead of pod IPs

B Pods would not get IPs

C Clients would connect directly to pods

D Service would be deleted automatically

💡 Hint

Refer to execution_table step 1 and variable_tracker clusterIP value

Concept Snapshot

Headless Service in Kubernetes:
- Set clusterIP: None to disable virtual IP
- DNS returns pod IPs directly
- Clients connect directly to pods
- Useful for stateful or direct pod access
- No load balancer or proxy involved

Full Transcript

A headless service in Kubernetes is created by setting clusterIP to None. This means no virtual IP is assigned. When clients query DNS for the service, they get a list of pod IPs directly. Clients then connect straight to pods, bypassing any load balancer. As pods scale or change IPs, DNS updates accordingly. This is useful for applications needing direct pod access, like databases or stateful sets. The service stops when deleted or no pods match the selector.

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