别再被升级背刺了：控制平面 HA 才是“零停机”的真正底气
一、先泼一盆冷水：
大多数“零停机升级”，其实只是“用户没骂你”
很多方案写得很漂亮：
- 滚动升级
- 蓝绿
- 灰度
- 不影响业务
但真正的事故往往是：
- API Server 抖了一下
- Controller 选主失败
- etcd 一次小脑裂
然后——
业务没挂，但整个集群“半身不遂”
你会发现一个残酷事实：
你以为你在升级 worker，实际上你是在和控制平面拼命
二、为什么“控制平面 HA”比你想的重要得多？
很多人对 HA 的理解还停留在：
“多起几台 master 就行了吧？”
但控制平面不是 nginx，它有三件特别脆弱的事：
- 强依赖一致性（etcd）
- 有选主机制（controller / scheduler）
- 是所有操作的“单点入口”
一句话总结：
worker 挂了，是业务问题；控制平面抖了，是系统性问题
三、一个不 HA 的控制平面，升级时会发生什么？
我们来模拟一个很真实的场景（Kubernetes 举例，但思想是通用的）。
❌ 单控制节点 + 升级
# 你满怀信心地执行
kubeadm upgrade apply v1.28.x
接下来可能发生：
- API Server 重启
- etcd 正在 compact
- kubelet 还在重连
5～30 秒内：
- 所有 kubectl 命令卡死
- HPA 不生效
- Controller 停止 reconcile
业务 Pod 可能还活着，
但整个系统已经“瞎了 + 聋了”。
四、真正的控制平面 HA，至少要满足三件事
1️⃣ etcd 必须是奇数节点
这是老生常谈，但事故年年发生。
❌ 2 节点 etcd（看起来省机器）
✅ 3 / 5 节点 etcd（能活下来）
etcd 的底层是 Raft：
活着的节点 > N/2，集群才能写
少一个都不行。
2️⃣ API Server 必须无状态 + 前面有 LB
API Server 本身是可以多实例的：
LB
├── apiserver-1
├── apiserver-2
└── apiserver-3
关键不是“起多少个”，而是：
- 所有实例版本一致
- 证书一致
- 配置一致
👉 API Server 是“横向扩展友好型组件”
3️⃣ Controller / Scheduler 只能有一个“在干活”
它们靠的是 leader election：
--leader-elect=true
你可以跑多个，但：
- 只有一个是真正的“主”
- 其他都是热备
这点在升级时非常关键。
五、零停机升级的核心思想：
永远只动“不会让系统失控”的那一部分
我给你一个运维人好记的顺序：
先边缘，后核心；先无状态，后有状态
六、一个可落地的控制平面升级顺序（重点）
✅ Step 1：确认 HA 状态是“健康的”
升级前，你要像医生体检一样：
# etcd 是否健康
etcdctl endpoint status --cluster
# 控制平面 Pod 是否分布在不同节点
kubectl get pod -n kube-system -o wide
不健康的 HA = 没资格谈零停机
✅ Step 2：先升级 API Server（滚动）
API Server 是最好升级的：
- 无状态
- 可并行
- 有 LB 扛着
示例思路（伪代码）：
# 逐台下线 + 升级 + 上线
for node in master_nodes:
cordon(node)
upgrade_apiserver(node)
uncordon(node)
关键点：
- LB 健康检查要准
- 不要一次全下
✅ Step 3：再升级 Controller / Scheduler
这一步最容易翻车。
正确姿势是：
- 观察当前 leader
- 优先升级非 leader 节点
# 看 leader 在哪
kubectl describe lease kube-controller-manager -n kube-system
先动“备胎”，
最后再动“司机”。
✅ Step 4：最后才是 etcd（最危险）
我直说一句大实话：
etcd 升级，99% 的事故都发生在“心急”
正确原则：
- 一次只动一个节点
- 确认集群恢复健康
- 再继续下一个
# 每动一次，都确认
etcdctl endpoint health --cluster
etcd 没完全恢复前，
什么都别干。
七、为什么很多“零停机方案”在现实中失败？
我总结过几个血泪原因：
1️⃣ 把 HA 当成“部署数量问题”
不是 3 台就叫 HA，
是 “任何一台挂了，系统还能保持理性”。
2️⃣ 升级顺序拍脑袋
很多人升级顺序是：
“看哪个先跳报警，就先搞哪个”
这是事故导向型运维。
3️⃣ 没有“随时回滚”的能力
零停机的前提不是“不会出错”，
而是：
出错了，能不能在 1 分钟内撤回
八、我自己的一个感受（说点真心话）
这些年我越来越相信一句话：
运维的高级感，不在于你能升级，而在于你敢升级
你敢不敢在：
- 高峰期
- 真实流量
- 不停机
的情况下升级控制平面？
如果你敢，
那说明你的 HA 设计是站得住的。
九、最后一句“运维黑话翻译成大白话”
零停机升级的本质，不是技术多牛，而是你有没有给系统留退路
- HA 是退路
- 滚动是退路
- 回滚是退路
没有退路的系统，
迟早会在某个凌晨把你叫醒。
