Kubernetes Upgrades and Vulnerability Management

You upgrade kube-scheduler to 1.35 before the API server. The scheduler crashes on startup because it references API versions the 1.34 kube-apiserver doesn't serve. Pods stop scheduling. You roll back manually, but the cluster is now partially upgraded, and the version skew policy blocks a clean path forward.

This is the most common upgrade failure in kubeadm clusters. The fix is understanding the version skew policy and following the upgrade sequence exactly. You also need to know when to stop the API server for etcd upgrades, how to drain nodes without breaking DaemonSets, and how to verify with Trivy that the upgrade actually resolved the CVEs you're patching.