1. 高可用Kubernetes集群部署实战:基于kubeadm的多Master架构解析
在容器编排领域,Kubernetes已成为事实标准,而生产环境中的高可用(HA)部署则是每个运维工程师必须掌握的硬核技能。今天我要分享的是基于kubeadm工具构建多Master节点集群的完整实践方案,这个方案在我们电商平台的灰度发布环境中稳定运行了两年多,期间经历了618、双11等流量高峰的考验。
与单Master架构相比,多Master方案通过etcd集群的分布式特性和API Server的负载均衡,实现了控制平面的故障自动转移。当某个Master节点宕机时,集群仍能保持调度和管理功能,这对业务连续性要求严苛的生产系统至关重要。下面我就从架构设计到具体实施,详细拆解每个关键环节。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 集群架构设计与核心组件选型
2.1 高可用架构拓扑设计
我们采用典型的"3 Master + N Worker"架构:
code复制 +-----------------+
| Load Balancer |
+--------+--------+
|
+-----------------------+-----------------------+
| | |
+-------+-------+ +-------+-------+ +-------+-------+
| Master 1 | | Master 2 | | Master 3 |
| (kube-apiserver| <---> | (kube-apiserver| <---> | (kube-apiserver|
| etcd | | etcd | | etcd |
+-------+-------+ +-------+-------+ +-------+-------+
| | |
+-----------------------+-----------------------+
|
+--------+--------+
| Worker Nodes |
+-----------------+
关键设计要点:
- 使用3个Master节点构成etcd集群(奇数节点保证选举)
- 每个Master节点同时运行kube-apiserver、kube-controller-manager和kube-scheduler
- 通过外部负载均衡器(如HAProxy/Nginx)暴露API Server服务
- Worker节点通过负载均衡VIP连接控制平面
2.2 关键组件版本选择
经过生产验证的稳定组合:
- Kubernetes: v1.24.6(较新且稳定的版本)
- etcd: 3.5.4(与Kubernetes版本配套)
- Container Runtime: containerd 1.6.8
- OS: Ubuntu 20.04 LTS
重要提示:Kubernetes 1.24+默认移除了Docker支持,建议直接使用containerd以获得更好的稳定性和性能
3. 前置准备与系统配置
3.1 硬件资源配置建议
| 节点类型 | CPU | 内存 | 磁盘 | 数量 |
|---|---|---|---|---|
| Master | 4核+ | 8GB+ | 100GB | 3 |
| Worker | 8核+ | 16GB+ | 200GB | 按需 |
3.2 系统基础配置(所有节点)
bash复制# 关闭swap
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
# 设置主机名解析(所有节点)
cat <<EOF | sudo tee -a /etc/hosts
192.168.1.101 master1
192.168.1.102 master2
192.168.1.103 master3
192.168.1.201 worker1
EOF
# 加载内核模块
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
overlay
EOF
# 设置系统参数
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
sudo sysctl --system
4. 多Master集群部署实战
4.1 首个Master节点初始化
bash复制sudo kubeadm init \
--control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" \
--upload-certs \
--pod-network-cidr=10.244.0.0/16 \
--service-cidr=10.96.0.0/12 \
--image-repository registry.aliyuncs.com/google_containers
关键参数说明:
--control-plane-endpoint: 负载均衡器的VIP地址--upload-certs: 自动上传证书供其他Master节点使用--image-repository: 使用国内镜像源加速下载
初始化成功后,记下输出的join命令(包含证书哈希和token)。
4.2 加入其他Master节点
在其他两个Master节点上执行:
bash复制sudo kubeadm join LOAD_BALANCER_DNS:LOAD_BALANCER_PORT \
--token <token> \
--discovery-token-ca-cert-hash sha256:<hash> \
--control-plane \
--certificate-key <key-from-init-output>
4.3 部署网络插件(Calico示例)
bash复制kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
验证节点状态:
bash复制kubectl get nodes -o wide
5. 高可用关键配置详解
5.1 etcd集群健康检查
bash复制# 在任一Master节点执行
sudo ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
预期输出应显示所有etcd成员状态为healthy。
5.2 负载均衡器配置(HAProxy示例)
text复制frontend k8s-api
bind *:6443
mode tcp
option tcplog
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
5.3 关键组件高可用策略
-
kube-apiserver:
- 通过负载均衡实现流量分发
- 每个Master节点运行独立实例
-
etcd:
- 使用Raft共识算法保证数据一致性
- 定期备份快照(建议使用etcdctl snapshot save)
-
控制平面Pod:
- 使用--leader-elect=true参数确保单实例运行
- 通过kube-system命名空间的Endpoint对象实现自动故障转移
6. 运维实践与故障排查
6.1 证书管理技巧
查看证书过期时间:
bash复制sudo kubeadm certs check-expiration
更新证书(在过期前):
bash复制sudo kubeadm certs renew all
6.2 常见问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| kube-apiserver无法连接etcd | 证书不匹配 | 检查/etc/kubernetes/pki下的证书文件 |
| Worker节点NotReady | 网络插件未正确安装 | 重新应用CNI插件配置 |
| etcd集群状态异常 | 节点间时钟不同步 | 安装chrony并同步时间 |
| Pod无法跨节点通信 | 防火墙规则阻止 | 开放VXLAN端口(通常4789) |
6.3 监控与告警建议
必备监控指标:
- etcd存储空间使用率(超过80%需告警)
- API Server请求延迟(P99>1s需调查)
- 控制平面组件内存使用率
- 节点NotReady状态持续时间
推荐使用Prometheus Operator配合Grafana搭建监控面板。
7. 生产环境优化建议
7.1 性能调优参数
yaml复制# /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --target-ram-mb=8192 # 根据内存调整
- --max-requests-inflight=1500
- --max-mutating-requests-inflight=500
7.2 安全加固措施
- 启用RBAC并遵循最小权限原则
- 定期轮换ServiceAccount token
- 使用NetworkPolicy限制Pod间通信
- 启用API Server的审计日志
7.3 备份与恢复方案
etcd定期备份脚本:
bash复制#!/bin/bash
DATE=$(date +%Y%m%d)
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-snapshot-${DATE}.db
恢复步骤:
- 停止所有API Server
- 使用etcdctl snapshot restore
- 重启集群组件
8. 架构演进与扩展思考
随着业务规模扩大,可以考虑:
- 引入单独的etcd集群(与控制平面解耦)
- 使用kube-vip替代外部负载均衡器
- 部署区域感知的调度策略(topologySpreadConstraints)
- 评估ARM架构节点混合部署方案
在实际运维中,我们发现Master节点磁盘IO性能对集群稳定性影响极大,建议使用SSD并单独挂载/var/lib/etcd目录。另外,etcd的定期碎片整理(defrag)也能显著提升写入性能,可以在业务低峰期通过etcdctl执行。
