Kubernetes 版本升级是什么
K8s 集群的补丁与版本升级遵循「逐个小版本前进」的原则，不能跳版本；执行顺序是先控制面（逐台 master），再逐节点升级 kubelet。kubeadm 提供 upgrade plan 与 upgrade apply 完成大部分工作，但节点侧的腾空（drain）、组件重启与恢复调度（uncordon）仍需人工按批次控制。
基本信息
| 升级单位 | 小版本（如 1.30 → 1.31），不跳版 |
|---|---|
| 执行顺序 | 控制面 → 逐节点 kubelet → 观察工作负载 |
| 版本偏差 | 各组件间版本偏差需遵循官方 skew 策略 |
| 回退难度 | 控制面升级回退困难，必须先确认 etcd 备份可恢复 |
控制面与节点升级命令
控制面与节点升级命令
kubeadm upgrade plan # 查看可升级版本与组件清单
kubeadm upgrade apply v1.31.x # 控制面升级（逐台 master 执行）
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data # 节点腾空
kubeadm upgrade node # 节点侧升级
systemctl restart kubelet # 重启 kubelet 加载新版本
kubectl uncordon <node> # 验证工作负载正常后恢复调度典型使用场景
- 季度维护窗口：按官方支持周期规划并逐个版本推进
- 安全更新：跟随安全公告中已修复的组件版本升级
- API 弃用应对：kubeadm plan 会提示被弃用与移除的 API，提前改造工作负载
- 托管集群比对：云上控制面已升级时，本地节点池需跟随保持一致
- 升级演练：先在测试集群跑一遍完整流程与回滚验证
各阶段检查项
| 阶段 | 检查内容 | 风险点 |
|---|---|---|
| 升级前 | etcd 备份、插件兼容、弃用 API 清单 | 备份未验证可恢复 |
| 控制面 | 逐台执行并确认静态 Pod 正常 | 多 master 同时操作导致短时不可用 |
| 节点 | drain 后确认 Pod 已迁移或重建 | 忽略非受控 Pod 导致业务中断 |
| 升级后 | 工作负载健康、网络与存储插件正常 | CNI/CSI 插件版本不匹配 |
升级前确认已安装的 API 版本弃用清单（kubeadm plan 会提示），避免工作负载因 API 移除而无法部署或滚动更新。
控制面升级属于难以回退的操作：先确认 etcd 备份可恢复并做过恢复演练，再开始升级，否则出问题时可能只能重建集群。