升级前须检查版本兼容性、备份核心资源与etcd快照；分阶段滚动升级控制平面节点；工作节点需驱逐后升级并观察指标；升级后验证API资源、事件、CRD、Ingress及监控链路。
升级前必须做的三件事
不检查就升级等于埋雷。先确认当前集群版本、各组件兼容性，再备份核心资源对象和etcd数据。用red">kubectl version和kubeadm version核对控制平面与节点版本差异；运行kubectl get nodes -o wide查看kubelet实际版本；用etcdctl snapshot save生成快照并验证可恢复性——这一步跳过，出问题基本只能重建。
分阶段滚动升级控制平面节点
控制平面不能全停，必须逐台升级master节点。先升级主控节点（如master-0），再升级其余master。每台操作顺序固定：
- 执行kubeadm upgrade plan确认可用目标版本
- 运行kubeadm upgrade apply v1.x.y升级kubeadm/kubelet/kubectl
- 重启kubelet：systemctl restart kubelet
- 等待kubectl get nodes显示Ready且VERSION列更新
- 检查核心系统Pod（coredns、etcd、kube-apiserver）是否全部Running且无重启
工作节点升级要避开业务高峰
节点升级本质是驱逐+重启，必须控制影响范围。用kubectl drain <node> --ignore-daemonsets --delete-emptydir-data安全驱逐，确保应用有多个副本且配置了pod disruption budget。升级kubelet后记得systemctl daemon-reload && systemctl restart kubelet，再kubectl uncordon放行调度。建议一次只处理1–2个节点，观察监控指标（CPU、延迟、5xx错误率）稳定后再继续。
升级后必须验证的五项关键检查
版本数字变了不等于跑得稳。重点验证：
- kubectl api-resources输出是否完整，有无API组缺失
- kubectl get events --all-namespaces里有没有Warning或Error事件
- 自定义资源（CRD）对应Operator是否仍在正常协调
- Ingress控制器路由是否生效，Service类型为LoadBalancer的External IP是否重新分配成功
- 日志采集、监控、告警链路（如Prometheus抓取、Fluentd转发）是否持续工作
