A certificate maintenance window completes and afterward node readiness or metrics become inconsistent despite successful kubelet rotation.
A kubelet certificate rotation succeeds and nodes still flip NotReady because the metrics server still trusts the old cluster CA bundle mounted from a stale config secret
Node auth is valid, yet health reporting breaks because one metrics component never consumed the updated trust bundle.
Scenario
What to check first
- Identify the primary failure signal in the The Node Rotated Cleanly and the Observer Kept Trusting the Previous World scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Trace trust bundle propagation into observability components before forcing node rejoin.
Questions worth viewing together
Community-field Kubernetes problem inspired by Kubernetes community cases where observers still trusted the old CA after node certificate rotation. Successful certificate rotation on the producer side does not guarantee every consumer refreshed trust.
Teams often blame kubelet rotation itself when the broken piece is an observer with stale trust material.
Cluster certificate maintenance should verify dependent trust consumers, not only the rotated component.
Similar cases seen in the field