kubernetes多master高可用通过控制平面冗余、etcd强一致、负载均衡接入和自动故障接管四环节实现：部署≥3个对等master节点，独立etcd集群（3或5节点），haproxy+keepalived提供vip统一入口，并支持逐层健康检查与秒级故障转移。
Kubernetes 多 Master 节点高可用不是简单地部署多个 master，而是通过控制平面冗余、数据层强一致、流量智能分发和自动故障接管四个环节协同实现的。
控制平面多实例部署
至少部署 3 个 Master 节点，每个节点运行完整的控制平面组件（kube-apiserver、kube-controller-manager、kube-scheduler）。使用 kubeadm init --control-plane-endpoint 指定统一接入地址（如 k8s-api:6443），后续所有 master 加入时都指向该端点。初始化后，各 master 节点通过 etcd 集群同步集群状态，彼此不依赖单点调度。
- master1、master2、master3 均为对等节点，无主从之分
- controller-manager 和 scheduler 默认启用 leader election，同一时刻仅一个实例处于活跃工作状态，其余待命
- API Server 无状态设计，可并行接收请求，天然支持横向扩展
etcd 集群保障数据一致性
etcd 是 Kubernetes 的唯一数据源，其高可用直接决定整个集群的可靠性。必须以独立集群方式部署，推荐 3 或 5 个 etcd 成员（奇数），采用 Raft 共识算法保证写入多数派确认才成功。
- 避免堆叠式部署（即 etcd 与 master 共节点），优先选用外部 etcd 拓扑，实现控制平面与数据存储故障域隔离
- 各 etcd 节点需配置稳定的静态 peer URL，并确保 2379（client）和 2380（peer）端口互通
- 定期执行 etcdctl snapshot save 并异地备份，配合监控告警（如 etcd_disk_wal_fsync_duration_seconds）及时发现异常
负载均衡器统一接入入口
客户端（kubectl、CI/CD、Ingress Controller）不直连具体 master IP，而是访问由负载均衡器暴露的虚拟地址（VIP 或域名），由其将 6443 端口的 HTTPS 请求轮询转发至后端 master。
- HAProxy 作为四层负载均衡器，配置 roundrobin 算法 + health check（如 GET /healthz），自动剔除不可用 master
- Keepalived 提供 VIP（如 192.168.100.190），通过 VRRP 协议在 HAProxy 节点间漂移，主节点故障时 VIP 秒级切换
- kubeadm 初始化时指定 controlPlaneEndpoint 必须解析到该 VIP，否则证书 SAN 不匹配会导致 TLS 握手失败
健康检查与自动故障转移
整个链路具备逐层探测能力：HAProxy 定期探测 API Server 健康状态；Keepalived 监控本地 HAProxy 进程存活；etcd 集群内成员持续心跳同步。任一环节异常都会触发对应层级的恢复动作。
- 单个 master 节点宕机：HAProxy 自动摘流，剩余节点继续提供 API 服务，controller-manager/scheduler 在几秒内完成新 leader 选举
- 单个 etcd 成员失效：Raft 自动降级容忍，只要剩余成员数 ≥ ⌈n/2⌉+1，集群仍可读写；需及时替换故障节点并重新加入集群
- VIP 所在节点故障：Keepalived 将 VIP 迁移至备用节点，客户端连接无感知（TCP 连接会重试，通常在 1–3 秒内恢复）
