Kubernetes 升级不是简单替换几个二进制文件。它同时涉及控制面、etcd、kubelet、kubectl、CNI、CSI、Ingress Controller、Webhook、CRD 和业务兼容性。可靠升级应当按版本逐级、按节点滚动，并且每一步都能验证和停止。
本文介绍通用流程。具体安装命令和目标版本必须使用“当前版本 → 下一版本”对应的 Kubernetes 官方升级文档。
一、先确认安装方式
不同集群的升级工具不同：
1. kubeadm 集群使用 kubeadm upgrade 流程。
2. 托管 Kubernetes 按云厂商控制面和节点池流程。
3. Kubespray、kOps、Cluster API 等使用各自工具。
4. 手工二进制集群需要独立升级控制面和节点组件。
不要把 kubeadm 命令直接用于非 kubeadm 集群。
二、不要跳过次版本
Kubernetes minor 版本应逐级升级，例如从 1.x 到 1.x+1，再到 1.x+2。直接跨越多个 minor 版本通常不受支持。
同时检查版本偏差策略：kubeadm、kubelet、API Server 和 kubectl 允许的版本差异并不相同。最稳妥的做法是让同一次升级使用官方文档推荐的匹配版本。
三、升级前检查清单
1. 阅读目标版本和中间版本 Release Notes。
2. 检查弃用或移除的 API。
3. 确认所有 Node 为 Ready，控制面健康。
4. 检查业务 Pod、PDB 和节点容量。
5. 备份 etcd，并验证快照。
6. 备份 /etc/kubernetes 和部署配置。
7. 确认 CNI、CSI、Ingress、监控和 Webhook 支持目标版本。
8. 确认镜像仓库和软件源可访问。
9. 准备维护窗口、负责人、停止条件和回滚方案。
10. 先在测试集群演练。
命令示例：
kubectl get nodes
kubectl get pods -A
kubectl get pdb -A
kubectl get --raw='/readyz?verbose'
kubeadm version
kubelet --version
kubectl version
四、检查 API 兼容性
升级前应查找仍在使用的旧 apiVersion、被移除字段和不兼容 CRD。只要 YAML 能在旧集群 apply，不代表它能在新版本继续工作。
除了业务清单，还要检查 Helm Chart、Operator、Admission Webhook 和自动化脚本。对受影响资源，先在旧集群迁移到新 API，再开始控制面升级。
五、升级第一个控制平面节点
通用顺序是：
1. 升级该节点上的 kubeadm。
2. 执行 kubeadm upgrade plan。
3. 确认计划、组件版本和检查结果。
4. 执行 kubeadm upgrade apply <TARGET_VERSION>。
5. 根据官方步骤升级 kubelet 和 kubectl。
6. 重启 kubelet并验证控制面。
命令形式：
sudo kubeadm upgrade plan
sudo kubeadm upgrade apply <TARGET_VERSION>
软件包安装命令因操作系统、仓库和目标版本而异，不能长期固定在文章里。应复制对应版本官方页面上的命令。
六、升级其他控制平面节点
多控制平面集群逐台操作。每台执行相应 kubeadm upgrade node 流程，升级 kubelet，然后验证该节点和静态 Pod。
任何时候都不要同时让所有 API Server 或 etcd 成员不可用。每完成一台，都应确认：
kubectl get nodes
kubectl get pods -n kube-system -o wide
kubectl get --raw='/readyz?verbose'
如果使用 stacked etcd，还要观察成员健康和 quorum。
七、升级工作节点
工作节点应一台或少量一批滚动升级，确保剩余容量可以承载被驱逐的业务。
先禁止调度并驱逐普通工作负载：
kubectl drain <NODE_NAME> \
--ignore-daemonsets \
--delete-emptydir-data
--delete-emptydir-data 会删除 Pod 的本地临时数据，使用前必须确认业务可以重建。PDB 也可能阻止驱逐，这是保护机制，不应随意绕过。
在节点上按官方流程升级 kubeadm、执行 kubeadm upgrade node，再升级 kubelet并重启。
验证后恢复调度：
kubectl uncordon <NODE_NAME>
然后再处理下一台节点。
八、升级期间的常见阻塞
1. kubeadm upgrade plan 失败：先解决控制面不可达、版本不匹配或配置问题。
2. drain 被 PDB 阻止：评估副本和可用性，不要直接强制删除。
3. Pod 无处调度：集群缺少冗余容量，先扩容或调整升级批次。
4. CNI/CSI 不兼容：停止升级，按厂商支持矩阵处理。
5. Webhook 阻止资源：检查证书、API 兼容和 failurePolicy。
6. 镜像拉取失败：检查 registry、代理和运行时配置。
7. 节点升级后 NotReady：检查 kubelet、容器运行时、cgroup 和证书。
九、升级后的验证
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get events -A \
--sort-by=.metadata.creationTimestamp
kubectl get --raw='/readyz?verbose'
还应验证：
1. CoreDNS 和集群 DNS。
2. Service、Ingress/Gateway 和外部入口。
3. CNI 网络和 NetworkPolicy。
4. CSI 挂载、PVC 和存储扩容。
5. 指标、日志、告警和审计。
6. HPA、CronJob、Operator 和 Webhook。
7. 关键业务读写链路。
8. 新建 Pod、滚动发布和节点重启。
十、升级与证书
kubeadm 的控制面升级流程可能更新接近过期的证书，但不能因此取消证书监控。升级前后仍应执行：
sudo kubeadm certs check-expiration
使用外部 CA 的集群，证书生命周期由外部流程负责。
十一、失败时怎么处理
升级失败后不要立即删除节点或重建 etcd。先保存输出、日志、静态 Pod 状态和 /etc/kubernetes/tmp 中的 kubeadm 备份。
kubeadm upgrade 具有一定幂等性，修复根因后通常可以重新执行。但是否回退软件包、恢复 etcd 或重建节点，取决于失败阶段和集群拓扑。
Kubernetes 不支持随意降级控制面和 etcd。所谓“回滚”必须在升级前设计并演练，不能把它理解为安装旧 RPM 或 DEB 包。
总结
安全升级的核心顺序是：检查兼容性 → 备份 → 升级第一个控制面 → 逐台升级其他控制面 → drain并升级工作节点 → 全链路验证。每一步都要有停止条件，绝不能跨版本、跨节点同时冒进。
参考资料：
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/