如何构建高可用的 K8s 集群：详解多 Master 节点下的负载均衡与选主机制

构建生产级的高可用（HA）Kubernetes 集群是确保业务连续性的基石。一个高可用的集群意味着即使部分控制平面组件（Master 节点）发生故障，整个集群的管理功能仍然可以正常运行。这主要依赖于两个核心机制：API Server 的负载均衡和 etcd 的选主/数据一致性。

1. 核心挑战与架构概述

为了实现 HA，我们需要至少 3 个 Master 节点（奇数个节点保证 etcd 能够达成法定人数 Quorum）。

• 负载均衡（HA）： 用户和工作节点（Node）不应直接连接到单个 Master 节点的 API Server，而应该通过一个虚拟IP（VIP）或外部负载均衡器访问所有健康的 API Server。
• 选主（一致性）： etcd 是集群的关键状态存储。它使用 Raft 协议确保所有 Master 节点上的数据副本一致，并自动选举出一个 Leader 来处理写入请求。

2. API Server 的负载均衡实现

对于多 Master 节点，我们需要一个 L4 层的 TCP 负载均衡器（如 HAProxy、Keepalived 或云服务商的 LBs）来分发流量到所有 Master 节点上的 6443 端口（kube-apiserver 默认端口）。

步骤 1: 配置外部负载均衡器

假设我们有 3 个 Master 节点，IP 分别为 192.168.1.101, 192.168.1.102, 192.168.1.103。我们设定 Load Balancer 的 VIP 为 192.168.1.100。

以下是一个使用 HAProxy 的负载均衡配置示例（仅作演示，实际生产环境可能使用更复杂的工具或云服务）：

# haproxy.cfg 关键配置片段
frontend kubernetes-api
    bind 192.168.1.100:6443
    mode tcp
    default_backend kube-masters

backend kube-masters
    mode tcp
    balance roundrobin
    # 检查 Master 节点 API Server 的健康状态
    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

步骤 2: 使用 kubeadm 初始化集群

关键在于在 kubeadm init 时，指定 –control-plane-endpoint 参数指向我们配置好的负载均衡器的 VIP。

在第一个 Master 节点上执行初始化：

# 注意：192.168.1.100:6443 是 LB 的 VIP
KUBE_VIP="192.168.1.100:6443"

kubeadm init \
    --control-plane-endpoint $KUBE_VIP \
    --upload-certs \
    --pod-network-cidr=10.244.0.0/16 # 以 Flannel 为例

3. etcd 的选主与一致性

Kubernetes 的高可用性依赖于其内置的 etcd 集群。etcd 默认运行在 Master 节点上，它通过 Raft 协议保证集群状态的一致性，并负责“选主”。

选主机制（Raft 协议）

1. Leader 选举： etcd 节点处于 Leader, Follower 或 Candidate 状态。如果 Leader 宕机，Followers 会发起选举，成为 Candidates，通过投票选出新的 Leader。
2. Quorum（法定人数）： etcd 集群必须维持法定人数（N/2 + 1，N 为节点总数）的节点在线才能正常工作。对于 3 节点集群，至少需要 2 个节点；对于 5 节点集群，至少需要 3 个节点。
3. 数据复制： Leader 负责处理所有写入操作，并将修改日志复制到所有 Follower 节点。

重要提示： 部署 3 个或 5 个 Master 节点是 HA 的黄金准则。不建议部署偶数个节点，因为这不会提高容错能力，反而可能增加网络分区的风险。

4. 添加额外的 Master 节点

当第一个 Master 节点初始化完成后，获取加入集群的 Token，并在第二个和后续 Master 节点上执行加入操作。

请注意使用 –control-plane 标志：

# 假设你的 token 和 hash 已经获取
# master_ip_2 是当前节点的 IP (例如 192.168.1.102)

kubeadm join 192.168.1.100:6443 \
    --token <YOUR_TOKEN> \
    --discovery-token-ca-cert-hash sha256:<YOUR_HASH> \
    --control-plane \
    --apiserver-advertise-address 192.168.1.102

5. 验证集群高可用性

完成所有 Master 节点加入后，可以通过检查 etcd 集群成员和 Pod 状态来验证 HA 是否成功。

验证 etcd 成员

在任一 Master 节点上执行以下命令，查看所有 etcd 成员是否健康：

# 确保使用正确的 etcd 证书路径，在标准 kubeadm 安装中通常是 /etc/kubernetes/pki/etcd
ETCDCTL_API=3 etcdctl member list \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  --key=/etc/kubernetes/pki/etcd/peer.key

# 预期输出将列出所有 3 个 Master 节点，状态 HEALTHY

验证 API Server Pod

确保所有 kube-apiserver Pod 都在运行：

kubectl get pod -n kube-system -o wide | grep kube-apiserver

此时，即使你断开其中一个 Master 节点的网络连接（模拟故障），客户端通过 VIP 仍然可以访问 API Server，并且 etcd 集群会保持 Quorum，确保控制平面高可用。