在K8S中，高可用集群架构是什么样？

在Kubernetes（K8s）中，高可用（High Availability, HA）集群架构的核心目标是消除单点故障，确保集群在部分组件或节点故障时仍能正常运行。其架构设计围绕“控制平面高可用”和“数据平面高可用”展开，其中控制平面（集群的“大脑”）的高可用是核心，因为它直接影响整个集群的管理能力。

高可用集群的核心设计原则

1. 无单点故障：所有核心组件（如API Server、etcd、调度器等）均部署多个实例，避免单个实例故障导致集群瘫痪。
2. 数据一致性：集群状态数据库（etcd）需通过分布式协议（如Raft）保证数据一致，即使部分节点故障也能正常读写。
3. 自动故障转移：核心组件支持“领导者选举”，当主实例故障时，备用实例能自动接管工作。
4. 冗余通信链路：控制平面与工作节点、组件之间的网络通信需冗余，避免网络单点故障。

高可用集群架构详解

一个完整的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通信）  

高可用保障机制

1. 领导者选举：scheduler、controller-manager等组件通过etcd实现分布式锁，确保同一时间只有1个主实例工作，避免“脑裂”。
2. 自愈能力：
   • 节点故障时，kubelet与API Server通信中断，控制器会将该节点上的Pod标记为“Unknown”并在其他节点重建；
   • API Server故障时，负载均衡器自动将流量路由到健康实例；
   • etcd leader故障时，剩余节点快速选举新leader，数据读写不中断。
3. 状态同步：所有组件通过API Server和etcd同步集群状态，确保多实例间状态一致。

总结

K8s高可用集群的核心是控制平面多实例+etcd集群+负载均衡，通过“冗余部署”“领导者选举”“数据一致性协议”实现无单点故障。实际部署中，控制平面和etcd节点数建议为3（最小高可用配置），工作节点数根据业务规模扩展，同时需保证网络可靠和安全通信。这种架构能容忍部分节点或组件故障，确保集群持续可用。