高可用 Kubernetes 集群需跨节点部署控制平面组件并实现故障隔离与自动恢复：etcd 至少 3 节点、Raft 共识；kubeadm 搭建时剥离 etcd、配置 VIP+ 负载均衡；独立加固 etcd（分离 wal/data、调优参数、定期快照）；网络层用多主控感知 CNI，存储层确保副本跨区与外部存储高可用。
高可用 Kubernetes 集群的核心设计要点
要实现真正高可用，关键不在组件数量，而在故障隔离与自动恢复能力。控制平面必须跨节点部署 etcd、kube-apiserver、kube-scheduler 和 kube-controller-manager，且所有 API Server 需通过负载均衡器对外暴露统一入口；etcd 集群至少 3 节点（推荐奇数），数据同步采用 Raft 协议，避免单点写入瓶颈；Node 节点不参与控制面选举，但需配置多路径健康检查与滚动重启策略。
使用 kubeadm 快速搭建 HA 集群（三控制节点）
kubeadm 仍是生产环境主流选择，前提是跳过默认的单点 etcd 模式。操作分四步：先在三台机器上初始化第一个控制节点并生成 join 配置；再将 etcd 静态 Pod 清单改为外部集群模式，用 kubeadm init phase etcd local –config 指定外部 etcd 端点；接着在另两台机器上执行 kubeadm join –control-plane –certificate-key，指向共享的 etcd 集群和 VIP；最后部署 nginx 或 haproxy作为 API Server前端 负载均衡器，监听 6443端口 并启用 TLS 透传。
- 负载均衡器需配置健康检查，探测路径为red”>/healthz，超时设为 3 秒，失败阈值 2 次
- 所有控制节点的 –apiserver-advertise-address 必须绑定内网 IP，不可用 127.0.0.1
- 证书生成阶段务必备份 /etc/kubernetes/pki 目录，后续节点加入依赖 CA 和 front-proxy 证书
etcd 集群独立部署与稳定性加固
将 etcd 从控制节点剥离是提升稳定性的关键一步。建议用 systemd 托管 etcd 服务，禁用 swap，设置 GOMAXPROCS=2，wal 目录与 data-dir 必须分离在不同磁盘；开启自动碎片整理（–auto-compaction-retention=24h）和心跳超时调优（–heartbeat-interval=250 –election-timeout=2500）；定期用 etcdctl endpoint status 校验成员状态，并配合 Prometheus+Grafana 监控 leader 变化、snapshot 失败率和 backend commit 持续时间。
- etcd 客户端连接字符串应包含全部成员地址，例如https://10.10.1.1:2379,https://10.10.1.2:2379,https://10.10.1.3:2379
- 禁止在 etcd 中存储大于 1MB 的对象，ConfigMap/Secret 内容过大时拆分为多个资源
- 每日凌晨执行 etcdctl snapshot save 并上传至对象存储，保留最近 7 天快照
网络与存储层的高可用衔接
CNI 插件需支持多主控感知，Calico 推荐 v3.24+ 并启用 Typha 组件分担 API 压力；Cilium 则需开启 kube-proxy-replacement=strict 与 host-reachable-services。存储方面，若用 Longhorn，确保 replica 节点分布在不同可用区，且 management URL 指向负载均衡后的 service；若对接外部存储如 Ceph RBD，Secret 中 ceph.conf 必须包含 mon_host 列表而非单点，同时配置 rbdmap 超时与重试参数。
