Kubernetes Label Selector Tester
Test equality-based and set-based Kubernetes label selector queries against pod metadata with matched resource breakdowns — entirely on this device.
- Key 'env' must equal 'production'
- Key 'tier' must be one of [backend, frontend]
Do it offline:$
How to use it
- Enter a Kubernetes label selector query (e.g. env=production, tier in (backend, worker)).
- Alternatively, pick from the pre-configured example query presets.
- Review parsed requirements decomposed into exact boolean condition checks.
- Inspect the interactive split grid displaying matched versus non-matching resources in real time.
Test and validate Kubernetes label selector queries (equality, set-based in/notin, and key existence) against real-world pod and resource metadata with live matching breakdowns.
How it works
Kubernetes uses label selectors to group core objects such as Pods, Services, Deployments, and NetworkPolicies without rigid hierarchical schemas.
Equality-based requirements support three operators: = (or ==) for exact value match, and != for inequality or absent key.
Set-based requirements introduced in extensions/v1beta1 support rich operators: in (value in set), notin (value not in set), key (key exists), and !key (key does not exist).
Multiple comma-separated requirements act as an AND condition: a resource must satisfy every requirement simultaneously to match.
Examples
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Common errors
FAQ
Can Kubernetes Services use set-based label selectors?
No! Kubernetes Service spec.selector currently only supports equality-based selectors. Set-based requirements (in, notin, !) are supported in Deployment spec.selector.matchExpressions, Job selectors, and NetworkPolicies.
What does an empty label selector match in kubectl or manifests?
An empty selector matches every resource in the queried scope/namespace. In contrast, an empty matchLabels map ({}) also matches everything, but omitting the selector block altogether may cause validation errors depending on the API resource schema.
Are label values case-sensitive in Kubernetes?
Yes! Both label keys and values in Kubernetes are strictly case-sensitive. 'env=Production' will NOT match a pod labeled with 'env=production'.