api: Add status.summary with aggregated node counts to NodeReadinessRule

[vishnukothakapu]

Description

This PR implements the status.summary field proposed in #483 to provide pre-computed node aggregated counts.

As pointed out during review, because the Kubernetes API returns the full CRD object, this PR does not reduce the network payload size yet since the legacy arrays remain in the object. However, it accomplishes two critical goals:

1. It eliminates the need for UI clients (like Headlamp) to run expensive client-side loops to calculate basic totals.
2. It completely prepares the API surface for the future deprecation of status.nodeEvaluations. Once those arrays are eventually removed upstream, UI clients will already be reading from status.summary and the payload size will drastically drop.

Implementation details :

• Added NodeReadinessRuleSummary to the CRD types (Matched, Held, Released, Failed).
• Architectural Pivot: The summary computation is now 100% decoupled from the legacy NodeEvaluations array.
• It uses ListRuleNodeStates on the controller's local informer cache to generate the counts (identically to how the Prometheus metrics collector works).
• The summary is computed and injected immediately prior to optimistic locking patches in updateRuleStatus, cleanupDeletedNodes, and the node reconciler.
• This guarantees O(1) API performance and completely eliminates the controller's dependency on NodeEvaluations for generating this summary.

Related Issue

Fixes #483
Related to #327

Type of Change

/kind feature
/kind api-change

Testing

• Confirmed go build and go test ./internal/controller/... pass locally.
• Verified that incremental node updates correctly trigger summary recalculation via patchRuleStatusWithOptimisticLock.
• Wrote a new unit test TestComputeRuleSummary using the controller-runtime fake client to directly validate the decoupled summary computation against simulated cluster nodes.

Checklist

• make test passes
• make lint passes

Does this PR introduce a user-facing change?

Added a status.summary object to the NodeReadinessRule CRD that provides pre-computed, aggregated node evaluation counts (matched, held, released, and failed nodes) for O(1) reads by API clients.

Generative AI Usage Disclosure

• No AI tools were used
• AI tools were used (complete below)

How they were used:

Antigravity was used to write the unit tests for helper_unit_test.go. The final code was manually reviewed and tested locally

[netlify]

✅ Deploy Preview for node-readiness-controller canceled.

Name	Link
🔨 Latest commit	e20a95d
🔍 Latest deploy log	https://app.netlify.com/projects/node-readiness-controller/deploys/6abd66aa1b3b440008bed723

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vishnukothakapu
Once this PR has been reviewed and has the lgtm label, please assign mrunalp for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubernetes-prow]

Hi @vishnukothakapu. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Karthik-K-N]

Not sure if we really need this with NRE is being proposed to solve these kind of problems.

[vishnukothakapu]

Not sure if we really need this with NRE is being proposed to solve these kind of problems.

@Karthik-K-N, NRE works for checking individual nodes, but we still need this summary field for the Headlamp dashboard. otherwise, the UI would need to fetch thousands of NREs and calculate totals client-side. keeping the totals on the Rule object lets the dashboard load them with a single lightweight API call, which scales much better for large clusters.

[AnuragThePathak]

First of all before I check the code @vishnukothakapu, wanted to point out that this part is misleading

Instead of forcing clients to download up to 5,000 items from status.nodeEvaluations and run client-side loops just to get basic counts (e.g., "1,800 released, 150 held"), this PR writes those totals directly into the CRD status in O(1) time.

Your change won't magically fetch what your headlamp component is exactly rather the full CRD as a whole.

Secondly @Karthik-K-N, this is different from NRE. It is to provide these values like how many nodes are satisfying a rule, how many are targeted by the rule etc. Metrics also provide the same info through other means, but the problem is Headlamp doesn't natively support using Prometheus metrics.

Instead if we plumb those values in rule CRD, we will conveniently solve the Headlamp problem as well as have a chance to improvise the observability aspect for people using kubectl perhaps.

[AnuragThePathak]

@vishnukothakapu please run the linter (using make lint) and fix the issues. This is a step you should follow for all PRs.