Linux K8S版本升级需要注意什么

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 依次逐台）
  1. 检查状态：kubectl get nodes；2) 升级 kubeadm 并查看计划：kubeadm upgrade plan；
  2. 执行升级：kubeadm upgrade apply < 目标版本> （可按需设置日志级别如 --v=5）；
  3. 如暂不续期证书：--certificate-renewal=false；5) 升级 kubelet/kubectl 并重启：systemctl daemon-reload & & systemctl restart kubelet。
• 工作节点（逐台）
  1. 排空节点：kubectl drain < node> --ignore-daemonsets；
  2. 升级 kubelet/kubectl 并重启：systemctl daemon-reload & & systemctl restart kubelet；
  3. 恢复调度：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 与控制面清单；回滚后按流程恢复节点调度与业务流量。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！