2. K8s API Server 架构：组件、请求处理流程与认证授权准入机制

Kubernetes API Server（kube-apiserver）是整个控制面的核心组件，所有对集群状态的查询、变更操作都必须经过它。理解 API Server 的内部架构与请求处理流程，是构建可靠中间件错误处理逻辑的前提——因为事务边界、幂等性、重试策略都直接受制于 API Server 的认证、授权、准入与存储机制。

2.1 API Server 组件架构

API Server 采用分层设计，从网络层到存储层依次为：

2.2 请求处理全流程

一个典型的写请求（如 kubectl apply -f deployment.yaml）在 API Server 内部经历以下阶段：

1. TLS 握手与连接建立——客户端证书验证，双向 TLS 可选。
2. 认证——按顺序尝试所有认证插件，直到某个插件返回用户信息或全部失败。
3. 授权——根据用户、资源、动词（get/list/create/update/delete）进行权限判定。
4. 准入控制（Mutating）——先执行变更准入插件（如 PodNodeSelector、DefaultStorageClass）。
5. 对象验证与默认值填充——API Server 对资源对象进行 schema 校验并设置默认字段。
6. 准入控制（Validating）——执行校验准入插件（如 PodSecurity、ResourceQuota）。
7. 存储写入——将最终对象序列化为 protobuf 或 JSON，写入 etcd（带乐观锁）。
8. 响应返回——返回创建/更新后的对象给客户端，同时触发 watch 通知。

2.3 认证机制

API Server 支持多种认证方式，按配置顺序依次尝试：

2.4 授权机制

Kubernetes 默认使用 RBAC（Role-Based Access Control），授权决策基于：

• 用户 / 组 / ServiceAccount——认证阶段提取的身份
• 资源——如 pods、deployments、nodes
• 动词——get、list、create、update、patch、delete、watch
• 命名空间——集群作用域或命名空间作用域

授权链支持同时配置多个 Authorizer（如 RBAC + Webhook），按顺序执行，任一授权器返回 Allow 则通过，全部 Deny 则返回 403。

2.5 准入控制机制

准入控制是 API Server 请求处理中最关键的扩展点，也是中间件错误处理最容易出问题的环节。准入插件分为两类：

2.6 关键设计原则

• 无状态与水平扩展——API Server 实例之间不共享本地状态，所有状态在 etcd 中。这意味着中间件不能假设请求被同一实例处理。
• 乐观并发控制——etcd 写入依赖 resourceVersion，冲突时返回 409。中间件应实现重试逻辑，并注意指数退避。
• Watch 机制的一致性——API Server 保证 watch 事件的顺序与 etcd 写入顺序一致，但不保证客户端不丢失事件（断连重连后需重新 list + watch）。
• 准入 Webhook 的失败策略——failurePolicy 可设为 Fail（默认）或 Ignore。中间件应明确评估 Webhook 不可用时的集群行为。