Kubernetes - Labels & Selectors

Introduction
In Kubernetes, labels are simple key-value pairs attached to objects such as Pods, Deployments, and Services. They are the foundation of resource organization and selection, allowing you to efficiently group, filter, and manage related objects within your cluster.

Example label sets:

app: web-server
tier: frontend
environment: development
release: stable
Labels help answer questions like:

“Which Pods are part of my frontend tier?”

“Which resources belong to the staging environment?”

“Which release version is currently running?”

1. Working with Labels a. Creating a Pod with Labels Create a Pod manifest with labels. Save the following as labeled-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
name: web-server-pod
labels:
app: nginx
tier: frontend
environment: development
spec:
containers:

• name: nginx-container image: nginx Apply the manifest:

kubectl apply -f labeled-pod.yaml
b. Viewing Labels
To list Pods with their labels:

kubectl get pods --show-labels
Output:

NAME READY STATUS RESTARTS AGE LABELS
web-server-pod 1/1 Running 0 30s app=nginx,environment=development,tier=frontend
To display specific labels as columns:

kubectl get pods -L app,environment
c. Adding and Modifying Labels
Add a new label to an existing Pod:

kubectl label pod web-server-pod owner=admin
Verify the update:

kubectl get pods --show-labels
Update an existing label (requires the --overwrite flag):

kubectl label pod web-server-pod environment=staging --overwrite

1. Understanding Selectors If labels are the tags that describe objects, selectors are the filters used to find and group those objects.

Selectors are widely used in:

Services — to select which Pods to send traffic to.

Deployments — to define which Pods belong to the deployment.

ReplicaSets — to manage a specific group of Pods.

There are two main types of selectors:

a. Equality-Based Selectors
Filter objects based on exact key-value matches.

Supported operators:

=, ==, !=
b. Set-Based Selectors
Allow more flexible filtering by checking if a key’s value exists within (or outside) a set.

Supported operators:

in, notin, exists

1. Hands-On: Using Selectors Let’s create two more Pods for demonstration.

a. database-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: database-pod
labels:
app: postgres
tier: backend
environment: development
spec:
containers:

• name: postgres-container image: postgres b. api-pod.yaml apiVersion: v1 kind: Pod metadata: name: api-pod labels: app: user-api tier: backend environment: production spec: containers:
• name: api-container image: gcr.io/google-samples/hello-app:1.0 Apply both:

kubectl apply -f db-pod.yaml -f api-pod.yaml

1. Querying Pods with Selectors Equality-Based Selection Find all Pods in the development environment:

kubectl get pods -l environment=development
Find all Pods belonging to the backend tier:

kubectl get pods -l tier=backend
Combine multiple filters (logical AND):

kubectl get pods -l 'tier=backend,environment=production'
Set-Based Selection
Find all Pods in either the development or staging environments:

kubectl get pods -l 'environment in (development,staging)'
Find all Pods that do not belong to the frontend tier:

kubectl get pods -l 'tier notin (frontend)'
Find all Pods that simply have an app label (regardless of value):

kubectl get pods -l 'app'
Summary
Concept Purpose Example
Label Key/value metadata attached to objects app=nginx
Selector Filters resources by labels -l environment=dev
Equality-Based Selector Matches exact key/value tier=backend
Set-Based Selector Matches from a set or existence environment in (dev, staging)
Key Takeaways
Labels are the backbone of organization in Kubernetes.

Selectors use those labels to logically group, filter, and manage resources.

Kubernetes controllers (Deployments, Services, ReplicaSets) rely heavily on label selectors to define their scope.