Linux 上 Kubernetes 版本升级注意事项
一 升级前规划与兼容性
- 明确升级路径：遵循 Kubernetes 的N-2 支持策略，通常一次只升级一个次版本（例如从 v1.28.x → v1.29.y），严禁跨多个小版本或跨大版本直接升级。升级前在测试环境演练完整流程。
- 组件与运行时：确保 kubelet/kubeadm/kubectl 与目标版本一致；如使用 Docker，注意 v1.24 起移除 dockershim，需迁移到 containerd 等受支持的容器运行时。
- 系统依赖：确认 Linux 内核与所需特性（如 cgroup v2）满足新版本要求；保持 kube-proxy 版本 ≤ kube-apiserver。
- 高可用与流量：若为 HA 控制面，前置 HAProxy/Keepalived 等负载均衡，升级时暂时摘除待升级的 API Server 后端，避免业务中断。
- 备份与变更窗口：备份关键数据与配置（如 /etc/kubernetes/、/var/lib/etcd/，并用 etcdctl 备份 etcd），选择低峰时段，准备回滚方案与回滚窗口。
二 标准升级流程要点
- 控制平面节点（HA 依次逐台）
- 检查状态：
kubectl get nodes；2) 升级 kubeadm 并查看计划：kubeadm upgrade plan；
- 执行升级：
kubeadm upgrade apply <目标版本>（可按需设置日志级别如 --v=5）；
- 如暂不续期证书：
--certificate-renewal=false；5) 升级 kubelet/kubectl 并重启：systemctl daemon-reload && systemctl restart kubelet。
- 工作节点（逐台）
- 排空节点：
kubectl drain <node> --ignore-daemonsets；
- 升级 kubelet/kubectl 并重启：
systemctl daemon-reload && systemctl restart kubelet；
- 恢复调度：
kubectl uncordon <node>。
- 升级后验证：检查节点与系统组件状态、Pod 分布与事件日志，确认无异常。
三 常见风险与规避
- 单节点或单副本业务：无法在驱逐后调度，业务会中断；需提前扩容副本或采用 PodDisruptionBudget、反亲和等策略降低影响。
- 证书与 API 变化：升级会触发 kubeadm 管理的证书自动续期（可关闭）；跨版本可能引入 API 移除/变更，需提前评估并调整清单。
- 网络与存储插件：升级后可能需要更新 CNI/CSI/Ingress/监控等组件以适配新版本；升级前确认各组件的版本兼容矩阵。
- 节点角色混合：若节点同时是 Master/Worker，按控制面流程排空与升级，再恢复调度，避免控制面不可用。
四 升级后验证与回滚
- 快速健康检查：
- 节点与组件：
kubectl get nodes -o wide、kubectl get pods -A；
- 事件与日志：
kubectl describe nodes <node>、journalctl -u kubelet -xe；
- 控制面就绪：
kubectl get componentstatuses（如启用）。
- API 与清单适配：对受影响的资源用 kubectl convert 迁移到新 API 版本，并更新本地清单与 GitOps 仓库。
- 回滚策略：若
kubeadm upgrade apply 失败或异常，优先使用 kubeadm upgrade plan 输出的回滚指引或基于备份恢复 etcd 与控制面清单；回滚后按流程恢复节点调度与业务流量。