A set-based label selector filters Kubernetes objects by requiring a label value to belong to, or be excluded from, a specified set. It can also test whether a label key exists or does not exist. section 7.3
Use these operators in a selector or match expression:
- In requires the label value to match one of the listed values, such as app in (quiz, quote). section 7.3
- NotIn excludes objects whose label value matches any listed value, such as app notin (kiada). section 7.3
- Exists selects objects containing a label key, while DoesNotExist selects objects without that key. section 7.3 section 7.3.2
- Lt compares a label value with a single specified value. section 7.3.2
Select application pods
Run kubectl get pods -l 'app in (quiz, quote)' to list both Quiz and Quote pods. Combine selectors with commas when every condition must match: kubectl get pods -l app=quote,rel=canary selects only the quote-canary Pod. Quote !rel when testing absence in a shell, as in kubectl get pods -l '!rel'. section 7.3.1 section 7.3
Constrain pod scheduling
A nodeAffinity match expression can require node-role In front-end and skip-me DoesNotExist. Multiple nodeSelectorTerms act as alternatives, while expressions within one term must all match. Labeling matching nodes with skip-me=true leaves the affinity-constrained pod Pending. section 7.3.2
Listing 7.5 Using a set-based label selector
apiVersion: v1
kind: Pod
metadata:
name: kiada-front-end-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions: #1
- key: node-role #2
operator: In #2
values: #2
- front-end #2
- key: skip-me #3
operator: DoesNotExist #3
...
Use the manifest listing to inspect how In and DoesNotExist expressions combine in node affinity. section 7.3.2
