生产级Kubernetes高可用集群搭建与优化实战

1. 从单节点到高可用：生产级K8s集群搭建全记录

三年前我第一次接触Kubernetes时，完全没想过这个容器编排系统会成为我们生产环境的核心支柱。当时只是用minikube跑了个单节点集群，如今却要管理着横跨三个可用区的生产级高可用集群。这篇文章将完整还原我的演进路径，特别是最近一次从单控制平面升级到多Master高可用架构的实战过程。

我们最初的业务规模很小，单Master节点确实够用。直到某个周五下午，这个唯一的主节点因为磁盘故障宕机，整个集群控制平面瘫痪，所有部署和扩缩容操作全部停摆。那次事故让我深刻认识到：生产环境必须实现控制平面的高可用（HA）。经过充分准备和多次测试，我们最终采用HAProxy+Keepalived作为负载均衡层，配合三个Master节点和etcd集群，构建了真正意义上的生产级K8s HA架构。

2. 高可用架构设计解析

2.1 核心组件选型与拓扑设计

高可用K8s集群的核心在于控制平面的冗余设计。我们采用的架构包含以下关键组件：

• 负载均衡层：HAProxy 2.4 + Keepalived实现VIP漂移
• 控制平面：3个Master节点部署kube-apiserver等核心组件
• 数据存储：3节点etcd集群采用奇数节点部署
• 工作节点：根据业务需求动态扩展的Node节点

拓扑结构上，我们将三个Master节点分散在不同机架（对应云环境的不同可用区），每个节点同时运行etcd和kube-apiserver。这里有个关键决策点：etcd是与Master共置还是独立部署？考虑到我们的集群规模（初期约50个Node），选择了共置方案以简化运维。

重要提示：etcd集群必须保持奇数节点，这是Raft共识算法的基础要求。偶数节点实际上会降低可用性，因为4节点集群需要3票才能达成共识，与3节点集群的容错能力相同。

2.2 网络与存储规划

生产级集群必须提前规划好网络和存储方案：

• 网络插件：经过对比测试，我们最终选择Calico作为CNI插件，其BGP模式能很好地适应我们的混合云环境
• Pod CIDR：采用172.16.0.0/16，每个节点分配/24子网
• Service CIDR：10.96.0.0/12，确保有足够空间供Service使用
• 存储类：根据应用需求配置了SSD和HDD两种StorageClass

3. 关键实现步骤详解

3.1 负载均衡层搭建

HAProxy配置是控制平面高可用的核心。我们的/etc/haproxy/haproxy.cfg关键配置如下：

frontend k8s-api bind *:6443 mode tcp default_backend k8s-masters backend k8s-masters mode tcp balance roundrobin option tcp-check server master1 192.168.1.101:6443 check fall 3 rise 2 server master2 192.168.1.102:6443 check fall 3 rise 2 server master3 192.168.1.103:6443 check fall 3 rise 2

配合Keepalived实现VIP漂移，确保即使某个HAProxy实例宕机，服务仍可用。这里有个血泪教训：早期测试时忘记配置TCP健康检查，导致某个Master节点不可用时，请求仍会被转发到故障节点。

3.2 多Master节点部署

使用kubeadm初始化第一个Master节点：

kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" \ --upload-certs \ --pod-network-cidr=172.16.0.0/16 \ --service-cidr=10.96.0.0/12

获取join命令后，在其他节点执行：

kubeadm join LOAD_BALANCER_DNS:LOAD_BALANCER_PORT \ --token <token> \ --discovery-token-ca-cert-hash sha256:<hash> \ --control-plane --certificate-key <key>

特别注意：证书轮换是个容易忽略的点。我们设置了定期检查任务，确保证书不会过期导致集群故障。

3.3 etcd集群配置

etcd集群的健康状态直接影响整个K8s集群的稳定性。我们通过以下命令定期检查：

ETCDCTL_API=3 etcdctl \ --endpoints=https://192.168.1.101:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ endpoint health

4. 生产环境调优经验

4.1 关键参数调优

经过压力测试，我们对以下参数进行了优化：

• kube-apiserver：
  • --max-requests-inflight=1500
  • --max-mutating-requests-inflight=500
• etcd：
  • --heartbeat-interval=500
  • --election-timeout=2500
• kubelet：
  • --max-pods=110（根据节点规格调整）

4.2 监控与告警配置

完善的监控是高可用集群的"眼睛"。我们的监控体系包括：

1. 控制平面组件：通过kube-state-metrics监控各组件状态
2. etcd性能：专门部署etcd-exporter采集关键指标
3. 节点资源：Node Exporter收集基础资源数据
4. 自定义告警规则：如"API Server响应时间>1s"、"etcd写入延迟>500ms"

5. 故障排查与经验总结

5.1 典型问题及解决方案

问题1：新加入的Master节点一直处于NotReady状态

• 排查：发现是Calico网络插件未正确初始化
• 解决：手动应用Calico manifest后恢复正常

问题2：etcd集群偶尔出现leader切换

• 排查：网络延迟检测显示跨可用区通信存在波动
• 解决：调整etcd心跳参数并优化网络配置

5.2 血泪教训

1. 证书管理：曾因证书过期导致整个集群不可用，现在使用kubeadm certs check-expiration定期检查
2. 备份策略：etcd快照备份必须跨地域存储，我们曾因单机房故障丢失备份
3. 升级顺序：K8s版本升级时必须严格按照官方文档的顺序操作，我们曾因先升级worker节点导致兼容性问题

6. 集群扩展与未来规划

当前架构已支持横向扩展：

• Master节点：可随时添加新控制平面节点（保持奇数）
• Worker节点：通过Cluster Autoscaler实现自动扩缩容
• 多集群管理：正在评估Karmada等多集群方案

从单节点到高可用的演进过程中，最大的体会是：生产级K8s集群不是简单的组件堆砌，而是需要根据实际业务需求不断调优的有机体。每次架构升级前，我们都会在测试环境充分验证，确保生产环境的稳定性。