北陌大叔1. Kubernetes高可用集群的核心价值
在生产环境中，Kubernetes集群的高可用性直接关系到业务连续性。单Master架构存在明显的单点故障风险——一旦控制平面崩溃，整个集群将失去调度能力。我在金融行业的一次生产事故中深刻体会到：当API Server不可用时，不仅新的Pod无法创建，连现有的Deployment滚动更新都会中断，导致业务版本回滚失败。
多Master架构通过部署多个控制平面节点，实现了以下关键能力：
- API Server负载均衡：客户端请求可被均匀分配到健康节点
- 组件冗余：etcd集群、Controller Manager和Scheduler都具备故障转移能力
- 零感知维护：单个Master节点下线不影响集群操作
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 高可用架构设计要点
2.1 典型拓扑结构
我们采用的3节点Master架构经过多个生产环境验证：
code复制[负载均衡层]
│
├── Master Node 1 (etcd member 1)
├── Master Node 2 (etcd member 2)
└── Master Node 3 (etcd member 3)
│
└── Worker Nodes (至少3个)
关键设计原则：
- etcd集群必须奇数节点（3/5/7）
- 每个Master节点部署完整控制平面组件
- 负载均衡器需要健康检查能力
2.2 网络与存储规划
在AWS环境中的最佳实践：
yaml复制# 网络配置示例
apiVersion: kops.k8s.io/v1alpha2
kind: Cluster
spec:
networking:
kubenet: {}
subnets:
- cidr: 172.20.32.0/19
name: us-east-1a
type: Private
zone: us-east-1a
- cidr: 172.20.64.0/19
name: us-east-1b
type: Private
zone: us-east-1b
存储特别注意：
- etcd数据目录需要高性能SSD（至少1000 IOPS）
- 建议每个etcd成员使用独立EBS卷
- 禁用swap分区以防止内存抖动
3. 负载均衡器实战配置
3.1 Nginx方案实现
这是经过生产验证的nginx配置模板：
nginx复制stream {
upstream kube-apiserver {
server 10.0.1.10:6443 max_fails=3 fail_timeout=5s;
server 10.0.1.11:6443 max_fails=3 fail_timeout=5s;
server 10.0.1.12:6443 max_fails=3 fail_timeout=5s;
}
server {
listen 6443;
proxy_pass kube-apiserver;
proxy_connect_timeout 1s;
proxy_timeout 3s;
}
}
健康检查关键参数：
bash复制# 使用kube-apiserver的healthz端点
health_check interval=10s passes=2 fails=3 uri=/healthz
3.2 云厂商LB方案对比
| 服务商 | 方案类型 | 会话保持 | 健康检查 | 典型延迟 |
|---|---|---|---|---|
| AWS | NLB | TCP级别 | 端口探测 | <5ms |
| GCP | L4 ILB | 无 | HTTP/2 | <3ms |
| Azure | Standard LB | 无 | 自定义 | 8-15ms |
重要提示：避免使用ALB/ELB等7层负载均衡器，kube-apiserver需要保持长连接
4. 集群初始化关键步骤
4.1 使用kubeadm部署
多Master加入流程：
bash复制# 第一个Master节点
kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:6443" \
--upload-certs \
--pod-network-cidr=192.168.0.0/16
# 其他Master节点
kubeadm join LOAD_BALANCER_DNS:6443 \
--token <token> \
--discovery-token-ca-cert-hash sha256:<hash> \
--control-plane \
--certificate-key <key>
证书管理要点：
--upload-certs生成的密钥24小时有效- 建议使用外部CA签发长期证书
- 定期轮换kubeadm生成的证书
4.2 etcd集群调优
性能关键参数（/etc/etcd/etcd.conf）：
ini复制# 建议根据节点规格调整
ETCD_HEARTBEAT_INTERVAL="500"
ETCD_ELECTION_TIMEOUT="2500"
ETCD_SNAPSHOT_COUNT="10000"
ETCD_MAX_REQUEST_BYTES="157286400"
监控指标阈值参考：
- 写延迟应<50ms
- 未完成提案数应<500
- 存储配额使用率<80%
5. 高可用验证与故障演练
5.1 模拟节点故障
验证流程：
- 随机停止一个Master节点的kube-apiserver
bash复制
systemctl stop kube-apiserver - 观察负载均衡流量切换（应30秒内完成）
- 执行集群操作验证（如创建Deployment）
- 检查组件日志是否有选举发生
5.2 网络分区测试
使用iptables模拟网络中断：
bash复制# 隔离etcd节点3
iptables -A INPUT -p tcp --dport 2379 -s 10.0.1.13 -j DROP
iptables -A OUTPUT -p tcp --dport 2379 -d 10.0.1.13 -j DROP
预期现象：
- 剩余节点应继续形成法定人数
- 被隔离节点日志显示"lost leader"
- 客户端请求可能有短暂超时但不会失败
6. 生产环境运维经验
6.1 升级策略
滚动升级控制平面步骤：
- 标记节点不可调度
bash复制
kubectl cordon master-1 - 排空节点（忽略DaemonSet）
bash复制
kubectl drain master-1 --ignore-daemonsets - 升级组件后解除封锁
- 验证节点健康状态再处理下一个
6.2 监控指标看板
Prometheus关键告警规则：
yaml复制- alert: APIServerDown
expr: sum(up{job="apiserver"}) by (cluster) < 2
for: 5m
labels:
severity: critical
annotations:
summary: "Kubernetes API server unavailable (instance {{ $labels.instance }})"
Grafana面板应包含：
- 各Master节点API延迟百分位
- etcd写入吞吐量
- 负载均衡器连接数分布
7. 典型问题排查实录
7.1 证书过期问题
症状表现：
code复制Unable to connect to the server: x509: certificate has expired or is not yet valid
解决方案：
bash复制# 查看证书有效期
openssl x509 -noout -dates -in /etc/kubernetes/pki/apiserver.crt
# 手动更新证书
kubeadm alpha certs renew all
7.2 脑裂场景处理
当etcd出现网络分区时：
- 优先保证包含leader的分区
- 强制移除故障节点：
bash复制
etcdctl member remove <member-id> - 添加新节点重新加入集群
预防措施：
- 部署跨AZ的etcd集群
- 配置合理的超时参数
- 定期进行故障演练