企业官网建设流程全解析

上一篇【第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.29，kubelet可以是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-getupdate&&apt-getinstall-ykubeadm=1.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-ykubelet=1.29.0-00kubectl=1.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 kubelet=1.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-1'apt-get install -y kubelet=1.29.0-00 && systemctl restart kubelet'kubectl uncordon node-1# 重复对node-2, node-3...

要点：节点升级的关键是cordon→drain→升级→uncordon四步，逐台进行。drain会把Pod优雅驱逐（走PreStop Hook，第035篇）到其他节点。配合Deployment多副本+PDB（PodDisruptionBudget），保证驱逐期间服务不丢容量。绝不能一次性cordon所有节点——那集群就空了。

五、常见升级故障

5.1 排错速查

# 升级中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和集群恢复