2. kube-apiserver 深度解析：API 聚合层、认证授权准入链、请求处理流程、资源配额管理

kube-apiserver 是 Kubernetes 控制面的核心网关，所有对集群状态的查询和变更操作都必须经过它。本章深入剖析其内部架构，包括 API 聚合层、认证/授权/准入控制链、完整的请求处理流程以及资源配额管理机制，帮助你在选型和性能验证中做出精准决策。

2.1 API 聚合层：扩展 API 的基石

API 聚合层（API Aggregation Layer）允许你将第三方或自定义的 API 服务无缝集成到 Kubernetes API 中，使其看起来像原生资源一样。它通过 APIService 对象进行注册。

2.1.1 API 聚合层架构

2.1.2 APIService 对象示例

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.custom.metrics.k8s.io
spec:
  group: custom.metrics.k8s.io
  version: v1beta1
  service:
    name: custom-metrics-server
    namespace: monitoring
  groupPriorityMinimum: 100
  versionPriority: 15
  insecureSkipTLSVerify: false
  caBundle: <base64-encoded-ca-cert>

2.2 认证、授权与准入控制链

每个 API 请求在到达资源存储（etcd）之前，必须依次通过认证、授权和准入控制三个阶段。这条链是集群安全的第一道防线。

2.2.1 三阶段处理流程

2.2.2 认证模块对比

2.2.3 授权模式选择

• RBAC（推荐）：基于角色访问控制，通过 Role/ClusterRole 和 RoleBinding/ClusterRoleBinding 实现细粒度权限。
• ABAC：基于属性的访问控制，策略文件静态配置，灵活性低，不推荐新集群使用。
• Webhook：将授权决策委托给外部服务，适合需要自定义策略引擎的场景。
• AlwaysDeny / AlwaysAllow：仅用于测试或特殊场景，生产环境禁止使用。

2.3 请求处理流程

一个完整的 API 请求从客户端发出到最终写入 etcd，经历多个内部阶段。理解这个流程对性能调优和故障排查至关重要。

2.3.1 请求处理阶段

1. HTTP 路由匹配：根据请求路径和 HTTP 方法匹配对应的资源处理器。
2. 认证：按配置顺序尝试所有认证模块，提取用户身份信息。
3. 授权：根据用户身份和请求资源进行权限检查。
4. 准入控制（Mutating）：修改请求对象的准入插件（如 MutatingAdmissionWebhook、DefaultStorageClass）。
5. 对象验证：对请求对象进行结构化和语义验证。
6. 准入控制（Validating）：验证请求对象的准入插件（如 ValidatingAdmissionWebhook、PodSecurity）。
7. 资源配额检查：检查请求是否超出命名空间或集群的资源配额。
8. 存储写入：将对象序列化后写入 etcd。
9. 响应返回：构造 HTTP 响应并返回给客户端。

2.3.2 请求处理时序图

2.4 资源配额管理

资源配额（ResourceQuota）用于限制命名空间级别的资源消耗总量，防止单个命名空间耗尽集群资源。kube-apiserver 在准入控制阶段执行配额检查。

2.4.1 配额类型

2.4.2 配额评估流程

1. 请求到达：创建或更新资源的请求进入准入控制阶段。
2. 配额匹配：根据请求的命名空间查找对应的 ResourceQuota 对象。
3. 资源计算：计算当前命名空间已使用的资源总量 + 请求的资源量。
4. 阈值比较：将计算结果与配额限制进行比较。
5. 决策：如果超出限制，拒绝请求并返回 403 Forbidden；否则允许继续。

2.4.3 配额示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"
    services: "10"
    persistentvolumeclaims: "20"
    requests.storage: "100Gi"

2.5 性能关键点总结

• API 聚合层：每个扩展 API 服务器都会增加代理延迟，建议将扩展服务部署在集群内并启用连接池。
• 认证链：Webhook 认证是主要延迟来源，优先使用本地认证方式（X.509、ServiceAccount ）。
• 准入 Webhook：Mutating 和 Validating Webhook 会串行执行，超时设置（默认 30s）和失败策略（Fail/Ignore）直接影响集群可用性。
• 配额检查：大量 ResourceQuota 对象或高频资源变更会触发频繁的 etcd 读取，建议使用 --watch-cache 和 --watch-cache-sizes 优化。
• 请求并发：kube-apiserver 默认最大并发请求数为 400（--max-requests-inflight），超出部分会排队，导致客户端超时。