2. kube-apiserver 架构深度解析：组件内部模块与交互流程

kube-apiserver 是 Kubernetes 控制面的核心网关，所有对集群状态的读写操作都必须经过它。理解其内部模块的职责与交互顺序，是进行安全回滚验证的前提。本章将逐一拆解认证、授权、准入控制、API 路由与存储层五个核心模块，并展示请求的完整生命周期。

2.1 五层模块总览

kube-apiserver 采用“请求处理管道”架构，每个模块在管道中承担特定职责。下表总结了各模块的核心功能与常见实现：

2.2 请求处理管道：模块交互流程

一个典型的 API 请求会依次经过认证 → 授权 → 准入控制 → API 路由 → 存储层。下图展示了这一完整流程：

2.3 模块深度解析

2.3.1 认证 (Authentication)

认证模块是请求进入 apiserver 的第一道关卡。它从 HTTP 请求中提取身份信息，并验证其有效性。kube-apiserver 支持同时启用多种认证方式，按顺序尝试，直到有一个成功：

• X.509 客户端证书：通过 TLS 握手时提供的证书中的 CN 字段识别用户。
• Bearer ：从 Authorization: Bearer <> 头中提取，支持静态 文件、ServiceAccount 或 Webhook TokenReview。
• Webhook TokenReview：将 发送给外部认证服务，由外部服务返回用户信息。

2.3.2 授权 (Authorization)

认证通过后，授权模块根据用户身份和请求属性（操作、资源、命名空间）判断是否允许执行。授权策略按配置顺序评估，第一个匹配的规则决定允许或拒绝：

• RBAC (Role-Based Access Control)：最常用，通过 Role/ClusterRole 和 RoleBinding/ClusterRoleBinding 绑定权限。
• ABAC (Attribute-Based Access Control)：基于 JSON 策略文件，灵活性高但管理复杂。
• Webhook SubjectAccessReview：将授权决策委托给外部服务。

2.3.3 准入控制 (Admission Control)

准入控制是请求持久化前的最后一道防线，分为两个阶段：

1. Mutating Admission：修改请求内容（如注入默认值、Sidecar 容器）。
2. Validating Admission：校验请求合法性（如检查资源配额、Pod 安全策略）。

准入控制通过内置插件和动态 Webhook 实现。内置插件在 apiserver 启动时加载，Webhook 则通过 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源动态注册。

# 查看当前启用的准入插件
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook

2.3.4 API 路由 (API Routing)

API 路由模块负责将 HTTP 请求映射到对应的 REST 处理器。它根据请求的路径（如 /api/v1/pods）、HTTP 方法（GET、POST、PUT、DELETE）和资源版本（v1、v1beta1）进行匹配。路由树支持版本化 API 组，例如：

• /api/v1/：核心 API 组
• /apis/apps/v1/：命名 API 组
• /apis/rbac.authorization.k8s.io/v1/：RBAC API 组

2.3.5 存储层 (Storage Layer)

存储层是 apiserver 与 etcd 之间的桥梁。它负责将资源对象序列化为 JSON 或 Protobuf 格式，并通过 etcd 的 gRPC API 进行读写。存储层还维护了一个 Watch 缓存，用于高效处理客户端的长轮询请求。

2.4 模块交互的完整时序

下图以“创建 Pod”请求为例，展示各模块的详细交互时序：

2.5 回滚验证中的模块关注点

在回滚 kube-apiserver 时，每个模块都可能成为风险点。下表总结了各模块在回滚场景下的关键验证项：