2. Kubernetes API Server 架构：核心组件、请求处理流程、认证授权审计链
Kubernetes API Server（kube-apiserver）是整个控制面的核心网关，所有对集群状态的查询与变更都必须经过它。对于多租户场景，API Server 的请求处理路径直接决定了限流与隔离策略的生效位置。本节深入剖析 API Server 的内部架构、请求生命周期以及认证、授权、准入、审计的完整链路。
2.1 核心组件与分层架构
API Server 采用分层设计，从上到下依次为：API 层（路由与版本协商）、访问控制层（认证→授权→准入）、业务逻辑层（资源校验与存储）、底层存储层（etcd 交互）。
| 层级 | 核心组件 | 职责 |
|---|---|---|
| API 层 | HTTP Router、API Group Manager、Codec | 请求路由、版本协商、序列化/反序列化 |
| 访问控制层 | Authentication、Authorization、Admission | 身份验证、权限校验、策略准入 |
| 业务逻辑层 | Resource Registry、Strategy、Validation | 资源校验、默认值注入、存储适配 |
| 存储层 | Storage Backend (etcd3)、Watch Cache | 数据持久化、监听通知、缓存 |
多租户视角： 访问控制层是租户隔离的第一道防线，而存储层的 Watch Cache 是限流与队列隔离的关键拦截点。
2.2 请求处理流程（完整生命周期）
一个典型的 API 请求从客户端到达 API Server 到最终写入 etcd，经历以下 8 个阶段：
- HTTP 接收与路由 — TLS 终止，根据 URL 路径匹配 API 版本与资源类型。
- 认证（Authentication） — 从请求头、证书、Bearer 中提取身份信息。
- 授权（Authorization） — 检查请求主体是否有权限执行该操作（RBAC/ABAC/Webhook）。
- 准入控制（Admission） — 通过 Mutating 与 Validating 准入插件链，修改或拒绝请求。
- 资源校验与默认值 — 调用对应资源的 Strategy 进行字段校验与默认值注入。
- 存储操作 — 将请求转换为 etcd 事务（Create/Update/Delete），写入持久化存储。
- 响应构建 — 序列化返回对象，包含最终状态与资源版本号。
- 审计日志 — 异步记录请求的完整元数据（阶段 2-7 均可触发审计事件）。
关键路径延迟： 准入控制链与存储操作是请求处理中最耗时的两个阶段，也是限流与队列隔离策略的主要作用点。
2.3 认证（Authentication）链
API Server 支持多种认证方式，按配置顺序依次尝试，直到某个模块成功提取身份或全部失败：
| 认证模块 | 凭证来源 | 典型场景 |
|---|---|---|
| X.509 客户端证书 | TLS 握手阶段 | kubelet、控制面组件 |
| Bearer | Authorization 请求头 | ServiceAccount、用户 |
| Webhook | 外部认证服务 | 企业 SSO 集成 |
| Anonymous | 无凭证 | 健康检查、只读匿名访问 |
多租户风险： 如果启用了 Anonymous 认证且未绑定 RBAC 限制，任何未认证请求都可能获得集群信息。生产环境必须禁用匿名访问或仅授予最小权限。
2.4 授权（Authorization）链
认证通过后，API Server 将请求主体（User/Group/ServiceAccount）与操作（Verb/Resource/Subresource）传递给授权模块链。Kubernetes 默认使用 RBAC 模式，也支持 ABAC 与 Webhook：
- RBAC（Role-Based Access Control） — 通过 Role/ClusterRole 与 RoleBinding/ClusterRoleBinding 定义权限。多租户场景下，每个租户对应一个 Namespace，通过 RoleBinding 将租户用户绑定到该 Namespace 的 Role。
- ABAC（Attribute-Based Access Control） — 基于 JSON 策略文件，灵活性低，不推荐用于多租户。
- Webhook — 将授权决策委托给外部服务，适合复杂的企业级策略。
最佳实践： 多租户集群应使用 RBAC + 外部 IDP（如 LDAP/OIDC）实现租户隔离。每个租户拥有独立的 Namespace 和 ServiceAccount，通过 RBAC 限制跨 Namespace 访问。
2.5 准入控制（Admission）链
准入控制是请求处理路径中最后一个可编程拦截点，分为两类：
| 类型 | 执行顺序 | 作用 | 多租户相关插件 |
|---|---|---|---|
| Mutating | 先执行 | 修改请求对象（注入默认值、Sidecar、标签） | NamespaceLifecycle、MutatingWebhook |
| Validating | 后执行 | 校验请求对象（资源配额、Pod 安全策略） | ResourceQuota、PodSecurity、ValidatingWebhook |
对于多租户场景，以下准入插件至关重要：
- NamespaceLifecycle — 防止在正在删除的 Namespace 中创建资源。
- ResourceQuota — 限制每个 Namespace 的资源使用量（CPU/内存/PVC 数量）。
- PodSecurity — 强制 Pod 安全标准（Privileged/Baseline/Restricted）。
- MutatingWebhook / ValidatingWebhook — 自定义准入逻辑，例如注入租户标识、校验租户配额。
2.6 审计（Audit）链
审计日志记录每个 API 请求的完整上下文，是安全审计与租户行为分析的基础。审计策略分为四个级别：
| 级别 | 记录内容 | 性能影响 | 推荐场景 |
|---|---|---|---|
| None | 不记录 | 无 | 健康检查、静态资源 |
| Metadata | 请求元数据（用户、资源、操作、状态码） | 低 | 常规审计 |
| Request | 元数据 + 请求体 | 中 | 敏感操作审计 |
| RequestResponse | 元数据 + 请求体 + 响应体 | 高 | 故障排查、安全取证 |
多租户审计建议： 为每个租户配置独立的审计策略，对租户管理员操作使用 Request 级别，对普通用户操作使用 Metadata 级别。审计日志应包含租户标识（Namespace 或自定义标签），便于后续检索与分析。
2.7 限流与队列隔离的切入点
基于上述架构，多租户限流与队列隔离可以在以下位置实施：
- HTTP 路由层 — 基于请求路径或 Header 进行速率限制（如 nginx ingress 的 limit-req）。
- 认证后/授权前 — 识别租户身份后，对每个租户的请求速率进行独立计数。
- 准入控制链 — 通过 MutatingWebhook 注入租户优先级标签，或通过 ValidatingWebhook 拒绝超出配额的请求。
- 存储层 Watch Cache — 为每个租户分配独立的 Watch 队列，防止一个租户的突发流量阻塞其他租户的监听通知。