Labels
A label is a key-value pair attached to a Kubernetes object's metadata — a tag used to identify and organize resources, such as app: frontend or environment: production. Tracking a handful of Pods by name is easy, but a cluster running thousands of Pods across teams and environments needs a way to group and query them; labels are that mechanism.
metadata:
name: nginx-pod
labels:
app: nginx
environment: development
team: devopsOnce applied, labels show up with kubectl get pods --show-labels and can be used to filter results directly:
kubectl apply -f pod.yml
kubectl get pods --show-labels
kubectl get pods -l app=nginx
kubectl get pods -l app=nginx,environment=developmentCommon label conventions you'll see everywhere: app (which application), environment (dev/staging/production), version (release tag), and team (who owns it).
Selectors
A selector is the counterpart to a label — a query that matches objects by their labels. If a label is an identity tag, a selector is the search filter that finds everything wearing that tag. ReplicaSets, Deployments, Services, and NetworkPolicies all rely on selectors to decide which Pods they manage or route traffic to:
# ReplicaSet / Deployment — "manage every Pod with this label"
selector:
matchLabels:
app: nginx
# Service — "send traffic to every Pod with this label"
selector:
app: nginx| Concept | Role |
|---|---|
| Label | Attached to an object; answers "what am I?" |
| Selector | Attached to a controller or Service; answers "which objects do I care about?" |
Why This Pairing Matters
This pairing is what ties the object graph together: a Deployment's selector matches its ReplicaSet's labels, the ReplicaSet's selector matches its Pods' labels, and a Service's selector matches those same Pod labels to route traffic — all without any object referencing another by name.
Deployment ──selector──▶ ReplicaSet ──selector──▶ Pods
▲
Service ─────────────────selector──────────────────┘
That loose coupling is deliberate. Pods come and go — crash, reschedule, scale up and down — and as long as replacements carry the right labels, every controller and Service picks them up automatically. The upcoming ReplicaSet, Deployment, and Service lessons all build directly on this mechanism.
Keep labels meaningful and consistent (app, environment, version, team) rather than terse placeholders like a: x. A selector is only as useful as the labeling convention behind it, and once a Deployment or Service is wired to a selector, changing the underlying labels means re-wiring every object that depends on them.