升级要先讲顺序
集群升级的基本顺序是先进控制面、后升级节点，且要逐个小版本推进，不能跨多个小版本一次跳。组件版本存在偏差约束：节点组件不能比接口服务更新，且只能落后有限的小版本。理解这两条，绝大多数升级事故都能提前避免。
基本信息
| 适用平台 | 自建集群（kubeadm 等工具），托管集群由云厂商提供升级入口 |
|---|---|
| 升级顺序 | 控制面组件先升，节点组件后升 |
| 版本步进 | 每次只升一个小版本，逐次推进 |
| 偏差约束 | 节点组件不得高于接口服务组件 |
| 前置动作 | 备份数据、检查废弃接口使用情况、确认副本冗余 |
升级前的必查项
- 数据后端快照已备份并校验可读
- 废弃接口清单：确认现有清单没有使用将被移除的接口版本
- 关键工作负载的副本数与中断预算能承受滚动重启
- 组件兼容矩阵：网络、存储、监控等插件是否支持目标版本
- 回退方案：明确回退到哪个版本以及数据如何处理
典型路径（kubeadm 环境示意）
典型路径（kubeadm 环境示意）
kubeadm upgrade plan # 查看可升级目标与提示
# 控制面节点：升级管理工具 → 应用升级 → 升级节点组件与命令行工具
kubectl drain node1 --ignore-daemonsets --delete-emptydir-data # 腾空待升级节点
# 节点：升级节点组件后重启服务
kubectl uncordon node1 # 恢复调度
kubectl get nodes -o wide # 确认版本与状态一致阶段与风险
| 阶段 | 关键动作 | 风险点 |
|---|---|---|
| 预检 | 查看升级计划与提示 | 忽略废弃接口提示 |
| 控制面 | 逐个升级控制面节点 | 同时操作多个节点可能失去多数派 |
| 节点 | 腾空、升级、恢复调度 | 容量不足导致副本无法重排 |
| 验证 | 确认版本与工作负载状态 | 只看节点就绪，未验证业务 |
工作负载自身的不兼容改动往往比集群升级本身更容易出问题：滚动重建时新版本容器要能正常启动，否则升级过程中会出现大面积不可用。
跨多个小版本一次性升级不符合版本偏差策略，组件之间无法互操作，出问题的概率极高。控制面节点也不应同时全部操作，否则可能失去多数派。