Labels, selectors & annotations
The glue behind almost every Kubernetes object.
In plain terms
Labels are sticky notes you put on things; a selector is “grab everything with a blue note.” It’s how a Service or a ReplicaSet finds its pods without knowing any of their names.
Labels are arbitrary key/value tags on objects; selectors query them. This one primitive is the glue behind almost everything: a Service finds its pods, a ReplicaSet owns its pods, and the scheduler places by node labels — all through label selection.
terminal
$ kubectl label pod web tier=frontend$ kubectl get pods -l tier=frontend,app=web # equality (AND)$ kubectl get pods -l 'env in (prod,staging)' # set-based$ kubectl get pods --show-labels
Two selector styles exist: equality-based (tier=frontend) and set-based (env in (prod, staging)). Services and ReplicaSets use matchLabels; richer controllers accept matchExpressions. Annotations look similar but are for non-identifying metadata — you cannot select on them.
Selector typos fail silently
A Service whose selector matches no pod simply has zero endpoints, with no error anywhere. When traffic vanishes, kubectl get endpoints is the first check.