API Server 架构与高可用设计
API Server（kube-apiserver）是 Kubernetes 控制面的核心网关，所有对集群状态的查询、变更操作都必须经过它。它负责处理 RESTful 请求、执行认证与授权、调用准入控制器，并将最终数据持久化到 etcd。本章深入分析 API Server 的请求处理流程、认证授权准入机制以及高可用部署模式。
2.1 请求处理流程
一个典型的 API 请求从客户端（kubectl、Pod 内部 ServiceAccount、外部系统）到达 API Server，经过完整的处理管道后写入 etcd 或返回缓存数据。整个流程分为三个阶段：HTTP 处理阶段、认证授权准入阶段、存储与响应阶段。
关键路径： 客户端 → TLS 终止 → 认证 → 授权 → 准入 → 对象校验 → etcd 读写 → 响应返回
2.1.1 请求处理阶段分解
| 阶段 | 组件/模块 | 主要职责 |
|---|---|---|
| 1. TLS 终止 | HTTP Server (net/http) | 验证客户端证书，建立双向 TLS 连接 |
| 2. 请求路由 | Mux (路由分发器) | 根据 HTTP 方法和路径匹配对应的 Handler |
| 3. 认证 | Authenticator 链 | 提取并验证用户身份（证书//Proxy） |
| 4. 授权 | Authorizer 链 | 判断用户是否有权限执行请求操作 |
| 5. 准入 | Admission 链 | 修改或验证请求对象（Mutating + Validating） |
| 6. 对象校验 | Schema Validation | 检查请求体是否符合 OpenAPI Schema |
| 7. 存储 | Storage Backend (etcd) | 执行 Create/Update/Delete 操作，返回结果 |
| 8. 响应 | Response Writer | 序列化结果，写入 HTTP 响应 |
性能要点： 认证和授权阶段通常通过缓存（如 RBAC 缓存、TokenReview 缓存）减少对 etcd 的重复查询；准入阶段是唯一可以修改请求对象的环节，也是实现动态策略注入的最佳位置。
2.1.2 请求处理流程 SVG 图
2.2 认证、授权与准入机制
API Server 的安全三层模型是 Kubernetes 多租户隔离和权限控制的基础。每一层都有独立的插件体系，管理员可以根据安全需求组合启用。
2.2.1 认证（Authentication）
认证层负责从 HTTP 请求中提取用户身份信息。API Server 支持多种认证方式，按配置顺序依次尝试，只要有一个认证器成功即通过。
| 认证方式 | 原理 | 典型场景 |
|---|---|---|
| X.509 客户端证书 | 验证 TLS 客户端证书的 CN/O 字段 | kubelet、kube-controller-manager 组件间通信 |
| Bearer | 从 Authorization Header 提取 | ServiceAccount 自动挂载的 JWT |
| Webhook TokenReview | 将 发送给外部认证服务验证 | 集成企业 OIDC/LDAP 认证 |
| Proxy 认证 | 信任反向代理设置的 Header（X-Remote-User） | API Gateway 前置认证 |
| 匿名请求 | 未通过任何认证器的请求标记为 Anonymous | 健康检查、只读公开端点 |
安全警告： 匿名请求默认被授权层拒绝（system:anonymous 用户没有权限）。生产环境应禁用匿名认证，或仅对 /healthz 等端点开放。
2.2.2 授权（Authorization）
授权层在认证之后执行，决定已认证用户是否有权执行特定操作。Kubernetes 支持四种授权模式，可以组合使用（按顺序评估，任一模式允许即通过）。
- Node 授权： 专门为 kubelet 设计的授权器，自动授权 kubelet 对其所在节点的 Pod 和 Volume 的读写操作。
- ABAC（基于属性的访问控制）： 使用 JSON 策略文件定义权限，策略变更需要重启 API Server，不推荐用于大规模集群。
- RBAC（基于角色的访问控制）： 通过 Role/ClusterRole 和 RoleBinding/ClusterRoleBinding 定义权限，是生产环境的标准选择。
- Webhook 授权： 将授权决策委托给外部 HTTP 服务，适用于自定义复杂的权限策略。
2.2.3 准入（Admission Control）
准入控制器在对象被持久化到 etcd 之前拦截请求，分为 Mutating（修改请求对象）和 Validating（验证请求对象）两类。Kubernetes 内置了 30+ 个准入控制器，管理员可以通过 --enable-admission-plugins 和 --disable-admission-plugins 控制启用列表。
| 准入控制器 | 类型 | 功能 |
|---|---|---|
| NamespaceLifecycle | Validating | 拒绝在正在删除的 Namespace 中创建对象 |
| MutatingAdmissionWebhook | Mutating | 调用外部 Webhook 修改请求对象（如注入 Sidecar） |
| ValidatingAdmissionWebhook | Validating | 调用外部 Webhook 验证请求对象（如策略检查） |
| PodSecurity | Validating | 根据 Pod Security Standards 检查 Pod 安全上下文 |
| ResourceQuota | Validating | 验证资源配额是否超限 |
| LimitRanger | Mutating | 为未设置资源限制的 Pod 设置默认值 |
2.2.4 安全三层模型 SVG 图
2.3 高可用部署模式
API Server 本身是无状态的，所有状态都存储在 etcd 中，因此高可用部署的核心是：多副本 API Server + 负载均衡 + 高可用 etcd 集群。生产环境通常部署 2~3 个 API Server 实例，前端通过负载均衡器分发流量。
2.3.1 标准高可用架构
| 组件 | 部署方式 | 高可用要点 |
|---|---|---|
| API Server | 多副本（通常 2~3 个实例） | 无状态，每个实例独立连接 etcd；通过 --advertise-address 暴露自身地址 |
| 负载均衡器 | L4 负载均衡（如 HAProxy、Nginx、云厂商 LB） | 健康检查端点 /livez 和 /readyz；TCP 6443 端口转发 |
| etcd 集群 | 3 或 5 节点集群 | Raft 共识算法保证强一致性；API Server 通过 --etcd-servers 指定所有 etcd 地址 |
| kubelet / 控制器 | 连接负载均衡器 VIP | 所有组件通过负载均衡器访问 API Server，避免单点故障 |
2.3.2 关键配置参数
# API Server 启动参数示例（高可用相关）
--apiserver-count=3 # 集群中 API Server 总数，用于选举和端点传播
--peer-advertise-ip=10.0.1.1 # 本实例对等通信地址
--etcd-servers=https://10.0.1.10:2379,https://10.0.1.11:2379,https://10.0.1.12: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
--enable-admission-plugins=NodeRestriction,PodSecurity,ResourceQuota
--authorization-mode=Node,RBAC
--client-ca-file=/etc/kubernetes/pki/ca.crt
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key2.3.3 高可用部署模式对比
| 模式 | 负载均衡方式 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| 外部 LB 模式 | 云厂商 LB / 硬件 LB | 云原生环境、大型集群 | 运维简单，自动健康检查 | 依赖外部 LB 可用性 |
| Keepalived + HAProxy | VIP + HAProxy | 自建机房、中小集群 | 完全自主控制 | 需要维护 VIP 切换逻辑 |
| BGP 动态路由 | BGP 宣告多个 API Server IP | 网络设备支持 BGP 的环境 | 流量自动负载均衡 | 网络配置复杂 |
| kube-vip | 基于 ARP/BGP 的虚拟 IP | Kubernetes 原生高可用 | 与集群深度集成 | 相对较新，生态成熟度待验证 |
生产建议： 推荐使用外部 LB 模式（云环境）或 Keepalived + HAProxy（自建环境）。API Server 实例数建议为奇数（3 个），与 etcd 节点数保持一致，避免脑裂风险。所有 API Server 实例必须使用相同的
--etcd-servers 列表连接到同一个 etcd 集群。
2.3.4 高可用架构 SVG 图
2.4 关键设计原则与避坑指南
核心原则： API Server 是控制面的流量入口，其可用性直接决定集群的管控能力。高可用设计应遵循“无状态水平扩展 + 有状态强一致”的分离原则。
- 避免单点 etcd： 永远不要将 API Server 连接到单节点 etcd。etcd 集群至少 3 节点，且部署在不同物理机/可用区。
- 负载均衡器健康检查： 使用
/readyz端点而非/healthz，因为/readyz会检查 API Server 与 etcd 的连接状态，避免流量路由到 etcd 连接异常的实例。 - 认证链顺序： 将性能最高的认证器（如客户端证书）放在最前面，减少延迟。Webhook 认证器应设置超时和熔断机制。
- 准入控制器性能： MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 会引入额外网络延迟，建议使用
failurePolicy: Fail确保安全，但需为 Webhook 服务部署高可用。 - 审计日志： 高可用部署时，审计日志应写入集中式存储（如 S3、Elasticsearch），避免每个 API Server 实例本地存储导致日志碎片化。
常见故障场景： 当 etcd 集群发生 Leader 选举时（约 200~300ms），API Server 的写请求会短暂失败。客户端（如 kube-controller-manager）应配置重试机制和指数退避，避免请求雪崩。建议在负载均衡器层面配置
retry-on-failure 策略。