kubernetes-sigs / kubernetes-sigs/node-readiness-controller

[BUG] Verification steps use a label selector that only matches the static pod example

Open
#401 2 comments 0 reactions 1 assignee View on GitHub

@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-manager and app.kubernetes.io/name=nrrcontroller
  • Helm chart (charts/nrr-controller/templates/_helpers.tpl):
    app.kubernetes.io/name=nrr-controller, app.kubernetes.io/instance=<release>
    and control-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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.