把Kubernetes跑起来很容易，一条kubeadm init命令几分钟就能得到一个可用集群，但要在生产环境中长期稳定运行，单master架构几乎不可接受：一旦控制平面节点故障，集群的写入操作全部中断，虽然已运行的Pod不会立刻消失，但无法调度新工作负载、无法执行扩缩容，故障恢复窗口完全取决于人工介入速度。本文从控制平面、etcd存储、负载均衡层、工作节点与运维细节几个维度，梳理生产环境高可用设计的核心要点。
一、控制平面多副本部署：高可用的地基
Kubernetes控制平面由kube-apiserver、kube-controller-manager、kube-scheduler和etcd组成。除了etcd本身是分布式存储外，其余组件默认是无状态的，这为多副本部署提供了天然条件。生产环境建议至少部署3个master节点，最好是奇数个节点（3、5、7），这样在选举类组件（如controller-manager的leader election）和etcd投票时才能正确形成多数派。
kube-apiserver是无状态的，每个副本都可以独立对外提供服务，直接横向扩展即可。而kube-controller-manager和kube-scheduler虽然也部署多份，但同一时刻只有通过leader选举的那一个实例真正工作，其余副本处于热备状态。这一点在排查问题时很重要：如果你发现某个副本没有产生任何日志，不要误以为它坏了，先看看leader lease在谁手上。
节点数量规划上要结合业务规模。3个master节点可以容忍1个节点故障，5个可以容忍2个。对于大多数中小规模集群，3个master节点加上合理的资源预留已经足够。每个master节点建议至少4核CPU、8GB内存，并且使用taint把业务Pod挡在控制平面之外，避免业务负载挤占apiserver的资源。
二、etcd集群：最容易成为短板的一环
etcd存储着集群的全部状态数据，是整个体系里最怕慢、最怕丢数据的组件。高可用方面，etcd采用Raft协议，3节点容忍1个故障，5节点容忍2个故障。值得注意的是，etcd的可用性以"写入多数派成功"为标准，3节点集群挂掉2个节点时，读取和写入都会失败，因此不建议为了省机器把etcd副本数设为偶数，偶数不增加容错能力反而增加写入延迟。
磁盘性能对etcd的影响极大。etcd每次写入都会强制落盘（fsync），如果磁盘延迟高，apiserver的响应速度会断崖式下跌，表现为kubectl命令卡顿、Pod启动缓慢。官方建议使用SSD或NVMe盘，保证p99的fsync耗时在10ms以内。云环境上尽量选择独享型云盘，避免和邻居虚拟机争抢IO。同时要监控两个关键指标：etcd_disk_wal_fsync_duration_seconds和etcd_disk_backend_commit_duration_seconds。
另一个决策点是etcd是堆叠在master节点上还是独立部署。堆叠方案（kubeadm默认）省机器、部署简单，适合大多数场景；外置etcd集群则把存储故障域与控制平面隔离，适合大型集群或对数据安全要求极高的场景。无论哪种方案，都必须配置定时备份，例如使用etcdutl snapshot save每6小时做一次快照并上传到对象存储，备份是应对逻辑错误和误删除的最后防线。
三、负载均衡层：让apiserver访问无单点
多个kube-apiserver副本前面需要一层负载均衡，否则kubectl、kubelet和各类客户端还是只能指向某一个固定地址。常见方案有三种：硬件或云厂商的LB、自建HAProxy+Keepalived、以及云原生场景下的DNS轮询（不推荐）。
自建方案中，Keepalived通过VRRP协议维护一个虚拟IP（VIP），HAProxy负责把请求转发给后端多个apiserver。一旦持有VIP的节点故障，VIP会自动漂移到备节点，配合HAProxy的健康检查，单个apiserver宕机对客户端完全透明。一个精简的HAProxy配置如下：
frontend k8s-apiserver
bind *:6443
mode tcp
default_backend k8s-control-plane
backend k8s-control-plane
mode tcp
option tcp-check
balance roundrobin
server master-1 192.168.10.11:6443 check inter 2000 fall 3 rise 2
server master-2 192.168.10.12:6443 check inter 2000 fall 3 rise 2
server master-3 192.168.10.13:6443 check inter 2000 fall 3 rise 2
如果集群跑在公有云上，直接使用云负载均衡是更省心的选择，把三个master的6443端口注册为后端即可，云LB天然具备高可用能力。此外，kubelet访问apiserver的地址在节点加入后就固化了，所以负载均衡地址必须从一开始就规划好，后期更换证书和endpoint的成本非常高。
四、工作节点与负载层的高可用
控制平面高可用只是故事的一半，业务Pod的高可用需要依赖调度机制和节点容量。首先要给关键应用设置多副本并配合反亲和性，把同一服务的副本打散到不同节点甚至不同可用区：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: web
topologyKey: kubernetes.io/hostname
其次要配置合理的PodDisruptionBudget（PDB），保证在节点维护、升级时至少保留一定数量的可用副本。再配合cluster-autoscaler或云厂商的节点组自动伸缩，应对流量高峰。coredns、ingress controller这类基础设施组件自身也要多副本部署，DNS挂了比业务挂了影响面更大。
网络插件的选择也影响故障恢复表现。生产环境推荐Calico或Cilium这类支持NetworkPolicy的方案，并确认插件的故障场景行为，例如节点重启后Pod网络能否自动恢复。跨可用区部署时还要留意网络延迟对etcd跨机房同步的影响，一般不建议etcd成员之间的RTT超过50ms。
五、容易被忽视的运维细节
证书续期是最常见的"定时炸弹"。kubeadm签发的证书默认一年有效期，很多集群运行一年后突然全部组件掉线，就是证书过期导致的。建议配置证书到期监控告警，并定期执行kubeadm certs renew all，或者在上游接入长期有效的CA。
版本升级策略同样关键。生产集群不要追新，建议跟随上一个次版本的最新补丁版本，并且先在预发环境演练。升级master节点时要逐台进行，等待etcd和apiserver健康后再处理下一台。最后，建立完整的监控体系：Prometheus加node-exporter、kube-state-metrics，重点盯etcd的leader变化、apiserver的请求延迟、节点NotReady事件和Pod重启次数，配合告警把故障发现时间压缩到分钟级，这才是一套真正生产可用的Kubernetes高可用体系。
Kubernetes高可用etcd集群kube-apiserver负载均衡修改时间：2026-09-06 08:58:33