Kubernetes高可用集群部署与优化实战

1. Kubernetes 1.32 高可用集群部署深度解析最近在帮客户部署Kubernetes 1.32生产环境时发现很多同行对高可用集群的部署细节存在不少疑问。作为从Kubernetes 1.12版本就开始实操的老兵我想通过这个系列分享一些实战经验。第七篇我们将重点讨论控制平面组件的拓扑分布和故障域隔离策略。高可用(HA)在Kubernetes语境下特指控制平面组件(API Server、Controller Manager、Scheduler等)的冗余部署。与普通部署最大的区别在于HA集群需要至少三个master节点且这些节点应当分布在不同的物理故障域中。我在AWS上的标准做法是将master节点部署在三个不同的可用区(AZ)这样即使整个AZ宕机集群仍能保持控制平面功能。2. 核心架构设计2.1 控制平面拓扑方案选择当前主流的高可用方案有两种堆叠式(Stacked)拓扑etcd与control plane组件部署在同一节点外部etcd拓扑etcd集群独立部署通过基准测试发现在节点数小于10个的中小型集群中堆叠式拓扑的延迟表现更好平均API响应时间快17%。这是因为减少了跨节点通信开销。但超过20个节点的大型集群外部etcd方案在稳定性方面优势明显。生产环境选择建议开发测试环境3节点堆叠式生产环境节点153-5节点堆叠式生产环境节点≥153节点control plane 5节点etcd集群2.2 关键组件配置细节2.2.1 API Server高可用在/etc/kubernetes/manifests/kube-apiserver.yaml中需要特别注意spec: containers: - command: - kube-apiserver - --etcd-servershttps://192.168.1.100:2379,https://192.168.1.101:2379,https://192.168.1.102:2379 - --apiserver-count3 # 必须与实际master节点数一致 - --endpoint-reconciler-typelease实测发现当--apiserver-count设置不正确时会导致Service IP分配异常。曾经有个客户环境因此导致ClusterIP重复分配引发网络故障。2.2.2 Controller Manager选举三个master节点上的controller-manager会通过--leader-electtrue自动选举主实例。但需要确保ps aux | grep controller-manager # 应该只有一个节点显示如下进程 # --leader-electtrue --controllers*,bootstrapsigner,tokencleaner常见问题是防火墙规则阻塞了9443端口的通信导致选举失败。可以用以下命令诊断curl -k https://localhost:9443/metrics | grep leader_election3. 网络与存储方案3.1 多AZ网络配置要点在AWS多可用区部署时需要特别注意每个AZ使用独立子网如10.0.1.0/24、10.0.2.0/24、10.0.3.0/24VPC路由表确保跨AZ通信不经过NAT网关安全组需要放行master节点间TCP 2379-2380etcdTCP 6443API ServerUDP 8472Flannel VXLAN曾经遇到一个经典故障某AZ的节点无法加入集群最终发现是该AZ子网的路由表缺失了到其他AZ的路由条目。3.2 持久化存储方案对比高可用集群推荐使用以下存储方案方案适用场景性能指标(IOPS)故障恢复时间EBS多挂载单AZ应用3000-160002-5分钟EFS多AZ共享存储100-1000即时RookCeph自建存储基础设施2000-80001分钟Portworx有状态服务云原生存储5000-2000030秒在金融行业客户案例中我们最终选择了Portworx方案因其支持存储级别故障域感知自动重建副本的优先级调度亚秒级的卷故障切换4. 部署实操全流程4.1 使用kubeadm初始化集群第一台master节点初始化命令kubeadm init \ --control-plane-endpoint k8s-api.example.com:6443 \ --upload-certs \ --pod-network-cidr10.244.0.0/16 \ --service-cidr10.96.0.0/12 \ --apiserver-advertise-address192.168.1.100 \ --image-repository registry.aliyuncs.com/google_containers关键参数说明--control-plane-endpoint必须配置为负载均衡器地址--upload-certs自动轮转证书的密钥--apiserver-advertise-address建议显式指定内网IP4.2 加入其他控制平面节点获取join命令kubeadm token create --print-join-command然后在其他master节点执行kubeadm join k8s-api.example.com:6443 \ --token xxxx \ --discovery-token-ca-cert-hash sha256:xxxx \ --control-plane \ --certificate-key xxxx常见错误处理证书不匹配删除/etc/kubernetes/pki目录后重试端口不通检查防火墙和负载均衡器健康检查配置时间不同步安装chronyd并启用NTP同步5. 验证与故障排查5.1 高可用验证测试模拟节点故障# 随机停止一个master节点的kubelet systemctl stop kubelet # 观察其他节点日志 journalctl -u kubelet -f | grep -i electAPI Server负载测试wrk -t4 -c100 -d60s https://k8s-api.example.com/api/v1/namespaces健康集群应满足99%请求延迟500ms错误率0.1%5.2 常见问题速查表故障现象可能原因解决方案API Server间歇性不可用负载均衡器健康检查配置错误检查LB的health check路径应为/healthzetcd集群显示leader频繁切换磁盘IO延迟过高迁移etcd数据到SSD磁盘新master节点无法加入证书过期使用kubeadm alpha certs renew allController Manager无leader9443端口被占用netstat -tulnp找出冲突进程6. 性能调优建议6.1 etcd专项优化在/etc/etcd/etcd.conf中添加# 提高Raft心跳间隔 heartbeat-interval150 election-timeout1500 # 优化后端存储 auto-compaction-retention2h max-request-bytes157286400调整后etcd集群的写入吞吐量提升了40%特别是在批量创建Pod时效果显著。6.2 API Server参数调优spec: containers: - command: - kube-apiserver - --max-mutating-requests-inflight500 - --max-requests-inflight1500 - --target-ram-mb8192这些参数需要根据节点实际内存调整。监控API Server内存使用情况kubectl top pod -n kube-system kube-apiserver-master-1在最近一次千万级PV的电商大促中通过以上调优方案我们成功将API Server的P99延迟从1.2s降低到380ms。关键是要根据实际业务负载特点进行渐进式调整每次修改单个参数后观察监控至少30分钟。