Skip to content

feat: add blocked nodes metric to scrape-time collector - #431

Open
rawadhossain wants to merge 2 commits into
kubernetes-sigs:mainfrom
rawadhossain:blocked-nodes
Open

feat: add blocked nodes metric to scrape-time collector#431
rawadhossain wants to merge 2 commits into
kubernetes-sigs:mainfrom
rawadhossain:blocked-nodes

Conversation

@rawadhossain

@rawadhossain rawadhossain commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Description

Adds node_readiness_blocked_nodes{rule, condition} for tracking the number of currently-held nodes blocked by each unsatisfied condition for each NodeReadinessRule. Ref. New Scrape-Time Collector Surface

The metric is collected directly from the controller runtime cache on each Prometheus scrape, sharing the same Node snapshot with node_readiness_rule_nodes.

Changes

  • Added node_readiness_blocked_nodes metric with rule and condition labels.
  • Added ListBlockedNodes to calculate blocked nodes from the live Node state.
  • Uses the rule's DefaultStatus when a condition is missing from the Node, same as the controller.
  • Shares the ListNodes with node_readiness_rule_nodes during each scrape.

Related to #397

Type of Change

/kind feature

Testing

  • make test, make lint, go test ./... -race all pass
  • Verified against a live cluster, including live condition changes and DefaultStatus behavior.

Checklist

  • make test passes
  • make lint passes

Signed-off-by: Rawad Hossain <rawad.hossain00@gmail.com>
@kubernetes-prow kubernetes-prow Bot added the kind/feature Categorizes issue or PR as related to a new feature. label Aug 19, 2026
@netlify

netlify Bot commented Aug 19, 2026

Copy link
Copy Markdown

Deploy Preview for node-readiness-controller canceled.

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

@kubernetes-prow
kubernetes-prow Bot requested review from dchen1107 and mrunalp August 19, 2026 12:59
@kubernetes-prow

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rawadhossain
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:

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

@kubernetes-prow kubernetes-prow Bot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Aug 19, 2026
@kubernetes-prow

Copy link
Copy Markdown

Hi @rawadhossain. 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.

@kubernetes-prow kubernetes-prow Bot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Aug 19, 2026
@rawadhossain

Copy link
Copy Markdown
Contributor Author

/cc @AvineshTripathi @ajaysundark

@AvineshTripathi

Copy link
Copy Markdown
Contributor

/ok-to-test

@kubernetes-prow kubernetes-prow Bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Aug 19, 2026

@AvineshTripathi AvineshTripathi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did my initial round of reviewing, please have a look at the comments!

}

// ListBlockedNodes returns the number of blocked nodes for each rule and unsatisfied condition.
func (r *RuleReadinessController) ListBlockedNodes(ctx context.Context, nodes []corev1.Node) (map[string]metrics.RuleBlockedConditions, error) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this func is very much similar to ListRuleNodeStates in terms of execution. Can we make a util func that gives you execution flow and use it in both places?

for e.g.

func (r *RuleReadinessController) measureRuleNodes(
    ctx context.Context,
    nodes []corev1.Node,
    measureFn func(rule *readinessv1alpha1.NodeReadinessRule, node *corev1.Node) error,
) error {
    // Fetch rules, iterate, parse selectors, filter nodes
    // Call measureFn(rule, node) for each held node
    // measureFn does the actual counting/filtering
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Added a shared util forEachRuleNode and reused it in both functions.

continue
}

selector, err := metav1.LabelSelectorAsSelector(&rule.Spec.NodeSelector)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can reuse ruleAppliesTo here. I see we add extra !r.hasTaintBySpec(node, rule.Spec.Taint) check so probably opportunity to create another util that uses runAppliesTo and hasTaint

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, right. Added parseNodeSelector so the selector parsing is shared and added ruleAppliesToWithTaint to handle the rule + taint check together.

return
}

counts, err := c.lister.ListRuleNodeStates(ctx, nodes)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing return in case of err, this could be expected behavior but there is inconsistency. ListBlockedNodes below returns in case of err

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made error handling consistent for both metrics now. Neither returns on error, we log and continue as the two metrics are independent, so a failure in one shouldn't prevent the other from being collected.


// Collect implements prometheus.Collector.
func (c *ReadinessCollector) Collect(ch chan<- prometheus.Metric) {
ctx, cancel := context.WithTimeout(context.Background(), collectTimeout)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5sec to do ListNodes, ListRuleNodeStates and ListBlockedNodes can feel little less. wdyt?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't fully sure about this. Kept it at 5s since it's below Prometheus's default scrape timeout (10s), so we can fail and log before the scrape times out. I also tested it with larger node counts and it seemed fine. Do you think it'd be better to increase?

const collectTimeout = 5 * time.Second

// NodeLister lists Nodes for the collector.
type NodeLister interface {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more like a question not a blocker: why are we creating individual interfaces when at the end we are using only ReadinessLister. Is this for testing purposes?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, mainly for testing, so each part can be mocked independently

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants