A label selector filters Kubernetes objects by their labels. Labels are key–value pairs attached to objects; a selector turns those labels into a way to find a group without naming every member. You can use one to list or delete matching pods with kubectl, or put a selector in an object manifest so Kubernetes can identify related pods or nodes. section 7.3 section 7.6
Selectors can test values or simply check whether a key exists:
- Equality-based: app=quote selects pods labeled app=quote; app!=quote selects pods that do not match that value. section 7.3
- Set-based: app in (quiz, quote) accepts either value; app notin (kiada) excludes that value. The selector app requires the key to be present; !app requires it to be absent. section 7.3
- Combined: app=quote,rel=canary selects only objects matching both requirements. section 7.3
Find and act on a subset
Run kubectl get pods -l app=quote to list only Quote pods. Add a second requirement with kubectl get pods -l app=quote,rel=canary to find the Quote canary alone. The same filtering works for an operation: kubectl delete pods -l rel=canary deletes the matching canary pods. For a set expression, quote the selector, as in kubectl get pods -l 'app in (quiz, quote)' -L app; -L app displays the app label in its own column. Quote '!rel' too, so the shell does not interpret the exclamation mark. section 7.3.1
$ kubectl get pods -l app=quote,rel=canary NAME READY STATUS RESTARTS AGE quote-canary 2/2 Running 0 2h
The command and its single-pod output show that comma-separated requirements narrow a selection rather than combine two separate result lists. section 7.3.1
Selectors also express relationships between objects. A Service selector such as app=quote includes matching stable and canary pods as backends; other labels do not affect that match. With a selector, Kubernetes manages the Service’s Endpoints and EndpointSlices automatically. Without one, you must supply an Endpoints object yourself. A matching label alone does not guarantee that a newly started pod is ready for traffic: readiness affects whether it receives connections. To control membership by label, a Service can require enabled=true; removing that label removes the pod from the selected group. section 11.1.1 section 11.3.3
A Pod can select eligible nodes instead of choosing a node by name. Label a node with kubectl label node kind-worker node-role=front-end, then set spec.nodeSelector to node-role: front-end in the Pod manifest. Kubernetes can schedule that pod only on a node with the matching label. For more expressive requirements, node affinity supports matchExpressions, including In and DoesNotExist. If no node satisfies the required expressions, the pod remains Pending. section 7.3.2
A ReplicaSet uses a selector to identify the pods it keeps at its desired replica count. Pod names need not match: existing pods with matching labels can be adopted, while an extra matching pod can cause the controller to remove a pod. Changing a managed pod’s label so it no longer matches makes the controller create a replacement and leaves the changed pod available for inspection. Keep the selector’s labels in the ReplicaSet’s Pod template; additional template labels are allowed. A ReplicaSet selector cannot be edited after creation. section 14.1.2 section 14.3.3
A selector answers a label-based question, not every filtering question. Use a field selector when the criterion is an object field, such as the node on which a pod runs. Annotations cannot be filtered this way. section 7.6
