1. Kubernetes高可用集群架构设计基础

在生产环境中部署Kubernetes集群时，高可用性(High Availability, HA)是最基本的要求之一。一个设计良好的HA架构能够确保即使部分节点发生故障，整个集群仍能持续提供服务。kubeadm作为官方推荐的集群部署工具，提供了两种主流的HA拓扑方案：堆叠式etcd(Stacked etcd)和外部etcd(External etcd)。

高可用集群的核心在于消除单点故障。对于Kubernetes控制平面而言，这意味着需要冗余部署以下关键组件：

• kube-apiserver：集群的入口网关，所有控制面和数据面通信都要经过它
• kube-controller-manager：负责维护集群的各种控制循环
• kube-scheduler：负责将Pod调度到合适的节点
• etcd：集群的分布式键值存储，保存所有集群状态数据

重要提示：无论选择哪种拓扑结构，都建议至少使用三个控制平面节点。这是因为etcd作为分布式系统，需要多数节点(quorum)才能正常运作，三个节点可以容忍一个节点故障，五个节点可以容忍两个节点故障，依此类推。

2. 堆叠式etcd拓扑架构详解

2.1 架构组成与工作原理

堆叠式etcd拓扑是最常见的部署方式，也是kubeadm默认采用的方案。在这种架构中，每个控制平面节点都运行以下组件：

• 一个kube-apiserver实例
• 一个kube-scheduler实例
• 一个kube-controller-manager实例
• 一个etcd成员

这些组件通过本地通信，形成如下图所示的架构：

[控制平面节点1] ├── kube-apiserver ├── kube-scheduler ├── kube-controller-manager └── etcd成员1 [控制平面节点2] ├── kube-apiserver ├── kube-scheduler ├── kube-controller-manager └── etcd成员2 [控制平面节点3] ├── kube-apiserver ├── kube-scheduler ├── kube-controller-manager └── etcd成员3 [负载均衡器] ↑ [工作节点]

2.2 堆叠式架构的优势

1. 部署简单：kubeadm init和kubeadm join --control-plane命令会自动配置本地etcd成员，无需额外设置
2. 管理方便：所有组件集中在相同节点，减少了运维复杂度
3. 资源利用率高：相比外部etcd方案，需要的机器数量更少
4. 网络延迟低：控制平面组件与etcd成员通过本地通信，减少了网络开销

2.3 堆叠式架构的局限性

1. 耦合风险：当某个控制平面节点故障时，会同时丢失一个控制平面实例和一个etcd成员
2. 扩展性限制：增加控制平面节点会同时增加etcd成员，可能影响etcd集群性能
3. 升级复杂度：升级Kubernetes版本时需要同时考虑etcd版本的兼容性

2.4 适用场景分析

堆叠式etcd拓扑特别适合以下场景：

• 中小规模集群(节点数在100以内)
• 资源受限的环境
• 需要快速部署和简单维护的场景
• 对网络延迟敏感的应用

3. 外部etcd拓扑架构深度解析

3.1 架构组成与通信模式

外部etcd拓扑将etcd集群与Kubernetes控制平面物理分离，形成两个独立的集群：

[etcd集群] ├── etcd节点1 ├── etcd节点2 └── etcd节点3 [控制平面集群] ├── 控制平面节点1 │ ├── kube-apiserver │ ├── kube-scheduler │ └── kube-controller-manager ├── 控制平面节点2 │ ├── kube-apiserver │ ├── kube-scheduler │ └── kube-controller-manager └── 控制平面节点3 ├── kube-apiserver ├── kube-scheduler └── kube-controller-manager [负载均衡器] ↑ [工作节点]

3.2 外部etcd架构的优势

1. 更高的可用性：etcd和控制平面故障域隔离，单个节点故障影响范围更小
2. 独立扩展：可以根据需要独立扩展etcd集群或控制平面
3. 灵活升级：可以分别升级Kubernetes和etcd版本
4. 性能隔离：etcd的I/O密集型操作不会影响控制平面组件的性能

3.3 外部etcd架构的挑战

1. 部署复杂度高：需要先独立部署etcd集群，再部署Kubernetes控制平面
2. 资源需求大：至少需要6台机器(3台etcd + 3台控制平面)
3. 网络要求高：etcd集群和控制平面之间需要稳定、低延迟的网络连接
4. 运维成本高：需要维护两个独立的集群

3.4 适用场景推荐

外部etcd拓扑特别适合以下场景：

• 大规模生产环境(节点数超过100)
• 对可用性要求极高的关键业务系统
• 需要频繁扩展或升级的环境
• 有专门团队负责基础设施维护的组织

4. 生产环境部署建议与最佳实践

4.1 节点规格选择

对于控制平面节点，建议配置：

• CPU: 4核以上
• 内存: 8GB以上
• 存储: 100GB以上SSD(如果使用堆叠式etcd，需要更高性能的存储)

对于专用etcd节点(外部etcd拓扑)，建议配置：

• CPU: 4-8核
• 内存: 16GB以上
• 存储: 高性能SSD，容量根据集群规模而定(通常100GB起步)

4.2 网络配置要点

1. 延迟要求：etcd对网络延迟非常敏感，建议节点间RTT不超过5ms
2. 带宽要求：建议10Gbps网络，特别是对于大型集群
3. 隔离考虑：生产环境建议将etcd和控制平面流量与数据平面流量隔离

4.3 负载均衡配置

无论采用哪种拓扑，都需要为kube-apiserver配置负载均衡器：

• 可以使用硬件负载均衡器(F5等)或软件方案(HAProxy、Nginx等)
• 健康检查应配置为对/apiserver端点进行定期探测
• 建议使用TCP而非HTTP健康检查，避免证书问题

4.4 证书管理策略

1. etcd证书：为每个etcd成员配置单独的服务器证书
2. 客户端证书：kube-apiserver访问etcd需要客户端证书
3. 定期轮换：设置合理的证书有效期并建立轮换机制
4. 备份策略：妥善备份CA和所有关键证书

4.5 监控与告警配置

必须监控的关键指标包括：

• etcd集群健康状态(leader是否存在、节点是否健康)
• etcd存储空间使用情况
• etcd请求延迟和吞吐量
• 控制平面组件(API Server、Controller Manager、Scheduler)的运行状态
• 节点资源使用情况(CPU、内存、磁盘、网络)

4.6 备份与灾难恢复

1. 定期备份etcd数据：使用etcdctl snapshot save命令
2. 测试恢复流程：定期验证备份的有效性
3. 文档化恢复流程：详细记录各种故障场景的恢复步骤
4. 考虑地理冗余：对于关键业务，考虑跨可用区甚至跨地域部署

5. kubeadm部署HA集群的实操要点

5.1 堆叠式etcd集群部署流程

1. 初始化第一个控制平面节点：

kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" \ --upload-certs \ --pod-network-cidr=10.244.0.0/16

2. 加入其他控制平面节点：

kubeadm join LOAD_BALANCER_DNS:LOAD_BALANCER_PORT \ --token <token> \ --discovery-token-ca-cert-hash sha256:<hash> \ --control-plane \ --certificate-key <cert-key>

3. 验证etcd集群状态：

kubectl get pods -n kube-system -l component=etcd 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 \ member list

5.2 外部etcd集群部署流程

1. 先部署etcd集群：

• 在各etcd节点上安装etcd
• 配置etcd集群的peer通信和客户端端点
• 确保etcd集群健康

2. 生成etcd相关证书：

kubeadm alpha certs etcd-ca kubeadm alpha certs etcd-server --etcd-server-certs-dir=/etc/kubernetes/pki/etcd kubeadm alpha certs etcd-peer --etcd-peer-certs-dir=/etc/kubernetes/pki/etcd kubeadm alpha certs etcd-healthcheck-client --etcd-healthcheck-client-certs-dir=/etc/kubernetes/pki/etcd kubeadm alpha certs apiserver-etcd-client --apiserver-etcd-client-certs-dir=/etc/kubernetes/pki/apiserver-etcd-client

3. 初始化第一个控制平面节点：

kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" \ --upload-certs \ --pod-network-cidr=10.244.0.0/16 \ --etcd-external-endpoints=https://ETCD_NODE1_IP:2379,https://ETCD_NODE2_IP:2379,https://ETCD_NODE3_IP:2379 \ --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt \ --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \ --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key

5.3 常见问题排查技巧

1. etcd集群健康检查失败：

• 检查网络连接和防火墙规则
• 验证证书是否正确配置
• 检查etcd日志是否有错误信息

2. 控制平面组件无法启动：

• 检查kubelet日志：journalctl -u kubelet -f
• 验证各组件容器的运行状态：crictl ps -a
• 检查证书是否过期：kubeadm certs check-expiration

3. 节点无法加入集群：

• 检查token是否有效
• 验证discovery-token-ca-cert-hash是否正确
• 确保新节点能够访问负载均衡器端点

在实际部署中，我经常遇到的一个问题是证书配置错误导致的etcd通信失败。一个实用的调试技巧是使用openssl s_client命令测试etcd端点的连通性：

openssl s_client -connect ETCD_NODE_IP:2379 -CAfile /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key

另一个常见问题是资源不足导致的etcd性能下降。可以通过监控etcd的指标来识别这类问题：

# 查看etcd指标 curl --cacert /etc/kubernetes/pki/etcd/ca.crt \ --cert /etc/kubernetes/pki/etcd/server.crt \ --key /etc/kubernetes/pki/etcd/server.key \ https://127.0.0.1:2379/metrics | grep -E 'etcd_disk_wal_fsync_duration_seconds|etcd_network_peer_round_trip_time_seconds'