Headless services concept in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a headless service by setting the correct clusterIP value.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: [1]
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

Drag options to blanks, or click blank then click option'

ALoadBalancer

B10.0.0.1

CNone

DClusterIP

Attempts:

3 left

💡 Hint

Common Mistakes

Using a normal IP address instead of 'None'.

Setting clusterIP to 'ClusterIP' or 'LoadBalancer' which are not valid values here.

Setting clusterIP: None creates a headless service in Kubernetes.

2fill in blank

medium

Complete the command to create a headless service from a YAML file named service.yaml.

Kubernetes

kubectl [1] -f service.yaml

Drag options to blanks, or click blank then click option'

Adelete

Bapply

Cget

Ddescribe

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'get' which only retrieves information.

Using 'delete' which removes resources.

Using 'describe' which shows details but does not create.

The kubectl apply command creates or updates resources from a YAML file.

3fill in blank

hard

Fix the error in the service selector to correctly match pods with label 'app: myapp'.

Kubernetes

spec:
  selector:
    app: [1]

Drag options to blanks, or click blank then click option'

Amyapp

Bapp

Cmy-app

Dmyapp1

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different label value like 'my-app' or 'myapp1'.

Using the label key instead of the value.

The selector must exactly match the pod label value 'myapp' to select the pods correctly.

4fill in blank

hard

Fill both blanks to create a headless service that selects pods labeled 'app: web' and exposes port 8080.

Kubernetes

spec:
  clusterIP: [1]
  selector:
    app: [2]
  ports:
  - port: 8080

Drag options to blanks, or click blank then click option'

ANone

Bweb

Cmyapp

DLoadBalancer

Attempts:

3 left

💡 Hint

Common Mistakes

Using a normal IP or LoadBalancer for clusterIP.

Using wrong label values in selector.

Setting clusterIP: None makes the service headless, and the selector must match the pod label 'web'.

5fill in blank

hard

Fill all three blanks to define a headless service with name 'db-service', selecting pods labeled 'role: database' and exposing port 5432.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: [1]
spec:
  clusterIP: [2]
  selector:
    role: [3]
  ports:
  - port: 5432

Drag options to blanks, or click blank then click option'

Adb-service

BNone

Cdatabase

Dfrontend

Attempts:

3 left

💡 Hint

Common Mistakes

Using a normal IP or LoadBalancer for clusterIP.

Using wrong service name or label values.

The service name is 'db-service', clusterIP is 'None' for headless, and selector matches pods with label 'role: database'.

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