K8s高可用：Master与候选节点核心解析
在 Kubernetes 集群中，Master 节点（控制平面节点） 和 候选 Master 节点（Candidate Master） 是高可用（HA）架构中的关键角色，它们的核心区别在于 当前是否承担实际控制职责：
1. Master 节点（Active Master）
- 角色：当前激活的控制平面节点，实际处理集群管理任务。
- 职责：
- 运行核心组件：
kube-apiserver（集群入口）、kube-scheduler（调度 Pod）、kube-controller-manager（控制器循环）、etcd（存储集群状态）。 - 响应所有用户和管理请求（如
kubectl命令）。 - 监控节点状态，调度 Pod，维护集群状态一致性。
- 运行核心组件：
- 状态：唯一活跃的领导者（Leader），其他节点处于备用状态（高可用架构中通常只有 一个 Active Master）。
2. 候选 Master 节点（Standby/Candidate Master）
- 角色：高可用集群中的备用节点，处于待命状态，不处理实际请求（除非主节点故障）。
- 职责：
- 持续同步集群状态（从 Leader 的
etcd复制数据）。 - 运行相同的控制平面组件（API Server、Scheduler 等），但处于“待机模式”。
- 监控 Active Master 的健康状态（通过选举机制如
kube-controller-manager的领导者选举或etcd的 Raft 算法）。
- 持续同步集群状态（从 Leader 的
- 故障切换：当 Active Master 宕机时，备用节点通过选举机制 自动晋升为新的 Active Master，实现无缝切换。
关键区别总结
| 特性 | Master 节点 (Active) | 候选 Master 节点 (Standby) |
|---|---|---|
| 当前角色 | 领导者（Leader） | 跟随者（Follower） |
| 处理请求 | ✅ 响应所有集群请求 | ❌ 仅同步数据，不响应请求 |
| 组件运行状态 | 所有组件处于活跃状态 | 组件运行但处于待机模式 |
| 数据写入权限 | ✅ 唯一可写入 etcd 的节点 | ❌ 只能从 Leader 同步 etcd 数据 |
| 高可用切换 | 故障时降级 | 故障时晋升为 Active Master |
如何实现高可用？
- 选举机制：
etcd使用 Raft 算法 选举 Leader（存储层高可用）。- Kubernetes 控制平面组件（如
kube-controller-manager）通过 Lease API 实现领导者选举。
- 负载均衡：
用户请求通过 负载均衡器（如 HAProxy、Nginx） 定向到 Active Master 的kube-apiserver。当主节点切换时，负载均衡器自动检测新主节点。 - 最少节点数：
通常需要 至少 3 个 Master 节点 以容忍单节点故障（满足 Raft 算法的多数派要求）。
示例架构（3 节点高可用集群）
💡 注意：术语 “候选 Master” 并非 Kubernetes 官方命名，实际场景中通常直接称为 Master 节点，通过其角色（Active/Standby）区分状态。
总结
- Active Master：集群的“大脑”，实时处理任务。
- 候选 Master：热备节点，随时准备接管以避免单点故障。
两者协同工作，确保 Kubernetes 控制平面持续可用。