疯狂的SRE

深色模式

kube-apiserver 高可用与性能 ​

摘要：本文面向生产 SRE 与平台工程师，讲清 kube-apiserver 为何"无状态却最难挂"、如何水平扩展做 HA、它与 etcd 的关系，以及如何用 API Priority and Fairness（APF）在过载时保护关键流量。覆盖版本：Kubernetes v1.28+（APF 于 v1.29 GA）。

适用版本与前提 ​

  • Kubernetes：v1.28+（APF 在 v1.29 达 Stable，默认启用）
  • 组件：kube-apiserver、etcd、负载均衡器
  • 前提：理解 HA 基本概念、TLS、etcd 角色（见本分类 etcd 一文）

背景与问题：为什么 API Server 是"唯一入口" ​

kube-apiserver 是控制面的前端，负责校验并持久化所有 API 对象，并提供集群共享状态的 REST 接口。所有其他组件——scheduler、controller-manager、kubelet、kubectl、各控制器——都只通过它与 etcd 交互。它不存状态（状态在 etcd），因此本身可以无视状态地横向扩展。

关键认知

API Server 的"难挂"来自两点：(1) 无状态，可以随便多开副本；(2) 它是唯一写 etcd 的组件，所以 etcd 的写入瓶颈决定了整个集群的写入天花板，而非 API Server 实例数。

高可用架构 ​

  • 多副本 + LB：部署 3+ 个 kube-apiserver 实例，前面挂负载均衡器（如云 LB、HAProxy、keepalived + VIP）。客户端（kubelet、kubectl）只配 LB 地址。
  • 状态在 etcd：任何副本挂了，其余照常服务；新副本起来即加入，无需数据同步。
  • scheduler / controller-manager 的选主：它们各自通过 etcd Lease 做 leader election，多副本只为冗余，同一刻只有一个 active。

冷启动与滚动升级

滚动升级 API Server 时，务必逐个滚动、保证至少 2 个实例在线，避免客户端瞬时全部失败。升级前确认与 etcd 版本兼容（K8s 对 etcd 版本有要求，见 etcd 一文）。

关键配置与性能旋钮 ​

与 etcd 的连接 ​

bash
kube-apiserver \
  --etcd-servers=https://10.0.0.1:2379,https://10.0.0.2:2379,https://10.0.0.3:2379 \
  --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt \
  --etcd-certfile=/etc/kubernetes/pki/etcd/server.crt \
  --etcd-keyfile=/etc/kubernetes/pki/etcd/server.key

鉴权与准入 ​

  • --authorization-mode=RBAC：生产必须开启，切勿 AlwaysAllow。
  • --enable-admission-plugins=NodeRestriction,...：如 NodeRestriction（限制 kubelet 只能改自己的 Node）、PodSecurity、ResourceQuota 等。
  • --anonymous-auth=false（或仅保留只读匿名）以减少攻击面。

审计 ​

bash
kube-apiserver \
  --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
  --audit-log-path=/var/log/kubernetes/audit.log \
  --audit-log-format=json

API Priority and Fairness（APF）：过载保护 ​

这是生产 API Server 性能治理的核心。旧模型用两个全局硬限 --max-requests-inflight / --max-mutating-requests-inflight：所有请求抢同一池子，一个失控的控制器 LIST 就能把 kubelet 心跳、leader election 挤掉。APF 解决了这个问题。

APF 自 v1.29 起 Stable、默认启用（flag --enable-priority-and-fairness）。它用两类对象做细粒度流量整形：

  • FlowSchema：按请求属性（用户、组、verb、resource、namespace）分类请求，并指派优先级。
  • PriorityLevelConfiguration：为每个优先级定义并发份额（nominalConcurrencyShares）与队列/拒绝策略。

内置优先级级别（v1 API）已保护关键流量：exempt（绕过）、node-high、system、leader-election、workload-high、workload-low、global-default、catch-all。这样即使某个 workload 把 workload-low 打满，kubelet 心跳（node-high）、leader election 仍能拿到配额。

版本相关

  • APF 自 v1.20 默认开启 beta，v1.29 达 GA（stable flowcontrol.apiserver.k8s.io/v1）。
  • v1beta3 API 在 v1.29 弃用、于 v1.32 不再服务；升级到 v1.32 前需把残留 v1beta3 清单转成 v1，否则升级会被阻断。
  • 长连接类请求（如 exec/attach/日志流式）不受 APF 限制，同样也不受旧 max-inflight 限制。

查看与排障 APF ​

bash
kubectl get prioritylevelconfigurations
kubectl get flowschemas
# 查看某请求被拒/排队：关注 apiserver 的 apf 指标与 429 响应

自定义保护

若某业务控制器过于活跃，可新建 FlowSchema 把其 ServiceAccount 指向低优先级的 PriorityLevelConfiguration，或用 Reject 策略直接拒绝超额请求，保护控制面。但 exempt 级别要极谨慎——广泛 exempt 会让单客户端打满 API Server。

常见失败模式 ​

  • API Server 全部副本不可用：已运行 Pod 不受影响，但新调度、扩缩容、自愈全部停摆；kubelet 心跳中断后节点转 Unknown。
  • etcd 慢导致 API Server 慢：写入延迟高，所有变更卡住；根因在 etcd（磁盘/网络），而非 API Server 本身。
  • 失控控制器打满 API：没有 APF 或 APF 配置被改坏时，某客户端 LIST/WATCH 风暴拖垮整个控制面。
  • LB 单点：API Server 多副本但 LB 故障，等效于 API Server 全挂。LB 自身也要 HA。
  • 证书过期：API Server 与 etcd / kubelet 的 TLS 证书到期会导致全面失联，需纳入轮换与到期监控。

回滚与清理 ​

生产危险

变更 kube-apiserver 配置/升级属于控制面变更，错误配置会导致整个集群不可用。务必先确认 etcd 备份可用，并采用"先单副本灰度、再全量"的滚动策略。

bash
# kubeadm 集群：控制面以 static pod 运行，改 /etc/kubernetes/manifests/kube-apiserver.yaml
# 改完 kubelet 会自动重启该 static pod；回滚即还原该文件
ls /etc/kubernetes/manifests/kube-apiserver.yaml
cp /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/kube-apiserver.yaml.bak.$(date +%F)
# 编辑后观察日志
journalctl -u kubelet -f
# 或容器视角
crictl ps | grep kube-apiserver

安全与合规 ​

  • RBAC 强制：关闭匿名写，按最小权限授予 ServiceAccount 与用户。
  • 准入控制：启用 NodeRestriction、PodSecurity、ResourceQuota 等，拦截危险对象。
  • 审计日志：记录谁在何时对什么资源做了什么，是安全溯源基础；注意审计日志自身有磁盘与吞吐成本（audit-log-mode 可选 batch 降低阻塞）。
  • 加密传输：secure port 全程 mTLS；关闭不必要的非安全端口。

性能、容量与成本 ​

  • API Server 实例数提升读/校验吞吐与可用性，但不突破 etcd 写入上限。调优顺序：先治 etcd，再扩 API Server。
  • 大集群（数千节点、数十万对象）下 API Server 内存与 CPU 随 watch 连接数、对象量增长；按负载做容量规划与压测。
  • APF 的全局并发上限仍受 --max-requests-inflight / --max-mutating-requests-inflight 约束，它们作为兜底上限存在。

可观测性 ​

  • kube-apiserver：请求延迟分位（读/写）、inflight 请求数、被 APF 拒绝/排队数、与 etcd 的交互延迟。
  • 关注 rest_client_request_duration_seconds（各客户端视角）定位"谁在打 API"。
  • 日志：关注 Throttling、超时、与 etcd 连接断开等告警。

替代方案与权衡 ​

  • 聚合层（API Aggregation）：把自定义 API 扩展到独立扩展服务（如 metrics-server、cert-manager 的 webhook）。扩展服务自身也要考虑 APF 递归场景——若扩展服务在处理请求时会回调 apiserver，需把回调请求豁免或指向更高优先级，避免死锁/优先级反转。
  • 托管控制面：云厂商负责 API Server 多副本与升级，但你失去对 feature gate、部分 flag 的控制力，且仍需自己管 RBAC/准入。

FAQ ​

Q：开更多 kube-apiserver 能解决写入慢吗？ A：不能。写入最终都落到单个 etcd leader。多副本只提升并发读与可用性。写入慢先查 etcd。

Q：APF 开启后还有必要配 max-inflight 吗？ A：需要。max-inflight 仍是全局并发的总上限（兜底），APF 在其内做更细的优先级与公平排队。

参考资料 ​

基于 VitePress 构建 · 托管于阿里云 ECS

Copyright © 2026 CrazySRE