2. K8s 集群高可用架构：控制平面高可用、etcd 集群部署、多 Master 节点设计
生产级 Kubernetes 集群必须消除单点故障。控制平面组件（API Server、Controller Manager、Scheduler）以及 etcd 数据存储是高可用的核心关注点。本章将深入剖析多 Master 节点设计、etcd 集群部署策略以及控制平面组件的选主与负载均衡机制。
2.1 高可用架构总览
K8s 高可用架构的核心原则是：无单点故障、组件冗余、数据一致性。一个典型的高可用集群包含以下关键设计：
- 多 Master 节点：至少 3 台 Master 节点，运行控制平面组件。
- etcd 集群：独立或与 Master 节点混合部署，奇数节点（3/5/7）保证 Raft 共识。
- 负载均衡器：前置 L4 负载均衡器（如 HAProxy、Nginx、云厂商 LB）分发 API Server 请求。
- 组件选主：Controller Manager 和 Scheduler 通过 leader election 实现 Active-Standby。
架构要点： 控制平面高可用 ≠ 所有组件同时工作。API Server 是无状态的，可水平扩展；Controller Manager 和 Scheduler 有状态，通过租约（Lease）机制选举 Leader，只有 Leader 执行实际逻辑。
2.2 控制平面组件高可用设计
2.2.1 API Server 水平扩展
API Server 是控制平面的入口，所有管理请求（kubectl、Controller、Scheduler）都通过它。API Server 本身是无状态的，所有数据都存储在 etcd 中。因此，可以通过部署多个 API Server 实例并前置负载均衡器来实现高可用。
| 组件 | 高可用方式 | 关键配置 |
|---|---|---|
| kube-apiserver | 水平扩展 + L4 负载均衡 | --advertise-address 指向本机 IP；所有实例连接同一 etcd 集群 |
| kube-controller-manager | Leader Election（选主） | --leader-elect=true；--leader-elect-lease-duration=15s |
| kube-scheduler | Leader Election（选主） | --leader-elect=true；--leader-elect-lease-duration=15s |
实践建议： 负载均衡器建议使用 TCP 四层转发（L4），不要做 TLS 终止。API Server 的证书验证应在客户端完成，避免 LB 成为性能瓶颈或安全风险点。
2.2.2 Controller Manager 与 Scheduler 选主机制
Controller Manager 和 Scheduler 是有状态组件，同一时刻只能有一个实例执行逻辑。它们通过 Kubernetes 内置的 Lease（租约） 机制实现选主：
- 所有实例启动时尝试创建/更新一个 Lease 对象（位于 kube-system 命名空间）。
- 第一个成功更新 Lease 的实例成为 Leader，定期续约（默认每 10 秒）。
- 其他实例处于 Standby 状态，持续监听 Lease 对象。
- 当 Leader 失联（超过 lease-duration，默认 15 秒），Standby 实例竞争成为新 Leader。
2.3 etcd 集群部署
etcd 是 K8s 的“大脑”，存储所有集群状态。etcd 集群的高可用直接决定整个集群的可靠性。etcd 使用 Raft 共识算法，要求集群中多数节点（Quorum）存活才能正常服务。
2.3.1 节点数量与容错能力
| 集群大小 | 最大故障节点数 | Quorum（多数） | 推荐场景 |
|---|---|---|---|
| 1 | 0 | 1 | 开发/测试 |
| 3 | 1 | 2 | 生产环境（最小推荐） |
| 5 | 2 | 3 | 大规模生产/跨可用区 |
| 7 | 3 | 4 | 超大规模/极端可靠性 |
重要警告： etcd 集群节点数必须为奇数。偶数节点（如 2、4、6）在故障时可能无法形成多数，导致集群不可用。例如 2 节点集群故障 1 台后只剩 1 台，无法达到 Quorum（2），集群立即失效。
2.3.2 部署模式对比
| 部署模式 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| Stacked（堆叠） | etcd 与 Master 组件部署在同一节点 | 节省机器资源；部署简单 | etcd 与 Master 争抢资源；Master 故障同时丢失 etcd 成员 |
| External（外部） | etcd 集群独立部署在专用节点 | 资源隔离；etcd 性能稳定；Master 故障不影响 etcd | 需要额外机器；网络延迟略高 |
生产建议： 对于核心生产集群，强烈推荐使用 External 模式。将 etcd 部署在独立的 3 台高性能服务器上（SSD 磁盘、充足内存、低延迟网络），与 Master 节点物理隔离。这可以避免 Master 节点故障时 etcd 成员同时丢失，提高整体可靠性。
2.4 多 Master 节点设计关键步骤
以下是一个典型的多 Master 节点部署流程（以 kubeadm 工具为例）：
- 准备基础设施：至少 3 台 Master 节点（2C4G+）、3 台 etcd 节点（可选 External 模式）、1 台负载均衡器。
- 部署 etcd 集群：配置 TLS 证书、初始集群成员、数据目录。确保节点间网络互通（端口 2379/2380）。
- 初始化第一个 Master 节点：使用
kubeadm init指定 etcd 端点（External 模式）或自动部署 Stacked etcd。 - 加入其他 Master 节点：使用
kubeadm join --control-plane命令，传入第一个节点的证书和 API Server 地址。 - 配置负载均衡器：将 LB 后端指向所有 Master 节点的 6443 端口，配置健康检查。
- 验证集群状态：
kubectl get nodes确认所有 Master 节点 Ready；kubectl get componentstatuses检查控制平面组件健康。
关键命令示例： 加入控制平面节点时，需要从第一个 Master 节点获取证书哈希和 ：
# 在第一个 Master 节点执行
kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:6443" \
--upload-certs \
--apiserver-advertise-address 0.0.0.0
# 在其他 Master 节点执行
kubeadm join LOAD_BALANCER_DNS:6443 \
-- <> \
--discovery--ca-cert-hash sha256:<hash> \
--control-plane \
--certificate-key <cert-key>2.5 高可用架构验证清单
| 验证项 | 预期结果 | 验证方法 |
|---|---|---|
| API Server 负载均衡 | 停止任一 Master 的 API Server，kubectl 仍可正常使用 | systemctl stop kube-apiserver；kubectl get nodes |
| Controller Manager 选主 | 停止 Leader 节点，Standby 节点在 15s 内接管 | kubectl get leases -n kube-system；观察 leader 变化 |
| etcd 集群容错 | 停止一个 etcd 成员，集群仍可读写 | etcdctl endpoint health；写入/读取测试 |
| 节点故障恢复 | 故障节点恢复后自动加入集群 | 重启节点；kubectl get nodes 状态恢复 Ready |
常见陷阱：
- etcd 集群节点数不要超过 7 个，否则写入性能会因 Raft 日志复制而显著下降。
- 所有 Master 节点的 kubelet 证书必须由同一 CA 签发，否则节点间通信会失败。
- 负载均衡器必须支持 TCP 健康检查（如 HAProxy 的 tcp-check），不要使用 HTTP 检查。