📚 课程目录第3章 kube-apiserver高可用部署模式

3. kube-apiserver 高可用部署模式：静态 Pod vs 二进制部署、负载均衡策略、Leader Election 机制、健康检查端点

在生产环境中，kube-apiserver 作为 Kubernetes 控制面的核心网关，其高可用性直接决定了集群的稳定性和可运维性。本章深入剖析四种关键的高可用设计维度：部署模式选型、流量分发策略、选主机制以及健康探测体系，为后续的回滚验证操作奠定架构基础。

3.1 部署模式对比：静态 Pod vs 二进制部署

kube-apiserver 的高可用部署主要采用两种模式：静态 Pod 模式（由 kubelet 直接管理）和二进制部署模式（由 systemd 或 supervisord 管理）。两种模式在生产环境中均有广泛应用，但运维模型和回滚策略存在显著差异。

对比维度	静态 Pod 模式	二进制部署模式
管理方式	kubelet 监听静态 Pod 清单目录（`/etc/kubernetes/manifests/`）	systemd 单元文件或进程管理器直接控制
版本切换	替换 YAML 清单中的镜像 Tag，kubelet 自动拉取并重启	替换二进制文件 + 重启 systemd 服务
回滚速度	快速：修改镜像 Tag 即可触发回滚	中等：需替换二进制并 reload 服务
依赖关系	依赖 kubelet 正常运行，且 kubelet 版本需兼容	独立于 kubelet，可单独控制
日志持久化	容器日志默认由 kubelet 管理，需额外配置持久化	直接写入宿主机 journald 或文件
适用场景	kubeadm 部署、标准化集群、快速迭代环境	定制化集群、严格合规环境、离线部署

生产建议： 在回滚验证场景中，静态 Pod 模式因其“声明式镜像切换”特性，回滚操作更原子化且易于自动化。二进制部署模式虽然灵活，但回滚时需要额外关注二进制文件校验和依赖库兼容性。

3.2 负载均衡策略：流量分发与故障转移

高可用的 kube-apiserver 集群通常由 3 个或 5 个实例组成，前端通过负载均衡器分发流量。负载均衡策略直接影响客户端（kubelet、kube-controller-manager、kube-scheduler、kubectl）的连接稳定性和故障转移效率。

3.2.1 主流负载均衡方案

硬件/云负载均衡器：如 F5、AWS NLB、GCP TCP/UDP Load Balancer，支持 TCP 健康检查，延迟低。
软件负载均衡器：如 HAProxy、Nginx、Envoy，可配置更精细的健康检查和权重。
DNS 轮询：通过多个 A 记录实现简单分发，但无法感知后端健康状态，不推荐生产使用。
客户端侧负载均衡：kubeconfig 中配置多个 apiserver 地址，由客户端自行选择（如 --apiserver-list）。

3.2.2 健康检查与流量切换

负载均衡器必须配置正确的健康检查端点，才能在后端实例故障时及时摘除流量。kube-apiserver 提供多个健康检查路径，不同路径的语义不同：

端点路径	HTTP 状态码	检查语义	推荐用途
`/healthz`	200 表示健康	基础存活检查，不验证 etcd 连通性	负载均衡器存活探测
`/livez`	200 表示存活	与 `/healthz` 类似，但更细粒度	Kubernetes 1.16+ 推荐
`/readyz`	200 表示就绪	验证 apiserver 是否准备好接收流量（含 etcd 连通性）	负载均衡器就绪探测
`/livez?exclude=etcd`	200 即使 etcd 不可用	排除 etcd 依赖的存活检查	etcd 故障时保留 apiserver 缓存服务

关键配置： 负载均衡器的健康检查应使用 /readyz 端点，而非 /healthz。因为 /readyz 会验证 etcd 连通性，确保流量只分发到后端数据面完整的 apiserver 实例。仅使用 /healthz 可能导致流量被分发到 etcd 连接已断开的实例，造成客户端请求失败。

3.3 Leader Election 机制：选主与一致性保障

kube-apiserver 本身是无状态的，但集群中的控制器组件（kube-controller-manager、kube-scheduler）以及 kube-apiserver 对 etcd 的写入操作需要选主机制来保证一致性。kube-apiserver 的 Leader Election 通过 etcd 分布式锁 实现，选举结果存储在 etcd 的 /registry/leases/ 路径下。

3.3.1 选举流程

租约创建：每个 apiserver 实例启动时，尝试在 etcd 中创建或更新一个 Lease 对象，携带唯一的身份标识（identity）。
心跳续约：Leader 实例定期（默认 10 秒）更新 Lease 的 renewTime，表示自己仍然存活。
故障检测：Follower 实例监控 Lease 的 renewTime，如果超过 leaseDuration（默认 15 秒）未更新，则认为 Leader 失联。
抢占选举：Follower 实例尝试更新 Lease 的 holderIdentity 为自己的身份，第一个成功写入 etcd 的实例成为新 Leader。
角色切换：新 Leader 开始处理写请求，旧 Leader 恢复后自动降级为 Follower。

3.3.2 关键参数

参数	默认值	说明
`--leader-elect-lease-duration`	15s	Lease 有效期，超过此时间未续约则触发选举
`--leader-elect-renew-deadline`	10s	Leader 必须在此时限内完成续约，否则视为失联
`--leader-elect-retry-period`	2s	Follower 尝试抢占选举的间隔

  回滚影响分析： 在 kube-apiserver 回滚过程中，如果当前 Leader 实例被重启，集群会触发重新选举。回滚操作应尽量在非 Leader 实例上分批执行，避免同时重启多个实例导致选举风暴。建议在回滚前通过 kubectl get leases -n kube-system 确认当前 Leader 身份。

3.4 健康检查端点：探测体系与故障隔离

kube-apiserver 内置了多层次的健康检查端点，用于不同粒度的故障检测。正确配置这些端点，可以在回滚过程中快速识别异常实例并隔离流量。

3.4.1 端点分类与语义

存活检查（Liveness）：/livez — 检测 apiserver 进程是否存活，不验证后端依赖。适用于 kubelet 的容器重启策略。
就绪检查（Readiness）：/readyz — 检测 apiserver 是否准备好接收流量，验证 etcd 连通性和缓存同步状态。适用于负载均衡器流量分发。
启动检查（Startup）：/healthz?verbose — 返回所有健康检查项的详细状态，适用于启动阶段的慢启动保护。
排除检查（Exclude）：/livez?exclude=etcd — 排除 etcd 依赖，仅检查 apiserver 自身状态。适用于 etcd 故障时保留 apiserver 的缓存服务能力。

3.4.2 健康检查配置示例

以下为静态 Pod 模式下 kube-apiserver 的健康检查配置片段：

# kube-apiserver 静态 Pod YAML 中的健康检查配置
livenessProbe:
  httpGet:
    path: /livez
    port: 6443
    scheme: HTTPS
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /readyz
    port: 6443
    scheme: HTTPS
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 2

回滚验证关键点： 在回滚过程中，应持续监控 /readyz 端点的返回状态。如果回滚后的 apiserver 实例无法通过 /readyz 检查，说明其与 etcd 的连接或数据一致性存在问题，应立即停止流量并回退到上一版本。建议在回滚脚本中加入 curl -k --fail https://localhost:6443/readyz 作为前置验证步骤。

3.5 本章小结

kube-apiserver 的高可用部署涉及多个维度的协同设计：

部署模式：静态 Pod 模式更适合标准化集群和快速回滚，二进制部署模式适合定制化场景。
负载均衡：必须使用 /readyz 端点进行健康检查，确保流量只分发到数据面完整的实例。
Leader Election：回滚时应避免同时重启多个实例，优先在非 Leader 实例上操作。
健康检查：分层配置存活、就绪和启动检查，实现精细化的故障隔离。