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 算法）。
• 故障切换：当 Active Master 宕机时，备用节点通过选举机制 自动晋升为新的 Active Master，实现无缝切换。

---

关键区别总结

特性	Master 节点 (Active)	候选 Master 节点 (Standby)
当前角色	领导者（Leader）	跟随者（Follower）
处理请求	✅ 响应所有集群请求	❌ 仅同步数据，不响应请求
组件运行状态	所有组件处于活跃状态	组件运行但处于待机模式
数据写入权限	✅ 唯一可写入 etcd 的节点	❌ 只能从 Leader 同步 etcd 数据
高可用切换	故障时降级	故障时晋升为 Active Master

---

如何实现高可用？

1. 选举机制：
   • etcd 使用 Raft 算法 选举 Leader（存储层高可用）。
   • Kubernetes 控制平面组件（如 kube-controller-manager）通过 Lease API 实现领导者选举。
2. 负载均衡：
   用户请求通过 负载均衡器（如 HAProxy、Nginx） 定向到 Active Master 的 kube-apiserver。当主节点切换时，负载均衡器自动检测新主节点。
3. 最少节点数：
   通常需要 至少 3 个 Master 节点 以容忍单节点故障（满足 Raft 算法的多数派要求）。

---

示例架构（3 节点高可用集群）

💡 注意：术语 “候选 Master” 并非 Kubernetes 官方命名，实际场景中通常直接称为 Master 节点，通过其角色（Active/Standby）区分状态。

总结

• Active Master：集群的“大脑”，实时处理任务。
• 候选 Master：热备节点，随时准备接管以避免单点故障。
  两者协同工作，确保 Kubernetes 控制平面持续可用。