集群版本升级

Kubernetes 差不多每三个月出一个次版本（比如 1.35、1.36）。每个版本大约维护一年左右。升级这件事，躲是躲不过去的——老版本停止支持后，安全补丁和新特性都拿不到。

好消息是：Kubernetes 的升级设计得很克制，支持滚动升级，业务可以不中断。前提是你要按规矩来。

61-1 版本号与偏差策略

Kubernetes 版本格式是 x.y.z，即主、次、修订版本。项目只维护最近的三个次版本。不同组件之间允许有小幅偏差，但有硬规则：

• kube-apiserver 是基准。HA 集群里多个 apiserver 版本差不能超过一个次版本。
• kubelet 不能比 apiserver 新，最多比它旧三个次版本（1.25 之前的老 kubelet 只能旧两个）。
• 控制器管理器、调度器不能高于 apiserver，最多旧一个次版本。
• kubectl 可以跟 apiserver 差一个次版本。

这些规则是为了保证组件之间能正常通信。升级时务必先查官方版本偏差策略，别拍脑袋乱升。

61-2 升级顺序：先控制平面，后节点

从 1.n 升到 1.(n+1)，严格按这个顺序：

1. 先把 kube-apiserver 升到 1.(n+1)。升之前，其他控制组件和 kubelet 还停在 1.n，这是允许的。
2. 再升 kube-controller-manager、kube-scheduler，它们跟 apiserver 对齐到 1.(n+1)。
3. 最后升各节点的 kubelet，逐个节点滚动，期间 Pod 会被调度开，不中断服务。

为什么这个顺序？因为新 apiserver 要能兼容旧组件，而旧 apiserver 读不懂新组件的行为。先升”大脑”，再升”手脚”，是最稳的。

61-3 用 kubeadm 升级（概览）

kubeadm 集群的升级分两大块：控制平面节点、工作节点。

先在第一台控制平面节点上，查看可升级到的版本：

kubeadm upgrade plan

它会列出当前版本和可以升级的目标版本，顺便告诉你哪些组件会被升级。确认无误后，升级控制平面：

kubeadm upgrade apply v1.36.2

这条命令会升级 apiserver、控制器、调度器等静态 Pod 组件。完成后，记得把节点上的 kubelet 和 kubectl 也升到对应版本：

# 以你的包管理器为准，比如 apt
apt-get update && apt-get install -y kubelet=1.36.2-00 kubectl=1.36.2-00
systemctl daemon-reload
systemctl restart kubelet

61-4 升级工作节点

控制平面升完后，再逐个升工作节点。先排空一个节点，把上面的 Pod 挪走：

kubectl drain <节点名> --ignore-daemonsets --delete-emptydir-data

到该节点上升 kubelet：

apt-get update && apt-get install -y kubelet=1.36.2-00
systemctl daemon-reload
systemctl restart kubelet

确认节点 Ready 后，解除排空，让它重新接收调度：

kubectl uncordon <节点名>

逐个节点重复，直到全集群升完。多个工作节点可以错峰进行，保证总有节点扛着流量。

61-5 升级前的检查清单

动手前，这几件事先确认：

• 已备份 etcd。升级出意外时，这是你唯一的退路。
• 确认所有注册的准入 Webhook（Validating/Mutating）支持新版本的特性，否则可能拦截新请求。
• 读一遍目标版本的发布说明，留意废弃（deprecated）的 API。比如旧版有些 apiVersion 在新版被移除，相关 YAML 要先改。
• 确认 kubeadm、kubelet 版本与目标的 Kubernetes 版本匹配。

61-6 托管服务的升级

如果你用的是 EKS、GKE、AKS 这类托管服务，控制平面和 etcd 的升级通常由厂商帮你做，你点几下就能把控制平面升上去。但工作节点池的升级、以及你的业务对新版本的兼容性测试，仍然要你自己负责。

一句话：升级不可怕，可怕的是不按版本顺序、不备份。把 etcd 备份好、按”先大脑后手脚”的顺序走，升级就是一次平静的操作。