CKAD — Labels and Selectors

What Are Labels?

Labels are key-value pairs attached to Kubernetes objects. They are the primary mechanism for organizing and selecting resources. Almost every Kubernetes feature — Services, Deployments, ReplicaSets, NetworkPolicies — uses labels to find the objects it manages.

Adding Labels

# Add labels when creating a Pod
kubectl run web --image=nginx --labels="app=web,env=prod,tier=frontend"

# Add labels to an existing resource
kubectl label pod web version=v1

# Overwrite an existing label
kubectl label pod web env=staging --overwrite

# Remove a label (note the minus sign)
kubectl label pod web version-

Viewing Labels

# Show labels for all Pods
kubectl get pods --show-labels

# Show specific label columns
kubectl get pods -L app,env

# Expected output:
# NAME   READY   STATUS    AGE   APP   ENV
# web    1/1     Running   30s   web   prod

Selecting Resources with Labels

Selectors use labels to filter objects. There are two types of selectors:

Equality-Based Selectors

kubectl get pods -l app=web
kubectl get pods -l env=prod
kubectl get pods -l app=web,env=prod    # AND logic
kubectl get pods -l 'app!=cache'         # Not equal

Set-Based Selectors

kubectl get pods -l 'env in (prod, staging)'
kubectl get pods -l 'app notin (cache, db)'
kubectl get pods -l 'tier,!version'              # Has tier, does NOT have version

Selector Comparison Table

Selector Type	Syntax	Example
Equality	key=value	app=web
Not equal	key!=value	env!=dev
In set	key in (v1,v2)	env in (prod,staging)
Not in set	key notin (v1,v2)	app notin (cache,db)
Exists	key	tier
Does not exist	!key	!version
Multiple (AND)	k1=v1,k2=v2	app=web,env=prod

Labels in YAML

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
    env: prod
    tier: frontend
    version: v2
spec:
  containers:
  - name: nginx
    image: nginx:1.27

Label Selectors in Other Resources

Labels are used everywhere in Kubernetes. Here are the most common patterns:

Service Selecting Pods

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
    tier: frontend
  ports:
  - port: 80
    targetPort: 80

Deployment Managing Pods

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        version: v2
    spec:
      containers:
      - name: nginx
        image: nginx:1.27

NetworkPolicy Targeting Pods

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

Label Best Practices

Practice	Reason
Use consistent naming conventions	Makes selecting resources predictable
Include app, env, tier, version	Covers most filtering needs
Use Kubernetes recommended labels	app.kubernetes.io/name, app.kubernetes.io/version, etc.
Keep label values short	63-character max, alphanumeric + -_.
Don’t encode data in labels	Use annotations for large or complex metadata

Kubernetes Recommended Labels

metadata:
  labels:
    app.kubernetes.io/name: nginx
    app.kubernetes.io/instance: web-prod
    app.kubernetes.io/version: "1.27"
    app.kubernetes.io/component: frontend
    app.kubernetes.io/part-of: ecommerce
    app.kubernetes.io/managed-by: helm

Exam tip: Labels are used everywhere — Services select Pods by labels, Deployments manage Pods by label selectors, and NetworkPolicies target Pods by labels. Get fast at working with them.

---

Next: Learn about non-identifying metadata with Annotations →