在Kubernetes（K8s）中，高可用（High Availability, HA）集群架构的核心目标是消除单点故障，确保集群在部分组件或节点故障时仍能正常运行。其架构设计围绕“控制平面高可用”和“数据平面高可用”展开，其中控制平面（集群的“大脑”）的高可用是核心，因为它直接影响整个集群的管理能力。
高可用集群的核心设计原则
- 无单点故障：所有核心组件（如API Server、etcd、调度器等）均部署多个实例，避免单个实例故障导致集群瘫痪。
- 数据一致性：集群状态数据库（etcd）需通过分布式协议（如Raft）保证数据一致，即使部分节点故障也能正常读写。
- 自动故障转移：核心组件支持“领导者选举”，当主实例故障时，备用实例能自动接管工作。
- 冗余通信链路：控制平面与工作节点、组件之间的网络通信需冗余，避免网络单点故障。
高可用集群架构详解
一个完整的K8s高可用集群包括控制平面层、etcd集群、负载均衡层、工作节点层，各部分协同实现高可用：
1. 控制平面层（Control Plane）
控制平面是集群的管理中心，包含多个核心组件，需部署多个实例（通常3个节点，形成奇数集群，便于选举）：
| 组件 | 作用 | 高可用部署方式 |
|---|---|---|
| API Server | 所有操作的入口（REST API），负责接收请求、验证并转发给其他组件。 | 部署多个实例（如3个），通过负载均衡器（如HAProxy）分发流量，无状态设计，可水平扩展。 |
| kube-scheduler | 负责Pod调度到合适节点。 | 部署多个实例，通过“领导者选举（Leader Election）”机制确保仅1个实例活跃（主），其他备用，主故障时备用自动接管。 |
| kube-controller-manager | 运行各种控制器（如Deployment、StatefulSet控制器），维护集群状态。 | 同调度器，多实例+领导者选举，确保只有1个主实例工作，避免状态冲突。 |
| 云控制器管理器（Cloud Controller Manager） | 对接云厂商服务（如负载均衡、存储）（仅云环境需要）。 | 多实例+领导者选举，同controller-manager。 |
2. etcd集群（分布式数据库）
etcd是K8s的“数据库”，存储集群所有状态（如Pod、Service、配置等），其高可用是集群稳定的核心：
- 部署方式：独立的etcd集群（推荐）或与控制平面共节点（简化部署），但需满足奇数节点数（至少3个）（如3、5个节点），通过Raft协议实现数据一致性和 leader 选举。
- 高可用原理：
- Raft协议确保只有1个leader节点处理写请求，follower节点同步数据；
- 允许最多
(n-1)/2个节点故障（如3节点集群可容忍1个节点故障，5节点可容忍2个）； - 若leader故障，剩余节点会重新选举新leader，保证数据读写不中断。
3. 负载均衡层（Load Balancer）
API Server是所有组件（如kubectl、kubelet、控制器）的通信入口，多实例部署时需通过负载均衡器统一入口：
- 作用：将客户端请求（如kubectl命令、kubelet上报状态）分发到多个API Server实例，实现流量均衡和故障转移（某API Server故障时，自动路由到健康实例）。
- 实现方式：
- 硬件负载均衡器（如F5）；
- 软件负载均衡器（如HAProxy、NGINX）；
- 云厂商负载均衡服务（如AWS ELB、阿里云SLB）。
4. 工作节点层（Worker Nodes）
工作节点是运行Pod的“计算资源”，其高可用通过多节点冗余和Pod调度策略实现：
- 多节点部署：至少2个工作节点，避免单个节点故障导致所有Pod不可用。
- Pod自愈：通过Deployment、StatefulSet等控制器管理Pod，当节点故障时，控制器会自动在健康节点上重建Pod。
- 网络插件：使用支持高可用的CNI插件（如Calico、Flannel），确保Pod跨节点通信稳定（如多节点网络冗余）。
5. 网络与安全
- 控制平面网络：控制平面节点之间、控制平面与etcd之间需保证低延迟、高可靠通信（建议专用网络），避免网络分区导致集群分裂。
- 证书与认证：所有组件间通信需通过TLS加密（如API Server与kubelet、etcd的通信），确保安全且身份可信。
高可用集群的典型拓扑（3控制平面+3etcd+2工作节点）
[客户端] → [负载均衡器（HAProxy）] ↓
[控制平面节点1] ←→ [控制平面节点2] ←→ [控制平面节点3] (API Server、scheduler、controller-manager) ↓
[etcd节点1] ←→ [etcd节点2] ←→ [etcd节点3] （Raft集群） ↓
[工作节点1] ←→ [工作节点2] （运行Pod，通过kubelet与API Server通信）
高可用保障机制
- 领导者选举：scheduler、controller-manager等组件通过etcd实现分布式锁，确保同一时间只有1个主实例工作，避免“脑裂”。
- 自愈能力：
- 节点故障时，kubelet与API Server通信中断，控制器会将该节点上的Pod标记为“Unknown”并在其他节点重建；
- API Server故障时，负载均衡器自动将流量路由到健康实例；
- etcd leader故障时，剩余节点快速选举新leader，数据读写不中断。
- 状态同步：所有组件通过API Server和etcd同步集群状态，确保多实例间状态一致。
总结
K8s高可用集群的核心是控制平面多实例+etcd集群+负载均衡，通过“冗余部署”“领导者选举”“数据一致性协议”实现无单点故障。实际部署中，控制平面和etcd节点数建议为3（最小高可用配置），工作节点数根据业务规模扩展，同时需保证网络可靠和安全通信。这种架构能容忍部分节点或组件故障，确保集群持续可用。