You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #338 per @ajaysundark's review comment: when a node's labels change so it no longer matches a NodeReadinessRule's spec.nodeSelector, NodeReconciler simply stops seeing the rule as applicable via getApplicableRulesForNode and moves on. Any taint that rule previously applied to the node is never removed, and the node's stale entries in rule.Status.NodeEvaluations/AppliedNodes/FailedNodes are never cleaned up.
Steps to Reproduce
Create a rule with nodeSelector: {tier: frontend} and taint readiness.k8s.io/frontend-ready:NoSchedule.
Label a node tier=frontend; once a required condition is False, the controller applies the taint.
Relabel the node: kubectl label node worker-1 tier=backend --overwrite.
Inspect worker-1.spec.taints — readiness.k8s.io/frontend-ready is still present even though the node no longer matches tier: frontend.
Expected Behavior
Ideally the taint gets removed and the node drops out of the rule's status once it stops matching. In practice this needs a reliable way for NodeReconciler to detect "used to match, no longer does" without depending on rule.Status as the signal for what to act on, since the controller's own previously-written status isn't a trustworthy basis for deciding what action to take next (a first attempt at this in #339 did exactly that, and @ajaysundark flagged it as fragile in review).
The straightforward alternative — have NodeReconciler evaluate all rules (not just currently-matching ones) on every node update, so it can catch "still has a managed taint but no longer matches" — works, but is expensive, especially with the extra status writes it implies for every node event.
If a manual relabel (e.g. via script) causes this, removing the taint could reasonably be handled by the same script/automation rather than the controller. dry-run mode also exists to catch this kind of misconfiguration before it happens.
What happened?
Split out of #338 per @ajaysundark's review comment: when a node's labels change so it no longer matches a
NodeReadinessRule'sspec.nodeSelector,NodeReconcilersimply stops seeing the rule as applicable viagetApplicableRulesForNodeand moves on. Any taint that rule previously applied to the node is never removed, and the node's stale entries inrule.Status.NodeEvaluations/AppliedNodes/FailedNodesare never cleaned up.Steps to Reproduce
nodeSelector: {tier: frontend}and taintreadiness.k8s.io/frontend-ready:NoSchedule.tier=frontend; once a required condition isFalse, the controller applies the taint.kubectl label node worker-1 tier=backend --overwrite.worker-1.spec.taints—readiness.k8s.io/frontend-readyis still present even though the node no longer matchestier: frontend.Expected Behavior
Ideally the taint gets removed and the node drops out of the rule's status once it stops matching. In practice this needs a reliable way for
NodeReconcilerto detect "used to match, no longer does" without depending onrule.Statusas the signal for what to act on, since the controller's own previously-written status isn't a trustworthy basis for deciding what action to take next (a first attempt at this in #339 did exactly that, and @ajaysundark flagged it as fragile in review).Controller Version / Image Tag
main(commit43bff46)Kubernetes Version
Not version-specific.
Additional Environment Details
Carried over from review discussion on #338/#339:
NodeReconcilerevaluate all rules (not just currently-matching ones) on every node update, so it can catch "still has a managed taint but no longer matches" — works, but is expensive, especially with the extra status writes it implies for every node event.dry-runmode also exists to catch this kind of misconfiguration before it happens.