在K8S中,高可用集群架构是什么样?
在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(最小高可用配置),工作节点数根据业务规模扩展,同时需保证网络可靠和安全通信。这种架构能容忍部分节点或组件故障,确保集群持续可用。