Using labels for service routing in Kubernetes - Mini Project: Build & Apply

Using labels for service routing

📖 Scenario: You are managing a Kubernetes cluster that runs multiple versions of a web application. You want to route traffic to the correct version using labels and services.

🎯 Goal: Create two deployments with different labels and a service that routes traffic to one of them using label selectors.

📋 What You'll Learn

Create a deployment named web-v1 with label version: v1

Create a deployment named web-v2 with label version: v2

Create a service named web-service that routes traffic to pods with label version: v1

Use correct Kubernetes YAML syntax for deployments and service

Verify the service routes to the correct pods by checking labels

💡 Why This Matters

🌍 Real World

In real Kubernetes clusters, labels and selectors help route traffic to the right pods, enabling blue-green deployments and canary releases.

💼 Career

Understanding labels and service routing is essential for Kubernetes administrators and DevOps engineers to manage application versions and traffic flow.

1

Create the first deployment with label

Create a deployment named web-v1 with label version: v1 and container image nginx:1.19. Use 2 replicas.

Kubernetes

# Create deployment web-v1 with label version: v1
# Your code here

Hint

Use metadata.name for deployment name, spec.replicas for number of pods, and metadata.labels inside template for pod labels.

2

Create the second deployment with a different label

Create a deployment named web-v2 with label version: v2 and container image nginx:1.20. Use 2 replicas.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      version: v1
  template:
    metadata:
      labels:
        version: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.19

# Create deployment web-v2 with label version: v2
# Your code here

Hint

Follow the same structure as web-v1 deployment but change the name, label, and image.

3

Create a service to route traffic using label selector

Create a service named web-service that routes traffic to pods with label version: v1. Use port 80 for the service and target port 80 for the pods.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      version: v1
  template:
    metadata:
      labels:
        version: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v2
spec:
  replicas: 2
  selector:
    matchLabels:
      version: v2
  template:
    metadata:
      labels:
        version: v2
    spec:
      containers:
      - name: nginx
        image: nginx:1.20

# Create service web-service with selector version: v1
# Your code here

Hint

Use kind: Service with spec.selector matching version: v1 and define ports correctly.

4

Verify the service routes to the correct pods

Run the command kubectl get pods --selector=version=v1 --output=wide and print the output to verify pods with label version: v1 are selected.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      version: v1
  template:
    metadata:
      labels:
        version: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-v2
spec:
  replicas: 2
  selector:
    matchLabels:
      version: v2
  template:
    metadata:
      labels:
        version: v2
    spec:
      containers:
      - name: nginx
        image: nginx:1.20
---
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    version: v1
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

# Run kubectl command to get pods with label version=v1
# Your code here

Hint

Use print() to simulate the output of kubectl get pods --selector=version=v1 --output=wide.

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