Kubernetes 1.36 apiserver /readyz now waits for watch cache

Test first. If you run production traffic, treat this as a control-plane behavior change, not a feature. should you care? verdict Yes, you should care. This changes when kube-apiserver admits it is ready, and your automation will notice. In my experience, the worst control-plane outages start with a “green” health check and a pile of controllers doing list+watch at the same time. This release nudges the apiserver toward honest readiness. That is good. It can still bite you if your probes or load balancer health checks assume startup always stays under 10 seconds. Upgrade stance: test in a disposable cluster first. Watch your apiserver readiness time, restart count, and error rates after deploying. What breaks first: aggressive liveness or external health checks that kill the apiserver before it finishes warming watch cache. What gets better: fewer “Ready but actually not ready” windows that trigger thundering-herd list+watch traffic. should you care? apiserver readiness waits for watch