LinuxKubernetes集群升级教程_平滑升级与风险控制

升级前须检查版本兼容性、备份核心资源与 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 –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 转发）是否持续工作