在多数生产环境中，多主控制面高可用的最优拓扑，是把控制面组件分布在多个节点上，etcd保持奇数节点并形成多数派，前端统一由无状态负载均衡器收口，把这条链路想清楚，再去看具体的部署工具,思路会清晰很多。
多主控制面高可用部署方案的三层拓扑结构
多主控制面高可用部署方案，表面上是多台 master 节点，实际上是在解决三个独立问题：API Server如何水平扩展、etcd如何保证强一致、调度器和控制器管理器如何避免脑裂,这三个问题分别对应拓扑设计中的三个层面。
etcd 层：奇数节点是拓扑的第一条铁律
etcd 是整个集群唯一保存状态的地方，所有控制面组件都围绕它工作，它基于 Raft 协议达成共识，任何一条数据写入,都需要超过一半的节点确认。
拓扑设计要做的第一件事，就是保证 etcd 节点的数量是奇数，3节点容忍1个故障，5节点容忍2个故障，4节点的容错能力并不会比3节点高，单纯增加偶数节点只会增加同步开销，据CNCF公开文档，etcd 官方对集群部署的建议始终围绕多数派与故障域展开。
API Server 层：多副本的真正价值在于无状态
API Server 本身不保存业务数据，每个副本都能独立处理请求，多个 API Server 存在的意义，不只是互为备份,而是给负载均衡器提供多个可用后端。
kubelet、kube-proxy、调度器、控制器管理器最终都要通过 API Server 通信，只要负载均衡器背后有两个以上健康的 API Server，控制面就不会因为某一台机器宕机而完全失去响应，这一层在拓扑上几乎没有限制,节点的网络连通性达标即可。
调度器与控制器管理器：选主机制决定拓扑弹性
这两个组件默认以多副本方式运行，通过 Kubernetes 内置的选主机制协调，同时只有一个实例在工作，另一个实例处于热备状态，拓扑上不需要额外设计，只要多副本能访问到 API Server 即可。
这三层结构明确了之后，“多主控制面高可用部署方案”的真实工作方式就清楚了：真正的冗余在于组件，而不在于节点数量，3台master节点之上跑3个etcd副本、3个API Server副本、2个调度器副本和2个控制器管理器副本,才算真正的高可用。
多 master 节点拓扑设计对比：三种主流方案怎么选
把多 master 节点拓扑设计对比放在一起看，当前主流方案主要有三种，它们之间的差异集中在 etcd 的部署位置上。
| 拓扑类型 | 节点分配 | 主要优势 | 主要代价 | 常见场景 |
|---|---|---|---|---|
| 单栈堆叠 | 3台节点，控制面与etcd同机 | 机器少，部署简单 | 资源竞争明显，故障域集中 | 中小规模集群、业务起步阶段 |
| 控制面与etcd分离 | 3台控制面 + 3台etcd | 故障隔离，性能稳定 | 机器成本翻倍 | 大规模生产集群、高写入负载 |
| 跨地域分布式 | 3个可用区各布一主，etcd跨地域 | 区域级容灾 | 写延迟上升，脑裂风险 | 多活场景、异地容灾演练 |
单栈堆叠：小规模集群的默认选项
单栈堆叠即 kubeadm 默认的支持方式，3台服务器就能拉起一套完整的高可用控制面，每台机器同时运行 etcd 和控制面组件，基础设施成本最低，如果你是首次尝试多主控制面，或者集群规模不大，这个方案能让你快速获得高可用能力,同时把运维复杂度压到最低。
分离部署：把性能余量留给 etcd
当集群规模变大、API请求量上升、etcd 的写入压力明显增加时，控制面组件与 etcd 争抢 CPU 和内存的问题就会暴露，把 etcd 迁移到独立节点，控制面和存储各自独占资源，性能表现更稳定，分离部署需要6台服务器起步，这也是生产环境中最常见的一种拓扑，如果你的容器云平台高可用架构三节点已经跑了一段时间且频繁出现 API Server 响应变慢,优先考虑这个方向。
跨地域分布式：可用性与延迟的博弈
把3个 master 节点分散到三个城市，看起来容灾能力很强，但 etcd 的写入请求需要多数派节点响应，跨地域的物理距离直接把往返延迟放大到几十甚至上百毫秒，每次写入都要等待最远的那个节点返回，多数情况下，跨地域拓扑带来的性能损耗远大于容灾收益，业内专家指出，etcd 节点之间的网络延迟是决定拓扑取舍的第一指标,跨地域方案只适合对数据一致性要求不敏感的特定业务。
kubernetes 控制面高可用有没有拓扑限制
有，而且限制相当明确，行业共识认为，etcd 集群应当部署在低延迟、高稳定性的网络环境中,这是任何工具和平台都无法绕开的前提。
跨可用区与跨地域，拓扑上是两回事
同城双可用区之间通常走光纤专线，延迟保持在毫秒级，这个距离对 etcd 的影响非常小，是值得推荐的多主拓扑，但跨地域就是另一个故事了：网络分区一旦发生，多数派节点之间无法通信，写入请求会持续失败，控制面进入只读状态，调度器停止工作，拓扑设计必须区分“跨可用区”和“跨地域”两个层次，跨可用区是日常高可用的合理选择,跨地域则是容灾级别的额外诉求。
偶数节点多花的钱，经常听个响
这是 etcd 部署中最容易被误解的地方，6节点etcd的冗余能力是容忍2个节点故障，5节点etcd的冗余能力同样是2个，多出来的那台机器，并没有把系统可靠性抬上一个台阶，反而增加了同步数据时的网络开销，与其纠结节点数量,不如把这台机器的预算花在负载均衡器的高可用配置上。
接入层本身，不能成为新的单点
很多团队搭好三个 master 节点之后，直接在其中一个节点上跑了 HAProxy，结果这个节点一宕，整个集群的入口全部瘫痪，负载均衡器必须独立于控制面节点，或者使用云厂商的 SLB 产品,让接入层自身的可用性不被控制面故障拖累。
从一台到多台：多主控制面高可用部署方案的上线路径
如果你已经有一个单节点集群，想平滑迁移到高可用架构，不必推倒重来，按下面的顺序操作,每一步都可以验证有效性。
第一步：先让 etcd 具备多数派能力
用 kubeadm 在现有集群上添加新的 etcd 节点，或者把现有单节点的 etcd 迁移到外部集群，执行 etcdctl endpoint health --cluster 确认所有节点状态为 healthy，然后手动停掉其中一个节点，尝试写入一条测试数据,确认多数派机制已生效。
第二步：添加控制面副本并入负载均衡
通过 kubeadm join 添加第二个、第三个 control-plane 节点，操作完成后执行 kubectl get pods -n kube-system 查看所有控制面组件，确认全部处于 Running 状态，然后把三个节点全部加入负载均衡器的后端服务器列表,开启健康检查。
第三步：统一接入层，观察稳定运行
把 kubelet 的启动参数和 kubeconfig 都指向负载均衡器的虚拟 IP，而不是某个具体节点，这个过程中可以逐步切流量，先在低峰期切换，观察一两天再完全摘掉旧的入口，执行 kubectl get nodes 和 etcdctl endpoint status 确认整体状态正常后,单节点入口就可以正式下线。
这套路径依赖组件冗余和多数派机制，不依赖特定云厂商，在私有云和物理机环境同样适用，高可用控制面需要几台服务器，答案其实很简单：堆叠模式3台起步，分离模式6台起步，再加上一层负载均衡器,具体的数字由业务规模和对故障域的容忍度共同决定。
多主控制面高可用部署方案常见问题
多主控制面高可用部署方案需要几台服务器？
以大多数生产集群的实际规模来看，3台是最低配置，每台节点同时运行控制面组件与 etcd，能够容忍任意1台节点故障，如果采用独立 etcd 的分离架构，至少需要6台，具体数量还要结合节点规格、Pod 密度和可用区数量来定。
三节点堆叠部署和六节点分离部署，哪个更省心？
堆叠部署的维护成本明显更低，系统升级和证书续期只需处理三台机器，分离部署要维护两套节点组，但换来的是 etcd 性能稳定性明显提升，多数团队会先用堆叠部署完成业务上线,等出现控制面响应变慢后再做拆分。
负载均衡器挂了，多主控制面还有救吗？
控制面组件仍然在运行，但 kubelet、kubectl 和调度器都无法访问 API Server，整个集群实际上变成了一个不可管理的状态，因此负载均衡器的可用性直接决定多主控制面的最终可用性，负载均衡器层面的健康检查频率决定 API Server 故障转移的速度，检查间隔越短,控制面恢复越快。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/644118.html
