1. 项目背景与核心挑战
三年前我第一次在生产环境部署Kubernetes时，还是用kubeadm快速搭建的单Master节点集群。直到某个深夜收到报警短信，才发现这个架构有多脆弱——当Master节点所在物理机因内存故障宕机后，整个集群的控制平面完全瘫痪，连基本的Pod调度都无法进行。这次事故让我深刻认识到：在生产环境，高可用(High Availability)不是可选项，而是必选项。
经过半年多的实践迭代，我们最终构建了符合金融级稳定性要求的Kubernetes集群架构。这个方案有几个关键特征：
- 多Master节点组成控制平面，通过HAProxy实现API Server负载均衡
- etcd集群采用独立部署模式，使用Raft协议保证数据一致性
- 工作节点通过Node Authorizer实现细粒度权限控制
- 所有组件均配置健康检查与自动故障转移
重要提示：生产环境部署至少要准备3个Master节点，这是保证etcd集群脑裂时能正常选举的最小节点数。双节点部署在某些故障场景下反而会加剧不可用风险。
2. 基础环境准备
2.1 硬件资源配置建议
我们为每个Master节点配置了如下规格：
- 4核CPU/16GB内存（运行etcd需保证低延迟）
- 100GB SSD（etcd对磁盘IOPS要求极高）
- 双万兆网卡（bonding模式提升网络可靠性）
工作节点则根据业务负载动态调整，建议最小配置：
- 16核CPU/64GB内存（满足常规业务Pod需求）
- 500GB SSD（本地存储卷需要足够空间）
- 单个万兆网卡
2.2 操作系统优化
在所有节点执行以下内核参数调优：
# 禁用swap以保证kubelet正常工作 swapoff -a sed -i '/swap/s/^/#/' /etc/fstab # 调整网络参数 cat > /etc/sysctl.d/k8s.conf <<EOF net.ipv4.ip_forward=1 net.bridge.bridge-nf-call-iptables=1 fs.file-max=1000000 net.ipv4.tcp_max_tw_buckets=6000 EOF sysctl -p3. 高可用控制平面搭建
3.1 HAProxy负载均衡配置
在3台独立的LB节点上部署HAProxy 2.4，关键配置如下：
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 23.2 多Master节点部署
使用kubeadm初始化第一个Master节点：
kubeadm init \ --control-plane-endpoint "k8s-api.example.com:6443" \ --upload-certs \ --pod-network-cidr=10.244.0.0/16其他Master节点加入集群：
kubeadm join k8s-api.example.com:6443 \ --token <token> \ --discovery-token-ca-cert-hash <hash> \ --control-plane \ --certificate-key <key>3.3 etcd集群配置
独立部署的etcd集群需要特别注意：
# /etc/etcd/etcd.conf name: etcd1># /var/lib/kubelet/config.yaml authorization: mode: Webhook webhook: cacheAuthorizedTTL: 5m0s cacheUnauthorizedTTL: 30s4.2 Calico网络插件部署
选择BGP模式实现高性能网络：
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml关键配置调整：
# calico-config ConfigMap data: typha_service_name: "calico-typha" veth_mtu: "1440" ipam: type: calico-ipam5. 稳定性保障机制
5.1 健康检查体系
为关键组件配置存活探针：
apiVersion: apps/v1 kind: Deployment metadata: name: coredns spec: template: spec: containers: - name: coredns livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 60 periodSeconds: 105.2 监控告警方案
Prometheus关键监控指标示例：
- alert: KubeAPIDown expr: sum(up{job="apiserver"}) < 3 for: 5m labels: severity: critical annotations: summary: "Kubernetes API server down (instance {{ $labels.instance }})"6. 故障排查实录
6.1 常见问题速查表
| 故障现象 | 排查命令 | 解决方案 |
|---|---|---|
| Pod一直Pending | kubectl describe pod <name> | 检查资源配额和节点选择器 |
| API Server间歇性超时 | curl -k https://localhost:6443/healthz | 检查HAProxy会话保持配置 |
| etcd写入缓慢 | etcdctl endpoint status | 优化磁盘IOPS和网络延迟 |
6.2 Master节点脑裂处理
当网络分区导致etcd集群分裂时：
- 检查各节点状态：
ETCDCTL_API=3 etcdctl --endpoints=https://192.168.1.101:2379 \ --cacert=/etc/etcd/ssl/ca.pem \ --cert=/etc/etcd/ssl/etcd.pem \ --key=/etc/etcd/ssl/etcd-key.pem \ endpoint status- 强制恢复集群：
# 在健康的多数派节点执行 etcdctl snapshot restore snapshot.db \ --initial-cluster etcd1=https://192.168.1.101:2380,etcd2=https://192.168.1.102:2380 \ --initial-advertise-peer-urls https://192.168.1.101:23807. 性能优化实践
7.1 API Server参数调优
修改kube-apiserver启动参数：
--default-not-ready-toleration-seconds=30 --default-unreachable-toleration-seconds=30 --enable-priority-and-fairness=true --max-mutating-requests-inflight=500 --max-requests-inflight=15007.2 kubelet资源预留
确保系统进程有足够资源：
# /var/lib/kubelet/config.yaml systemReserved: cpu: "1" memory: "2Gi" kubeReserved: cpu: "500m" memory: "1Gi" evictionHard: memory.available: "500Mi" nodefs.available: "10%"这个架构目前已经稳定运行超过400天，期间经历了多次硬件故障和网络中断的考验。最让我自豪的是在某次数据中心级网络中断期间，集群自动完成了工作负载的跨可用区迁移，业务系统全程无感知。
