kubernetes-sigs / kubernetes-sigs/node-readiness-controller
[BUG] Verification steps use a label selector that only matches the static pod example
@Ujjwal-Gowda is already working on this.
Since Aug 13, 2026.
- Dominant language
- Go
- Stars
- 164
- Forks
- 75
- Avg merge
- 8d 23h
- Merged PRs (30d)
- 13
Description
Is your feature request related to a problem or existing issue? Please describe.
The verification steps in the installation guide tell the reader to find the
controller pods with:
kubectl get pods -n ${NAMESPACE} -l component=node-readiness-controller
kubectl logs -n ${NAMESPACE} -l component=node-readiness-controller
component=node-readiness-controller is only set by
examples/static-pod/node-readiness-controller.yaml. Grepping the repository,
that example is the only place the label appears outside the docs.
The other deployment options label their pods differently:
- release manifests and Kustomize (
config/manager/manager.yaml):
control-plane=controller-managerandapp.kubernetes.io/name=nrrcontroller - Helm chart (
charts/nrr-controller/templates/_helpers.tpl):
app.kubernetes.io/name=nrr-controller,app.kubernetes.io/instance=<release>
andcontrol-plane=controller-manager
Neither sets a component label, so both verification commands return nothing.
kubectl get pods prints "No resources found" and kubectl logs prints an
error about no matching pods, neither of which hints that the selector itself
is the problem. Someone whose install worked fine can reasonably conclude that
it did not.
I confirmed this on a kind cluster: after installing the chart,
-l component=node-readiness-controller matches 0 pods, while
-l app.kubernetes.io/name=nrr-controller and
-l control-plane=controller-manager both match the running pod.
Describe the solution you'd like
Add a ${SELECTOR} placeholder next to the existing ${NAMESPACE} one and
list the value for each deployment option, so the commands work regardless of
how the controller was installed.
Describe alternatives you've considered
Adding a component label to the chart and the Kustomize base so one selector
works everywhere. That changes the deployment's label set rather than the docs,
and the pod labels of an installed release are not something to change lightly,
so documenting the difference seemed like the smaller step. Happy to go the
other way if you would prefer the labels unified.
I have the docs change ready, could I be assigned?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.