上一篇【第80篇】K8s的CI/CD最佳实践——从代码到生产环境的“自动扶梯“下一篇【第82篇】K8s备份和灾备——etcd备份、Velero和集群恢复摘要K8s差不多每季度发一个小版本x.Y.z的Y不升级就会落后、有安全漏洞、新特性用不了。但升级生产集群像**“给飞行中的飞机换引擎”**——一步错全线崩。好消息是K8s的版本设计让升级可以滚动完成先升控制平面再升节点每个组件逐个来业务Pod基本不中断。这篇文章讲清版本偏差策略各组件版本差限制、升级前必做的准备备份etcd、查弃用API、kubeadm控制平面升级、节点滚动升级以及常见故障处理。一、版本偏差策略1.1 谁能比谁高多少【K8s 版本偏差规则(必须遵守!)】 kube-apiserver 是最高的: • apiserver 比 其他控制平面组件 高最多 1 个minor • apiserver 比 kubelet 高最多 2 个minor • apiserver 比 kubectl 高最多 1 个minor 记忆口诀: apiserver ≥ controller-manager scheduler (差≤1) apiserver ≥ kubelet (差≤2) apiserver ≥ kubectl (差≤1) ⚠️ 所以升级顺序: 先升apiserver, 再升其他, 最后升kubelet 绝不能先把kubelet升得比apiserver高!要点版本偏差规则保证了老组件能和新apiserver对话。比如apiserver是v1.29kubelet可以是v1.29/1.28/1.27差≤2但不能是v1.26差3不支持。升级时严格遵循控制平面先、节点后且一次只升一个minor版本——不能跨版本跳v1.24直接到v1.29会翻车要1.24→1.25→1.26…逐个来。二、升级前准备2.1 必做三件事【升级前检查清单】 1. 备份 etcd (最重要! 第082篇详讲) etcdctl snapshot save ... → 升级翻车还能恢复 2. 检查弃用/移除的API kubeadm upgrade plan 会提示 或用 pluto 工具扫manifest: pluto detect-files -d ./manifests → 把用了v1beta1 Ingress等旧API的先改掉 → 否则升级后这些资源直接失效 3. 看release notes的breaking changes • 哪个flag被移除? • 哪个默认行为变了? • 我的组件(CSI/CNI)兼容新版本吗?# 用kubeadm看升级计划(不实际升级)kubeadm upgrade plan# [upgrade/config] Making sure the configuration is correct# [upgrade/versions] Target version: v1.29.0# [upgrade/versions] Latest version in the v1.28 series: v1.28.4# Components to upgrade:# - kube-apiserver# - kube-controller-manager# - kube-scheduler# - kube-proxy# Your current version is v1.28.4, target is v1.29.0# ✅ 确认只差1个minor → 可以升三、控制平面升级3.1 第一个控制节点# 1. 升级kubeadmapt-getupdateapt-getinstall-ykubeadm1.29.0-00# 2. 看计划确认kubeadm upgrade plan# 3. 执行控制平面升级(第一个master)kubeadm upgrade apply v1.29.0# 会依次升级: apiserver → controller-manager → scheduler → kube-proxy# 4. 升级kubelet和kubectlapt-getinstall-ykubelet1.29.0-00kubectl1.29.0-00 systemctl restart kubelet# 5. 确认节点Readykubectl get nodes# master1 Ready v1.29.0 ← 第一个控制节点升好了3.2 多控制节点【多master的升级顺序】 master1 (第一个): kubeadm upgrade apply (升整个控制平面) master2: kubeadm upgrade node (只升级本节点组件) master3: kubeadm upgrade node → 注意: 只有第一个master用 apply (它会升共享的控制平面) → 其余master用 upgrade node (只升自己) → 过程中有master始终可用(高可用!)四、工作节点滚动升级4.1 逐个排空再升级【节点升级 排空 升级 恢复】 对每台worker节点: 1. kubectl cordon node-x # 标记为不可调度(新Pod不来) 2. kubectl drain node-x # 驱逐现有Pod(自动调度到其他节点) --ignore-daemonsets # DaemonSet不用管 --delete-emptydir-data # 清emptyDir数据(谨慎!) 3. 在node-x上升级kubelet: apt-get install -y kubelet1.29.0-00 systemctl restart kubelet 4. kubectl uncordon node-x # 恢复可调度 → 逐台做, 集群始终有节点能跑Pod → 配合Deployment的多副本(第013篇), 业务不中断# 升级第一个workerkubectl cordon node-1 kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data--force# (在node-1上) 升级kubeletsshnode-1apt-get install -y kubelet1.29.0-00 systemctl restart kubeletkubectl uncordon node-1# 重复对node-2, node-3...要点节点升级的关键是cordon→drain→升级→uncordon四步逐台进行。drain会把Pod优雅驱逐走PreStop Hook第035篇到其他节点。配合Deployment多副本PDBPodDisruptionBudget保证驱逐期间服务不丢容量。绝不能一次性cordon所有节点——那集群就空了。五、常见升级故障5.1 排错速查现象原因处理upgrade plan报错版本差太大跨版本跳只能逐minor升kubelet起不来配置文件格式变看journalctl -u kubelet按提示调某些Pod一直Pending用了移除的APIpluto查改manifest升级后网络不通CNI不兼容新版本升Calico/Cilium到兼容版etcd起不来升级中数据损坏用升级前快照恢复(第082篇)# 升级中kubelet异常, 看日志journalctl-ukubelet-n100--no-pager# 常见: flag --xxx has been deprecated/removed# → 编辑 /etc/kubernetes/kubelet.conf 或 /var/lib/kubelet/config.yaml 去掉旧flag六、托管集群的升级【云上托管集群(EKS/GKE/AKS)省心】 • 控制平面: 云厂商自动升(你点确认) • 节点: 节点池滚动升级(托管) • 你只需: 1. 确保用了托管版兼容的CSI/CNI 2. 处理弃用API(用pluto扫) 3. 点升级按钮, 等它滚完 • 风险比自建小得多本篇小结K8s升级要守版本偏差规则apiserver最高kubelet差≤2、kubectl差≤1且逐个minor升、不跨版本跳。升级前必做三件事备份etcd保命、用kubeadm plan/pluto查弃用API、读release notes的breaking change。流程控制平面先第一个master用upgrade apply其余用upgrade node工作节点后cordon→drain→升kubelet→uncordon逐台滚。故障多是跨版本跳、旧API、CNI不兼容。托管集群EKS/GKE控制平面自动升风险小。下篇讲备份灾备——etcd快照和Velero。上一篇【第80篇】K8s的CI/CD最佳实践——从代码到生产环境的“自动扶梯“下一篇【第82篇】K8s备份和灾备——etcd备份、Velero和集群恢复