📚 课程目录第3章高可用控制面架构

3. 高可用控制面架构：多Master架构设计原理、负载均衡器（HAProxy/Nginx）的引入与选型

在生产环境中，Kubernetes 控制面的单点故障是不可接受的。当唯一的 kube-apiserver 或 controller-manager 宕机时，整个集群将失去管理能力，正在运行的工作负载虽不会立即终止，但无法进行扩缩容、滚动更新或故障恢复。因此，构建高可用（HA）控制面是生产级集群的必备条件。本节将深入剖析多 Master 架构的设计原理，并详细对比负载均衡器的引入动机与选型策略。

3.1 多Master架构设计原理

高可用控制面的核心思想是消除单点故障，通过冗余部署和组件间的选主机制实现故障自动转移。一个典型的多 Master 架构包含以下关键设计原则：

组件冗余：kube-apiserver、kube-controller-manager、kube-scheduler 均部署在多个节点上（通常为 3 或 5 个奇数节点）。
无状态 vs 有状态：kube-apiserver 是无状态的，所有数据存储在 etcd 中，因此可以水平扩展；controller-manager 和 scheduler 通过 etcd 中的租约（Lease）机制进行选主，同一时刻只有一个实例处于活跃状态。
etcd 集群：作为控制面的状态存储，etcd 自身必须部署为 Raft 集群（通常 3 或 5 节点），保证强一致性和高可用。
前端负载均衡：所有外部客户端（kubectl、kubelet、scheduler、controller-manager）以及集群内部组件对 apiserver 的访问，必须经过一个统一的负载均衡器，将流量分发到多个 apiserver 实例。

架构要点：多 Master 架构中，apiserver 是唯一与 etcd 直接交互的组件。controller-manager 和 scheduler 通过 apiserver 间接读写集群状态，并利用 apiserver 提供的选举 API 实现领导者选举。

下图展示了标准的多 Master 高可用控制面架构，包含负载均衡器、多个 apiserver 实例以及 etcd 集群的关系：

3.2 负载均衡器的引入动机

在多 Master 架构中，负载均衡器扮演着流量入口和故障屏蔽的双重角色。其核心动机包括：

统一入口：所有对 apiserver 的请求（来自 kubectl、kubelet、scheduler、controller-manager、Webhook 等）都通过一个稳定的虚拟 IP 或 DNS 名称访问，屏蔽后端 apiserver 的 IP 变化。
健康检查与自动摘除：负载均衡器定期对后端 apiserver 进行健康检查（通常检查 /livez 或 /readyz 端点），当某个 apiserver 实例宕机或未就绪时，自动将其从转发池中移除，避免请求失败。
流量分发：将请求均匀分发到多个 apiserver 实例，避免单个实例过载，提升整体吞吐量。
TLS 终止（可选）：在负载均衡器层统一处理 TLS 证书，简化后端 apiserver 的证书管理。

关键注意：kubelet 和 kube-proxy 等节点组件默认通过 apiserver 的 IP 或 DNS 直连。引入负载均衡器后，必须确保所有组件（包括 kubelet、scheduler、controller-manager）的 --master 或 --kubeconfig 配置指向负载均衡器的地址，而非单个 apiserver 的地址。

3.3 负载均衡器选型对比：HAProxy vs Nginx

在 Kubernetes 控制面场景中，HAProxy 和 Nginx 是最常用的两种负载均衡方案。下表从多个维度对两者进行对比：

对比维度	HAProxy	Nginx
核心定位	专业 TCP/HTTP 负载均衡器	全能型 Web 服务器 + 反向代理 + 负载均衡
性能（L4 转发）	极高，单机可达数百万并发连接	高，但略低于 HAProxy
健康检查	原生支持 TCP、HTTP、SSL 等多种检查方式，配置灵活	支持 HTTP 健康检查，但 TCP 检查需额外模块
配置复杂度	配置语法简洁，专注负载均衡	配置较复杂，需区分 stream 和 http 上下文
动态重载	支持优雅重载（reload），不中断现有连接	支持热重载，但需注意 worker 进程管理
日志与监控	提供详细的统计页面（Stats Page）和结构化日志	日志功能强大，但需额外配置
社区与生态	Kubernetes 社区推荐方案，kubeadm 原生支持	广泛使用，但非 kubeadm 默认
适用场景	纯负载均衡场景，尤其是 L4 转发	需要同时处理 Web 服务、API 网关和负载均衡的场景

3.4 典型配置示例

以下是一个针对 Kubernetes apiserver 的 HAProxy 配置示例，展示了健康检查、负载均衡算法和统计页面的配置：

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode tcp
    option tcplog
    option dontlognull
    retries 3
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend k8s-api-frontend
    bind *:6443
    default_backend k8s-api-backend

backend k8s-api-backend
    balance roundrobin
    option tcp-check
    tcp-check connect
    tcp-check send GET\ /livez\ HTTP/1.0\r\n
    tcp-check send Host:\ apiserver.local\r\n
    tcp-check send User-Agent:\ haproxy-health-check\r\n
    tcp-check expect string ok
    server master-1 192.168.1.10:6443 check inter 5s fall 3 rise 2
    server master-2 192.168.1.11:6443 check inter 5s fall 3 rise 2
    server master-3 192.168.1.12:6443 check inter 5s fall 3 rise 2

listen stats
    bind *:8404
    mode http
    stats enable
    stats uri /stats
    stats refresh 10s
    stats auth admin:password

  配置要点解析：
  mode tcp：使用 L4 模式转发，避免 TLS 解密开销，apiserver 自身处理 TLS。
option tcp-check：通过 TCP 连接发送 HTTP 请求到 /livez 端点，检查 apiserver 存活状态。
balance roundrobin：轮询算法，适合 apiserver 这种无状态服务。
check inter 5s fall 3 rise 2：每 5 秒检查一次，连续 3 次失败则标记为宕机，连续 2 次成功则恢复。

3.5 选型建议与最佳实践

根据生产环境经验，以下选型建议可供参考：

优先选择 HAProxy：如果集群规模较大（超过 100 节点），或对 L4 转发性能有极致要求，HAProxy 是更专业的选择。kubeadm 在 kubeadm init 和 kubeadm join 中也原生支持配置 HAProxy 作为前端负载均衡器。
Nginx 适合中小规模：如果团队对 Nginx 更熟悉，且集群规模较小（少于 50 节点），Nginx 的 stream 模块完全可以胜任。同时，Nginx 可以复用为 Ingress Controller，减少组件数量。
避免使用云厂商 LB 直连 apiserver：云厂商的负载均衡器（如 AWS NLB、GCP TCP LB）通常不支持精细的健康检查（如检查 /livez 端点），建议在云 LB 后端再部署一层 HAProxy 或 Nginx。
部署方式：负载均衡器可以部署在独立的节点上，也可以与 Master 节点混部。建议使用 Keepalived 为负载均衡器提供 VIP 高可用，避免 LB 自身成为单点。

生产建议：在大型生产集群中，推荐使用 HAProxy + Keepalived 的组合方案。HAProxy 负责流量分发和健康检查，Keepalived 提供虚拟 IP（VIP）漂移，确保负载均衡器自身的高可用。同时，将 HAProxy 的统计页面绑定到内网管理地址，方便运维人员实时查看后端状态。

下图展示了 HAProxy + Keepalived 的高可用负载均衡方案，其中两台 HAProxy 实例通过 Keepalived 共享一个 VIP，实现故障自动切换：