Using labels for service routing in Kubernetes - Step-by-Step Execution

Process Flow - Using labels for service routing

Create Pods with labels

↓

Define Service selector

↓

Service routes traffic

↓

Traffic reaches matching Pods

↓

Pods respond to requests

↓

END

Pods are created with labels. The Service uses selectors to find Pods with matching labels. Traffic sent to the Service is routed to those Pods.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: myapp
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80

Defines Pods with label 'app: myapp' and a Service selecting Pods with that label to route traffic on port 80.

Process Table

Step	Action	Resource	Labels/Selector	Result
1	Create Pod	Pod 'pod1'	app: myapp	Pod created with label app=myapp
2	Create Pod	Pod 'pod2'	app: myapp	Pod created with label app=myapp
3	Create Service	Service 'myservice'	selector app=myapp	Service created selecting pods with app=myapp
4	Send traffic to Service	Service 'myservice'	selector app=myapp	Traffic routed to pod1 and pod2
5	Pods respond	Pods 'pod1' and 'pod2'	app=myapp	Pods handle requests
6	Send traffic to Service	Service 'myservice'	selector app=myapp	Traffic routed only to pods matching label
7	Create Pod	Pod 'pod3'	app: otherapp	Pod created with label app=otherapp (not selected)
8	Send traffic to Service	Service 'myservice'	selector app=myapp	Traffic NOT routed to pod3
9	END			Routing only to pods with matching labels

💡 Pods without matching labels are excluded from Service routing

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 7	Final
Pods with label app=myapp	0	1 (pod1)	2 (pod1, pod2)	2 (pod1, pod2)	2 (pod1, pod2)
Pods with label app=otherapp	0	0	0	1 (pod3)	1 (pod3)
Service selector	none	none	app=myapp	app=myapp	app=myapp
Traffic routed pods	none	none	pod1, pod2	pod1, pod2	pod1, pod2

Key Moments - 3 Insights

Why doesn't the Service route traffic to pod3 even though it exists?

Because pod3 has label app=otherapp which does not match the Service selector app=myapp (see execution_table step 8). Only pods with matching labels receive traffic.

What happens if a Pod is created without any labels?

The Service selector won't find it, so traffic won't be routed to that Pod. Labels are required for Service routing (see execution_table steps 1-3).

Can a Service route traffic to Pods with multiple different labels?

No, the Service selector matches Pods with the exact label set specified. To route to multiple label sets, multiple Services or label selectors with multiple keys are needed.

Visual Quiz - 3 Questions

Look at the execution table at step 4. Which Pods receive traffic from the Service?

A pod1 and pod2

B pod3 only

C pod1, pod2, and pod3

D No Pods receive traffic

💡 Hint

Check the 'Result' column at step 4 in the execution_table.

At which step does a Pod with a non-matching label get created?

A Step 2

B Step 5

C Step 7

D Step 3

💡 Hint

Look for the Pod with label app=otherapp in the execution_table.

If the Service selector changed to app=otherapp, which Pods would receive traffic?

A pod1 and pod2

B pod3 only

C All Pods

D No Pods

💡 Hint

Refer to variable_tracker for Pods with label app=otherapp.

Concept Snapshot

Pods have labels as tags.
Services use selectors to find Pods by labels.
Traffic sent to Service goes only to matching Pods.
Pods without matching labels do not get traffic.
Labels enable flexible routing in Kubernetes.

Full Transcript

In Kubernetes, Pods are created with labels, which are like name tags. A Service uses a selector to find Pods with specific labels. When you send traffic to the Service, it routes the requests only to Pods whose labels match the selector. Pods without matching labels do not receive traffic. This method allows you to control which Pods handle which requests by labeling them accordingly.

Practice

1. What is the main purpose of using labels in Kubernetes service routing?

easy

A. To connect services to the correct pods

B. To store pod logs

C. To define pod resource limits

D. To schedule pods on specific nodes

Solution

1. Step 1: Understand labels role

   Labels are key-value pairs attached to pods to identify them.

2. Step 2: Connect services using selectors

   Services use selectors to find pods with matching labels for routing traffic.

3. Final Answer:

   To connect services to the correct pods -> Option A

4. Quick Check:

   Labels link services and pods = D [OK]

Hint: Labels identify pods for services to route traffic [OK]

Common Mistakes:

• Confusing labels with resource limits
• Thinking labels store logs
• Assuming labels control pod scheduling

2. Which of the following is the correct syntax to select pods with label app=frontend in a Service YAML?

easy

A. selector:
app: frontend

B. selector:
app = frontend

C. selector:
app: 'frontend'
version: 'v1'

D. selector:
- app: frontend

Solution

1. Step 1: Check YAML selector syntax

   Selectors use key: value pairs without '=' sign or list format.

2. Step 2: Validate options

   selector: app: frontend uses correct key: value syntax. selector: app = frontend uses '=' which is invalid. selector: app: 'frontend' version: 'v1' adds extra label, which is valid but not asked. selector: - app: frontend uses list format which is invalid for selector.

3. Final Answer:

   selector: app: frontend -> Option A

4. Quick Check:

   Selector uses key: value, no '=' or list [OK]

Hint: Use key: value pairs for selectors, no '=' or lists [OK]

Common Mistakes:

• Using '=' instead of ':' in YAML
• Writing selectors as lists
• Adding extra labels not requested

3. Given this Service YAML snippet:

selector:
  app: backend
  tier: api

Which pods will this Service route traffic to?

medium

A. Pods labeled only with app=backend

B. Pods labeled with either app=backend or tier=api

C. Pods labeled with both app=backend and tier=api

D. Pods labeled only with tier=api

Solution

1. Step 1: Understand selector matching

   Selectors match pods that have all specified labels (AND logic).

2. Step 2: Apply to given labels

   Pods must have both app=backend and tier=api labels to be selected.

3. Final Answer:

   Pods labeled with both app=backend and tier=api -> Option C

4. Quick Check:

   Selector matches all labels (AND) = A [OK]

Hint: Selectors match pods with all labels, not just one [OK]

Common Mistakes:

• Assuming selector matches any label (OR logic)
• Ignoring one of the labels in selector
• Confusing selector with pod annotations

4. You created a Service with selector:

selector:
  app: web
  env: prod

But traffic is not reaching pods. What is the most likely cause?

medium

A. Pods are not running on the same node

B. Service type is not LoadBalancer

C. Service port is missing

D. Pods do not have both labels app=web and env=prod

Solution

1. Step 1: Check label matching

   Service routes only to pods matching all selector labels.

2. Step 2: Identify common mismatch

   If pods lack either label, service finds no endpoints, so no traffic flows.

3. Final Answer:

   Pods do not have both labels app=web and env=prod -> Option D

4. Quick Check:

   Missing labels cause no pod selection = C [OK]

Hint: Verify pods have all selector labels to receive traffic [OK]

Common Mistakes:

• Blaming service type instead of labels
• Assuming node location affects routing
• Ignoring missing service port errors

5. You want to update your app without downtime. You have pods labeled app=frontend, version=v1. You deploy new pods with app=frontend, version=v2. How should you configure the Service selector to route traffic to both versions during rollout?

hard

A. Use selector: version=v2 only

B. Use selector: app=frontend only

C. Use selector: app=frontend and version=v2

D. Use selector: app=frontend and version=v1

Solution

1. Step 1: Understand rolling update strategy

   To route traffic to both old and new pods, selector must match both versions.

2. Step 2: Choose selector that matches both versions

   Selector with only app=frontend matches all pods regardless of version label.

3. Step 3: Avoid version-specific selectors

   Selectors with version=v1 or version=v2 exclude the other version, causing downtime.

4. Final Answer:

   Use selector: app=frontend only -> Option B

5. Quick Check:

   Selector matches all versions for smooth rollout = B [OK]

Hint: Use broad selector to include all versions during rollout [OK]

Common Mistakes:

• Selecting only new version pods causing downtime
• Selecting only old version pods ignoring new pods
• Using multiple selectors that exclude pods