📚 课程目录第3章 Cluster API (CAPI) 核心概念

3. Kubernetes 准入控制基础：准入控制器的工作原理、类型及安全角色

准入控制（Admission Control）是 Kubernetes API Server 请求处理链中的关键安全闸门。所有对集群资源的创建、更新、删除操作，在通过认证（Authentication）与授权（Authorization）之后、对象被持久化到 etcd 之前，都必须经过准入控制器的拦截与校验。理解准入控制器的工作原理、类型划分及其在集群安全中的角色，是掌握 CAPI 与准入控制协同优化集群容量的前提。

3.1 准入控制器的请求处理位置与生命周期

Kubernetes API Server 处理一个写请求（CREATE、UPDATE、DELETE）的完整链路如下：

HTTP 路由与解析：请求到达 API Server，路由到对应的 REST 处理器。
认证（Authentication）：验证请求发起者的身份（客户端证书、、用户名/密码等）。
授权（Authorization）：基于 RBAC、ABAC 或 Node 授权策略，判断请求者是否有权限执行该操作。
准入控制（Admission Control）：请求对象依次通过配置的准入控制器链。这是本文核心。
对象验证与持久化：通过准入控制后，对象被校验并写入 etcd。

  关键原则：准入控制器无法拦截 LIST、WATCH 和 GET 等只读请求。它只作用于变更类操作。

CAPI 关联：Cluster API 控制器在创建或更新集群、Machine、MachineDeployment 等资源时，发出的请求同样会经过 API Server 的准入控制链。这意味着我们可以利用准入控制器对 CAPI 资源进行策略校验和默认值注入。

3.2 准入控制器的两种类型：Mutating 与 Validating

准入控制器按功能分为两大类：变更（Mutating）与校验（Validating）。它们在执行顺序、能力边界和典型用途上存在本质区别。

对比维度	Mutating 准入控制器	Validating 准入控制器
执行顺序	先执行（在 Validating 之前）	后执行（在 Mutating 之后）
核心能力	可以修改（Patch）请求对象的内容	只能读取和校验，不能修改对象
典型用途	注入默认值、Sidecar、标签、注解；修正配置	校验资源配额、安全策略、合规性检查
失败行为	拒绝请求或允许通过（取决于实现）	拒绝不合规的请求
Webhook 类型	MutatingAdmissionWebhook	ValidatingAdmissionWebhook
是否可绕过	否，所有请求必经此链	否，所有请求必经此链

重要顺序约束：如果同一个资源同时被多个 Mutating 控制器修改，后执行的控制器可能覆盖前者的修改。因此，Kubernetes 允许通过 admission.k8s.io/v1 的 matchPolicy 和 reinvocationPolicy 控制重新调用行为，确保最终状态符合预期。

3.3 内置准入控制器与动态准入 Webhook

Kubernetes 提供了两种形式的准入控制器：内置（In-tree）控制器和动态准入 Webhook。

3.3.1 内置准入控制器

内置控制器是编译在 kube-apiserver 二进制中的代码，通过 --enable-admission-plugins 和 --disable-admission-plugins 参数启用或禁用。常见的内置控制器包括：

NamespaceLifecycle：确保在已删除的 Namespace 中不能创建新资源。
LimitRanger：为 Pod 设置默认资源请求/限制。
ResourceQuota：校验资源配额是否超限。
PodSecurity：实施 Pod 安全标准（基线/受限）。
NodeRestriction：限制 kubelet 只能修改自身节点和绑定的 Pod。

3.3.2 动态准入 Webhook

动态准入 Webhook 允许集群管理员通过配置 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源，将准入决策委托给外部 HTTP 服务。这使得准入策略可以独立于 API Server 进行扩展和更新。

  CAPI 最佳实践：在 CAPI 环境中，动态准入 Webhook 是实现集群容量策略的首选方式。例如，可以编写一个 ValidatingAdmissionWebhook，拒绝创建不符合节点池规格的 Machine 资源，或通过 MutatingAdmissionWebhook 自动为 Machine 添加容量标签。

3.4 准入控制在集群安全中的核心角色

准入控制是 Kubernetes 纵深防御体系中的关键一环，其安全角色体现在以下四个层面：

安全层面	准入控制器的具体作用	示例控制器
资源合规	确保所有创建的资源满足预定义的合规标准，如禁止特权容器、强制只读根文件系统	PodSecurity、自定义 ValidatingWebhook
配额与容量	防止资源滥用，限制 Namespace 级别的 CPU/内存总量，避免单个应用耗尽集群容量	ResourceQuota、LimitRanger
配置加固	自动注入安全相关的默认配置，如网络策略、Seccomp 配置、只读根文件系统	MutatingAdmissionWebhook（如 Istio Sidecar Injector）
操作审计	记录所有被准入控制器拒绝或修改的请求，为安全审计提供关键数据	Event 记录、审计日志集成

容量安全视角：在 CAPI 场景下，准入控制可以防止创建超出集群容量规划的 Machine 资源。例如，通过 ValidatingAdmissionWebhook 校验 Machine 的 spec.template.spec.resources 是否超过节点池剩余容量，从而在资源创建阶段就避免容量过载。

3.5 准入控制器的配置示例

以下是一个动态 ValidatingAdmissionWebhook 的配置示例，用于校验 CAPI Machine 资源的 spec.version 字段是否包含允许的 Kubernetes 版本前缀：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: capi-version-validator
webhooks:
- name: capi-version-validator.capi.course
  clientConfig:
    service:
      name: capi-admission-webhook
      namespace: capi-system
      path: /validate-machine-version
    caBundle: <base64-encoded-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["cluster.x-k8s.io"]
    apiVersions: ["v1beta1"]
    resources: ["machines"]
    scope: "Namespaced"
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 10
  failurePolicy: Fail
  matchPolicy: Equivalent
  objectSelector:
    matchLabels:
      app.kubernetes.io/managed-by: capi-controller-manager

  关键字段说明：
  failurePolicy: Fail：当 Webhook 不可用时，拒绝所有请求，确保安全策略不被绕过。
objectSelector：只对带有特定标签的 Machine 资源生效，避免影响集群中其他非 CAPI 资源。
timeoutSeconds: 10：设置合理的超时时间，避免 Webhook 响应过慢导致 API Server 延迟。

3.6 本章小结

准入控制器是 Kubernetes API Server 请求处理链中承上启下的关键组件。Mutating 控制器负责注入默认值和修正配置，Validating 控制器负责校验合规性和安全性。内置控制器提供基础安全能力，动态准入 Webhook 则赋予集群管理员极大的扩展灵活性。在 CAPI 与准入控制协同优化集群容量的实践中，合理设计 Mutating 和 Validating Webhook 是实现自动化容量管理、防止配置漂移和保障集群安全的基础。