Using labels for service routing in Kubernetes - Deep Dive

Overview - Using labels for service routing

What is it?

Using labels for service routing in Kubernetes means attaching small pieces of information called labels to objects like pods. These labels help Kubernetes decide which pods should receive network traffic when a service is accessed. This way, services can send requests only to the right group of pods based on their labels. It makes managing and scaling applications easier and more organized.

Why it matters

Without labels for routing, Kubernetes would struggle to know which pods belong to which service, causing traffic to be sent to wrong or all pods. This would lead to inefficient resource use, errors, and difficulty in updating parts of an application independently. Labels solve this by providing a simple, flexible way to group and route traffic, enabling smooth updates, scaling, and maintenance.

Where it fits

Before learning labels for service routing, you should understand basic Kubernetes concepts like pods, services, and how networking works in Kubernetes. After mastering labels for routing, you can explore advanced topics like selectors, affinity rules, and ingress controllers for more complex traffic management.

Mental Model

Core Idea

Labels act like name tags that Kubernetes uses to find and send traffic only to the right pods within a service.

Think of it like...

Imagine a party where guests wear colored wristbands to show which group they belong to. The host only calls guests with a specific color to join an activity. Labels in Kubernetes work like those wristbands, helping the host (service) find the right guests (pods) to talk to.

Service
  │
  ▼
[Selector: app=web]
  │
  ▼
Pods with labels:
 ┌─────────────┬─────────────┬─────────────┐
 │ app=web    │ app=api     │ app=web     │
 │ version=v1 │ version=v1  │ version=v2  │
 └─────────────┴─────────────┴─────────────┘
  │             │             │
  ▼             ▼             ▼
Receives traffic  No traffic   Receives traffic

Build-Up - 6 Steps

1

Foundation

What are Kubernetes labels

Concept: Labels are key-value pairs attached to Kubernetes objects to identify and organize them.

In Kubernetes, labels are simple text tags like "app=frontend" or "env=production". You can add them to pods, services, and other objects. They help group objects logically without affecting how the system runs. For example, you can label pods running the frontend part of your app with "app=frontend".

Result

Objects now have labels that describe their role or characteristics.

Understanding labels as simple tags helps you see how Kubernetes can group and select objects flexibly.

2

Foundation

How services use selectors

Concept: Services use selectors to find pods with matching labels to send traffic to.

A Kubernetes service defines a selector, like "app=frontend", to find pods with that label. When a request comes to the service, it forwards the request only to pods matching the selector. This way, the service acts as a stable endpoint for a group of pods.

Result

Service routes traffic only to pods with matching labels.

Selectors connect services to pods dynamically, enabling flexible routing as pods come and go.

3

Intermediate

Using multiple labels for fine routing

🤔Before reading on: do you think a service selector can match pods with multiple labels or only one? Commit to your answer.

Concept: Selectors can match pods with multiple labels to route traffic more precisely.

You can define a service selector with multiple labels, for example, "app=frontend" and "version=v2". This means the service will only send traffic to pods that have both labels. This helps when you want to route traffic to a specific version or subset of pods.

Result

Service routes traffic only to pods matching all specified labels.

Knowing that selectors can combine labels lets you control traffic routing with great precision.

4

Intermediate

Labeling for canary deployments

🤔Before reading on: do you think labels can help send traffic to only a small part of your pods during updates? Commit to your answer.

Concept: Labels enable canary deployments by routing traffic to a subset of pods with a special label.

When updating an app, you can label new pods with "version=canary" and keep old pods labeled "version=stable". Then, create a service selector that routes some traffic only to canary pods. This lets you test new versions with real users safely.

Result

Traffic can be split between stable and canary pods using labels.

Using labels for canary deployments helps reduce risk by controlling which pods get traffic during updates.

5

Advanced

Label selectors with operators

🤔Before reading on: do you think selectors can use operators like 'not equal' or 'in'? Commit to your answer.

Concept: Kubernetes supports advanced label selectors with operators to include or exclude pods.

Selectors can use operators like 'In', 'NotIn', 'Exists', and 'DoesNotExist'. For example, a selector can be "env in (production, staging)" to match pods labeled with either environment. This allows complex routing rules beyond simple equality.

Result

Services can route traffic based on complex label conditions.

Understanding selector operators unlocks powerful and flexible routing strategies.

6

Expert

Limitations and pitfalls of label routing

🤔Before reading on: do you think labels alone can handle all routing needs in Kubernetes? Commit to your answer.

Concept: Labels are powerful but have limits; some routing needs require other tools like Ingress or service mesh.

Labels route traffic at the pod level but cannot handle HTTP path routing, TLS termination, or cross-cluster routing. For these, Kubernetes uses Ingress controllers or service meshes like Istio. Labels are best for grouping pods but not for all traffic control.

Result

Labels provide basic routing but must be combined with other tools for advanced scenarios.

Knowing label routing limits helps you choose the right tool for complex traffic management.

Under the Hood

Kubernetes stores labels as metadata on objects in its etcd database. When a service receives traffic, it uses its selector to query the API server for pods matching the labels. The service then updates its endpoints list dynamically to include only those pods. Traffic is forwarded via kube-proxy or IPVS to the selected pods, ensuring routing matches the current cluster state.

Why designed this way?

Labels and selectors were designed to provide a simple, flexible, and scalable way to group and route traffic without hardcoding pod identities. This decouples services from pods, allowing pods to be created, destroyed, or updated without changing service definitions. Alternatives like fixed IPs or manual routing were too rigid and error-prone.

┌───────────────┐       ┌───────────────┐
│   Service     │──────▶│ API Server    │
│ (with selector│       │(matches pods  │
│  app=frontend)│       │ labels)       │
└───────────────┘       └───────────────┘
         │                      │
         ▼                      ▼
  ┌─────────────┐        ┌─────────────┐
  │ kube-proxy  │◀──────▶│ Pods with   │
  │ routes to   │        │ label app=frontend │
  │ matching pods│        └─────────────┘
  └─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think a service sends traffic to pods without matching labels? Commit yes or no.

Common Belief: A service sends traffic to all pods in the cluster regardless of labels.

Reality: A service only routes traffic to pods whose labels match its selector exactly.

Why it matters: Assuming services send traffic to all pods can cause confusion and misdiagnosis when some pods do not receive traffic.

Quick: Can you use labels to route traffic based on HTTP paths? Commit yes or no.

Common Belief: Labels can be used to route traffic based on HTTP URL paths or headers.

Reality: Labels route traffic only at the pod level; HTTP path-based routing requires Ingress or service mesh.

Why it matters: Expecting labels to handle HTTP routing leads to wrong architecture choices and failed deployments.

Quick: Do you think label selectors can only check for exact matches? Commit yes or no.

Common Belief: Label selectors only support exact key-value matches.

Reality: Selectors support operators like In, NotIn, Exists, and DoesNotExist for flexible matching.

Why it matters: Not knowing selector operators limits routing strategies and leads to overly complex workarounds.

Quick: Do you think labels are immutable once set on a pod? Commit yes or no.

Common Belief: Labels on pods cannot be changed after the pod is created.

Reality: Labels can be added, modified, or removed on running pods using kubectl commands.

Why it matters: Believing labels are fixed prevents dynamic routing adjustments and flexible deployments.

Expert Zone

1

Label selectors are evaluated by the Kubernetes API server, so complex selectors can impact API performance in large clusters.

2

Labels are purely metadata and do not enforce any security or access control; combining labels with RBAC or Network Policies is necessary for secure routing.

3

Using consistent label naming conventions across teams and environments is critical to avoid routing errors and simplify automation.

When NOT to use

Labels should not be used alone for routing when you need advanced traffic control like HTTP path routing, TLS termination, or cross-cluster routing. In those cases, use Ingress controllers, service meshes (e.g., Istio), or external load balancers.

Production Patterns

In production, teams use labels to separate environments (dev, staging, prod), versions (v1, v2), and roles (frontend, backend). Canary deployments use labels to route a small percentage of traffic to new versions. Labels combined with Network Policies enforce security boundaries. Operators automate label management for scaling and updates.

Connections

Microservices architecture

Labels enable microservices to be grouped and routed independently within Kubernetes.

Understanding labels helps grasp how microservices communicate and scale separately in a cluster.

DNS service discovery

Kubernetes services use labels to select pods, which are then discoverable via DNS names.

Knowing label routing clarifies how DNS names map to dynamic pod groups in Kubernetes.

Database sharding

Both use labels or tags to partition workloads into manageable groups for routing and scaling.

Seeing label routing like sharding helps understand workload distribution and isolation concepts.

Common Pitfalls

#1 Using incorrect or inconsistent labels causing services to route no traffic.

Wrong approach:

apiVersion: v1
kind: Service
metadata:
name: frontend-service
spec:
selector:
app: front-end
ports:
- protocol: TCP
port: 80
targetPort: 8080

---
apiVersion: v1
kind: Pod
metadata:
name: frontend-pod
labels:
app: frontend
spec:
containers:
- name: app
image: myapp:latest

Correct approach:

apiVersion: v1
kind: Service
metadata:
name: frontend-service
spec:
selector:
app: frontend
ports:
- protocol: TCP
port: 80
targetPort: 8080

---
apiVersion: v1
kind: Pod
metadata:
name: frontend-pod
labels:
app: frontend
spec:
containers:
- name: app
image: myapp:latest

Root cause:

Mismatch between service selector label and pod label keys or values causes no pods to match, so no traffic is routed.

#2 Expecting labels to route traffic based on HTTP paths or headers.

Wrong approach:

apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 8080
# Trying to route /api path to different pods using labels (not supported)

Correct approach:

Use an Ingress resource with rules for HTTP paths:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-ingress
spec:
rules:
- http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80

Root cause:

Labels route at pod level only; HTTP path routing requires Ingress or service mesh.

#3 Not updating labels on pods during deployments causing stale routing.

Wrong approach:

Deploy new pods without updating their labels, e.g., new version pods labeled 'version: old'.

Correct approach:

Label new pods correctly, e.g., 'version: v2', and update service selectors or create new services accordingly.

Root cause:

Failing to manage labels during updates leads to traffic going to wrong pod versions.

Key Takeaways

Labels are simple key-value tags that Kubernetes uses to group and identify objects like pods.

Services use selectors to route traffic only to pods with matching labels, enabling flexible and dynamic routing.

Combining multiple labels and selector operators allows precise control over which pods receive traffic.

Labels alone cannot handle advanced routing like HTTP path or header-based routing; other tools like Ingress are needed.

Proper label management is critical in production to ensure correct traffic routing, smooth updates, and scalable deployments.