0
0
Kubernetesdevops~5 mins

Using labels for service routing in Kubernetes - Commands & Configuration

Choose your learning style9 modes available
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 OutputExpected
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 OutputExpected
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 OutputExpected
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 OutputExpected
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.