企业官网建设流程全解析

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 控制平面拓扑方案选择

当前主流的高可用方案有两种：

1. 堆叠式(Stacked)拓扑：etcd与control plane组件部署在同一节点
2. 外部etcd拓扑：etcd集群独立部署

通过基准测试发现，在节点数小于10个的中小型集群中，堆叠式拓扑的延迟表现更好（平均API响应时间快17%）。这是因为减少了跨节点通信开销。但超过20个节点的大型集群，外部etcd方案在稳定性方面优势明显。

生产环境选择建议：

• 开发测试环境：3节点堆叠式
• 生产环境（节点<15）：3-5节点堆叠式
• 生产环境（节点≥15）：3节点control plane + 5节点etcd集群

2.2 关键组件配置细节

2.2.1 API Server高可用

在/etc/kubernetes/manifests/kube-apiserver.yaml中需要特别注意：

spec: containers: - command: - kube-apiserver - --etcd-servers=https://192.168.1.100:2379,https://192.168.1.101:2379,https://192.168.1.102:2379 - --apiserver-count=3 # 必须与实际master节点数一致 - --endpoint-reconciler-type=lease

实测发现当--apiserver-count设置不正确时，会导致Service IP分配异常。曾经有个客户环境因此导致ClusterIP重复分配，引发网络故障。

2.2.2 Controller Manager选举

三个master节点上的controller-manager会通过--leader-elect=true自动选举主实例。但需要确保：

ps aux | grep controller-manager # 应该只有一个节点显示如下进程： # --leader-elect=true --controllers=*,bootstrapsigner,tokencleaner

常见问题是防火墙规则阻塞了9443端口的通信，导致选举失败。可以用以下命令诊断：

curl -k https://localhost:9443/metrics | grep leader_election

3. 网络与存储方案

3.1 多AZ网络配置要点

在AWS多可用区部署时，需要特别注意：

1. 每个AZ使用独立子网（如10.0.1.0/24、10.0.2.0/24、10.0.3.0/24）
2. VPC路由表确保跨AZ通信不经过NAT网关
3. 安全组需要放行：
   • master节点间TCP 2379-2380（etcd）
   • TCP 6443（API Server）
   • UDP 8472（Flannel VXLAN）

曾经遇到一个经典故障：某AZ的节点无法加入集群，最终发现是该AZ子网的路由表缺失了到其他AZ的路由条目。

3.2 持久化存储方案对比

高可用集群推荐使用以下存储方案：

在金融行业客户案例中，我们最终选择了Portworx方案，因其支持：

• 存储级别故障域感知
• 自动重建副本的优先级调度
• 亚秒级的卷故障切换

4. 部署实操全流程

4.1 使用kubeadm初始化集群

第一台master节点初始化命令：

kubeadm init \ --control-plane-endpoint "k8s-api.example.com:6443" \ --upload-certs \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --apiserver-advertise-address=192.168.1.100 \ --image-repository registry.aliyuncs.com/google_containers

关键参数说明：

• --control-plane-endpoint：必须配置为负载均衡器地址
• --upload-certs：自动轮转证书的密钥
• --apiserver-advertise-address：建议显式指定内网IP

4.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 高可用验证测试

1. 模拟节点故障：

# 随机停止一个master节点的kubelet systemctl stop kubelet # 观察其他节点日志 journalctl -u kubelet -f | grep -i elect

2. API Server负载测试：

wrk -t4 -c100 -d60s https://k8s-api.example.com/api/v1/namespaces

健康集群应满足：

• 99%请求延迟<500ms
• 错误率<0.1%

5.2 常见问题速查表

6. 性能调优建议

6.1 etcd专项优化

在/etc/etcd/etcd.conf中添加：

# 提高Raft心跳间隔 heartbeat-interval=150 election-timeout=1500 # 优化后端存储 auto-compaction-retention=2h max-request-bytes=157286400

调整后etcd集群的写入吞吐量提升了40%，特别是在批量创建Pod时效果显著。

6.2 API Server参数调优

spec: containers: - command: - kube-apiserver - --max-mutating-requests-inflight=500 - --max-requests-inflight=1500 - --target-ram-mb=8192

这些参数需要根据节点实际内存调整。监控API Server内存使用情况：

kubectl top pod -n kube-system kube-apiserver-master-1

在最近一次千万级PV的电商大促中，通过以上调优方案，我们成功将API Server的P99延迟从1.2s降低到380ms。关键是要根据实际业务负载特点进行渐进式调整，每次修改单个参数后观察监控至少30分钟。