别再被升级背刺了：控制平面 HA 才是“零停机”的真正底气

别再被升级背刺了：控制平面 HA 才是“零停机”的真正底气

一、先泼一盆冷水：

大多数“零停机升级”，其实只是“用户没骂你”

很多方案写得很漂亮：

• 滚动升级
• 蓝绿
• 灰度
• 不影响业务

但真正的事故往往是：

• API Server 抖了一下
• Controller 选主失败
• etcd 一次小脑裂

然后——
业务没挂，但整个集群“半身不遂”

你会发现一个残酷事实：

你以为你在升级 worker，实际上你是在和控制平面拼命

二、为什么“控制平面 HA”比你想的重要得多？

很多人对 HA 的理解还停留在：

“多起几台 master 就行了吧？”

但控制平面不是 nginx，它有三件特别脆弱的事：

1. 强依赖一致性（etcd）
2. 有选主机制（controller / scheduler）
3. 是所有操作的“单点入口”

一句话总结：

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 是退路
• 滚动是退路
• 回滚是退路

没有退路的系统，
迟早会在某个凌晨把你叫醒。