The metadata and query system that binds every Kubernetes object together. Labels are the glue; selectors are the query. Without this pair, Services could not route, ReplicaSets could not adopt, and NetworkPolicies could not target. Synthesized from CKA Day 13 — Static Pods, Manual Scheduling, Labels, and Selectors.
What Are Labels?
A label is a key-value pair attached to a Kubernetes object. Labels are intended to be used for identifying attributes of objects that are meaningful and relevant to users, but they do not directly imply semantics to the core system.
Keys can have an optional prefix (e.g., company.com/app) separated by a /
Prefix + key must be ≤ 253 characters; key alone ≤ 63 characters
Values must be ≤ 63 characters, start/end with alphanumeric, contain only -, _, ., and alphanumeric
A single object can have up to 64 labels
What Are Selectors?
A selector is a filtering expression that matches objects based on their labels. Controllers and Services use selectors to discover which objects they should manage or route to.
Equality-Based Selectors
Match labels where the key equals (or does not equal) a value.
Operator
Meaning
Example
= or ==
Equal
app=nginx
!=
Not equal
env!=staging
# kubectl exampleskubectl get pods -l app=nginxkubectl get pods -l app=nginx,tier=frontendkubectl get pods -l 'env!=staging'
Set-Based Selectors
More expressive matching using sets of values.
Operator
Meaning
Example
in
Key has one of the listed values
env in (production, staging)
notin
Key does not have any of the listed values
env notin (dev, test)
exists
Key exists (regardless of value)
tier
!exists
Key does not exist
!version
kubectl get pods -l 'env in (production, staging)'kubectl get pods -l 'tier,version notin (v1.0, v1.1)'
Note: Set-based selectors are supported in kubectl and in some API fields (e.g., nodeSelector with nodeAffinity), but the core selector field in Deployments and Services uses equality-based matching only.
How Labels and Selectors Connect Objects
The relationship between a controller and its Pods is entirely label-driven. This is the central design philosophy of Kubernetes: loose coupling via metadata.
Deployment
selector: matchLabels: {app: nginx}
│
▼
ReplicaSet
selector: matchLabels: {app: nginx}
│
▼
Pod 1 labels: {app: nginx}
Pod 2 labels: {app: nginx}
Pod 3 labels: {app: nginx}
If you manually create a bare Pod with the label app: nginx, the ReplicaSet will adopt it automatically because the labels match. Conversely, if you remove the label from a Pod, the ReplicaSet will create a replacement to maintain the desired count.
Critical Exam Trap: Services use selector: {app: nginx}, while Deployments and ReplicaSets use selector: matchLabels: {app: nginx}. Mixing these two formats is a common YAML error that causes Services to show zero Endpoints or ReplicaSets to orphan Pods. Source: CKA Day 13
Annotations are useful for third-party tools (e.g., ingress controllers, cost allocators, GitOps operators) that need to attach metadata without affecting the object’s identity. Ingress resources heavily rely on annotations to pass controller-specific configuration (e.g., nginx.ingress.kubernetes.io/rewrite-target) that the Ingress API spec itself does not define. See Kubernetes Ingress for the annotation reference.
Managing Labels with kubectl
# Add a label to an existing Podkubectl label pod nginx-pod env=production# Overwrite an existing labelkubectl label pod nginx-pod env=staging --overwrite# Remove a labelkubectl label pod nginx-pod env-# Label all Pods in a Deploymentkubectl label pods -l app=nginx team=platform# Show labels in list outputkubectl get pods --show-labels# Filter by labelkubectl get pods -l app=nginxkubectl get all -l env=production
CKA Speed Pattern:--show-labels is indispensable when debugging selector mismatches. If a Service has no Endpoints, run kubectl get pods --show-labels and kubectl get svc <name> -o yaml to compare the labels.
Labels in Network Policies
NetworkPolicies use podSelector and namespaceSelector to define which traffic is allowed. These are pure label queries. See Kubernetes Network Policies for the full enforcement model and default-deny patterns. Source: CKA Day 26
This policy applies to all Pods with tier: frontend, and allows ingress only from Pods with tier: backend.
CKA Exam Relevance
Workloads & Scheduling (~15%): Create Deployments with correct matchLabels; fix orphaned Pods caused by label mismatches.
Services & Networking (~20%): Diagnose Services with zero Endpoints by verifying label alignment.
Troubleshooting (~30%): Use kubectl get pods --show-labels and kubectl get svc -o yaml to compare selectors.
Speed Patterns:
kubectl label pod <name> <key>=<value>kubectl get pods -l app=nginxkubectl get pods --show-labels
Practical Practice
Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.
Task 1: Label a Node with Zone and Environment
You are asked to label node worker1 with zone=us-east-1a and env=prod.
Requirements: Use kubectl label and verify both labels are present.
Verification:kubectl get node worker1 --show-labelsSolution:
Task 2: Find Pods by Label Across All Namespaces
You are asked to list every Pod with label app=web in every namespace.
Requirements: Use a single kubectl command.
Verification: Output shows all matching Pods with their namespaces.
Solution:
kubectl get pods --all-namespaces -l app=web
Task 3: Fix a Deployment Selector Mismatch
A Deployment’s ReplicaSet is not creating Pods. You suspect the selector does not match the Pod template labels.
Requirements: Inspect the Deployment YAML and the Pod template labels, then align them.
Verification:kubectl get replicaset shows the desired count and kubectl get pods shows new Pods.
Solution:
# Inspect the Deploymentkubectl get deployment <name> -o yaml | grep -A 5 selectorkubectl get deployment <name> -o yaml | grep -A 5 'template:'# If mismatch, edit the Deployment to ensure matchLabels matches metadata.labels in the templatekubectl edit deployment <name>