1. Kubernetes高可用架构基础概述
在容器编排领域,Kubernetes已成为事实标准。当我们将生产环境迁移到Kubernetes时,高可用性(High Availability, HA)是必须考虑的关键特性。本系列将深入探讨基于containerd运行时构建Kubernetes高可用集群的架构设计与实施准备。
1.1 为什么需要Kubernetes高可用
生产级Kubernetes集群必须满足以下核心需求:
- 控制平面冗余:避免单点故障导致整个集群不可用
- 工作节点弹性:当部分节点故障时,工作负载能自动迁移
- 数据持久性:关键组件如etcd需要可靠的数据存储方案
- 零停机升级:支持滚动更新而不中断服务
传统单Master架构存在明显瓶颈:
- API Server单点故障会导致所有管理操作中断
- Scheduler/Controller Manager不可用将影响Pod调度
- etcd数据丢失可能造成集群状态不可恢复
1.2 containerd作为容器运行时的优势
相比Docker,containerd提供了更精简的容器运行时方案:
- 性能优化:减少抽象层,直接通过CRI与Kubelet通信
- 资源消耗低:内存占用减少约30%,启动速度快15%
- 稳定性增强:专为生产环境设计的核心功能
- 符合标准:通过CNCF认证,与Kubernetes兼容性更好
典型调用链路对比:
code复制Docker方案:kubelet → dockershim → docker daemon → containerd
Containerd方案:kubelet → cri-plugin → containerd
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 高可用架构核心组件解析
2.1 控制平面多实例部署
实现高可用的核心是部署多个Master节点,关键组件需要特殊配置:
API Server:
- 需要配置负载均衡器(如HAProxy/Nginx)
- 建议使用3或5个实例形成奇数个节点
- 保持各实例配置完全一致
Controller Manager:
- 通过
--leader-elect=true启用领导者选举 - 默认租约时间为15秒
- 故障转移通常能在30秒内完成
Scheduler:
- 同样采用领导者选举机制
- 需确保各节点配置相同的调度策略
- 建议设置
--bind-address=0.0.0.0
2.2 etcd集群设计
作为Kubernetes的大脑,etcd需要特别注意:
部署模式选择:
- Stacked etcd:与Master节点共置,节省资源
- External etcd:独立集群,更高可用性
关键配置参数:
yaml复制# etcd配置示例
name: etcd1
listen-peer-urls: https://192.168.1.101:2380
listen-client-urls: https://192.168.1.101:2379
initial-advertise-peer-urls: https://192.168.1.101:2380
advertise-client-urls: https://192.168.1.101:2379
initial-cluster: etcd1=https://192.168.1.101:2380,etcd2=https://192.168.1.102:2380,etcd3=https://192.168.1.103:2380
性能优化建议:
- 使用SSD存储,建议IOPS > 5000
- 单独部署在非虚拟化物理机上
- 保持时钟同步(NTP误差<50ms)
2.3 网络架构设计
高可用集群需要特殊的网络考虑:
Pod网络方案选择:
- Calico:适合需要网络策略的场景
- Flannel:简单易用,性能良好
- Cilium:基于eBPF的高性能方案
服务暴露方式:
- 使用LoadBalancer Service配合外部负载均衡器
- Ingress Controller需要多副本部署
- 考虑BGP协议实现ECMP负载均衡
3. 准备工作与系统配置
3.1 硬件资源规划
Master节点建议配置:
- CPU: 4核以上
- 内存: 8GB以上
- 磁盘: 100GB系统盘 + 单独etcd数据盘
- 网络: 万兆网卡最佳
Worker节点配置:
根据工作负载需求调整,但建议:
- 每个节点不超过100个Pod
- 预留20%资源缓冲
3.2 操作系统准备
基础配置要求:
-
禁用交换分区:
bash复制swapoff -a sed -i '/ swap / s/^/#/' /etc/fstab -
加载内核模块:
bash复制cat > /etc/modules-load.d/k8s.conf <<EOF br_netfilter overlay EOF modprobe br_netfilter modprobe overlay -
网络参数调整:
bash复制cat > /etc/sysctl.d/k8s.conf <<EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 EOF sysctl --system
3.3 containerd安装与配置
安装最新版containerd:
bash复制# 下载二进制包
wget https://github.com/containerd/containerd/releases/download/v1.6.8/containerd-1.6.8-linux-amd64.tar.gz
# 解压到系统目录
tar Cxzvf /usr/local containerd-1.6.8-linux-amd64.tar.gz
# 生成systemd服务文件
cat > /etc/systemd/system/containerd.service <<EOF
[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target
[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/containerd
Restart=always
RestartSec=5
Delegate=yes
KillMode=process
OOMScoreAdjust=-999
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
[Install]
WantedBy=multi-user.target
EOF
配置containerd:
bash复制mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
# 修改关键参数
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sed -i 's/sandbox_image = ".*"/sandbox_image = "registry.k8s.io\/pause:3.6"/' /etc/containerd/config.toml
4. 常见问题与解决方案
4.1 证书管理问题
多Master节点证书配置:
- 使用统一的CA签发所有节点证书
- SANs字段必须包含所有API Server地址
- 示例openssl配置:
ini复制[ alt_names ] DNS.1 = kubernetes DNS.2 = kubernetes.default DNS.3 = kubernetes.default.svc DNS.4 = kubernetes.default.svc.cluster.local DNS.5 = master1 DNS.6 = master2 DNS.7 = master3 IP.1 = 10.96.0.1 IP.2 = 192.168.1.100 IP.3 = 192.168.1.101 IP.4 = 192.168.1.102
4.2 网络连通性问题
典型故障现象:
- Pod间无法通信
- 服务域名解析失败
- NodePort无法访问
排查步骤:
- 检查CNI插件是否正常运行
- 验证kube-proxy日志是否有错误
- 测试CoreDNS是否响应查询
- 检查iptables/nftables规则
4.3 资源竞争问题
优化建议:
-
为关键组件配置资源限制:
yaml复制apiVersion: v1 kind: Pod metadata: name: kube-apiserver namespace: kube-system spec: containers: - name: kube-apiserver resources: requests: cpu: "2" memory: "4Gi" limits: cpu: "4" memory: "8Gi" -
使用PriorityClass确保关键Pod优先调度
-
配置合理的Eviction阈值
5. 验证与测试方案
5.1 高可用性测试
模拟故障场景:
- 随机停止一个Master节点上的API Server
- 观察kubectl命令响应时间
- 验证新的领导者选举过程
- 检查etcd集群健康状态
预期结果:
- 客户端请求应自动切换到健康节点
- 故障转移时间应小于30秒
- 无数据丢失或服务中断
5.2 性能基准测试
测试工具推荐:
- kube-burner:集群压力测试
- clusterloader2:模拟大规模部署
- etcdctl check perf:etcd性能评估
关键指标:
- API Server延迟:P99 < 500ms
- Pod启动时间:< 2s(已缓存镜像)
- etcd写入延迟:< 50ms
在实际部署中,建议先在小规模环境验证所有配置,再逐步扩展到生产集群。每个Kubernetes版本的行为可能略有不同,因此需要针对特定版本进行充分测试。
