Using labels for service routing in Kubernetes - Commands & Configuration

Introduction

When you run multiple parts of an app in Kubernetes, you need a way to send traffic to the right part. Labels help by tagging these parts so services know where to send requests.

When you want to connect a service to specific pods running your app.

When you have multiple versions of an app running and want to route traffic to one version.

When you want to organize pods by environment like development or production.

When you want to update your app without downtime by routing traffic to new pods gradually.

When you want to monitor or manage groups of pods easily by their labels.

Config File - service-routing.yaml

service-routing.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
    version: v1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod-v1
  labels:
    app: my-app
    version: v1
spec:
  containers:
    - name: my-app-container
      image: nginx:1.21
      ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod-v2
  labels:
    app: my-app
    version: v2
spec:
  containers:
    - name: my-app-container
      image: nginx:1.22
      ports:
        - containerPort: 8080

This file has three parts:

• Service: It routes traffic to pods with labels app: my-app and version: v1.
• Pod v1: A pod labeled with app: my-app and version: v1 running nginx 1.21.
• Pod v2: Another pod with app: my-app and version: v2 running nginx 1.22, but not selected by the service.

Commands

This command creates the service and pods defined in the YAML file. It sets up the routing rules using labels.

Terminal

kubectl apply -f service-routing.yaml

Expected Output

pod/my-app-pod-v1 created

pod/my-app-pod-v2 created

service/my-app-service created

This shows all pods with their labels so you can verify the labels are set correctly.

Terminal

kubectl get pods --show-labels

Expected Output

NAME             READY   STATUS    RESTARTS   AGE   LABELS

my-app-pod-v1    1/1     Running   0          10s   app=my-app,version=v1

my-app-pod-v2    1/1     Running   0          10s   app=my-app,version=v2

→

--show-labels - Displays labels assigned to each pod

This command shows the service details including the selector labels used for routing traffic.

Terminal

kubectl get service my-app-service

Expected Output

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

my-app-service   ClusterIP   10.96.0.1       <none>        80/TCP    15s

This shows detailed info about the service, including which pods it routes to based on labels.

Terminal

kubectl describe service my-app-service

Expected Output

Name:              my-app-service

Namespace:         default

Labels:            <none>

Annotations:       <none>

Selector:          app=my-app,version=v1

Type:              ClusterIP

IP:                10.96.0.1

Port:              80/TCP

TargetPort:        8080/TCP

Endpoints:         10.244.0.5:8080

Session Affinity:  None

Events:            <none>

Key Concept

Labels on pods let services find and route traffic only to the pods that match those labels.

Common Mistakes

Not adding matching labels on pods that the service selector expects.

The service won't find any pods to route traffic to, so your app won't receive requests.

Make sure pod labels exactly match the service selector labels.

Using different label keys or values between service selector and pods.

Labels must match exactly; otherwise, the service ignores those pods.

Double-check label keys and values for typos and consistency.

Assuming all pods with the same app label get traffic even if version label differs.

Service selector filters by all labels specified, so pods missing any label won't get traffic.

Include all required labels in both service selector and pod metadata.

Summary

Create pods with labels to identify them by app and version.

Create a service with a selector that matches the pod labels to route traffic.

Use kubectl commands to apply configs and verify labels and service routing.

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