1. 课程导论：Kustomize插件与控制平面准入策略的概念、关系与联动价值
在云原生生态中，Kubernetes 的资源管理正从“静态 YAML 堆叠”向“策略驱动的动态编排”演进。本章作为课程开篇，将厘清 Kustomize 插件扩展与控制平面准入策略（Admission Policy）的核心概念、职责边界，并揭示两者联动的架构价值。
1.1 核心概念速览
| 概念 | 所属层级 | 核心职责 | 典型工具/机制 |
|---|---|---|---|
| Kustomize 插件扩展 | 客户端（Client-Side） | 在资源提交前，对 YAML 进行转换、验证、注入 | exec 插件、Go 插件、KRM 函数 |
| 控制平面准入策略 | 服务端（Server-Side） | 在资源持久化前，拦截请求并执行策略检查 | ValidatingAdmissionPolicy、OPA/Gatekeeper、Kyverno |
关键区分：Kustomize 插件在
kubectl apply 之前生效，属于“左移”的安全与合规实践；准入策略在 API Server 内部生效，属于“运行时”的强制门禁。
1.2 Kustomize 插件扩展：客户端资源管线的“瑞士军刀”
Kustomize 本身是一个纯 YAML 转换引擎，其插件机制允许用户注入自定义逻辑，在渲染阶段对资源清单进行深度操作。常见的插件类型包括：
- 转换插件（Transformer）： 修改资源字段，如统一添加标签、注入 Sidecar、调整镜像版本。
- 验证插件（Validator）： 检查资源是否符合组织规范，如禁止
latest镜像标签、强制设置资源限制。 - 生成插件（Generator）： 从外部数据源（如 Vault、ConfigMap）动态生成资源。
实战场景： 使用 Kustomize exec 插件调用
yq 工具，在部署前自动为所有 Deployment 注入 sidecar.istio.io/inject: "true" 注解，无需修改原始 YAML。
1.3 控制平面准入策略：集群安全的“最后一道防线”
准入策略在 API Server 的请求处理链中执行，位于认证、授权之后，资源持久化之前。Kubernetes 1.28+ 原生支持 ValidatingAdmissionPolicy（VAP），结合 CEL（Common Expression Language） 实现声明式策略。此外，第三方引擎如 OPA/Gatekeeper 和 Kyverno 提供了更丰富的策略模板。
| 策略引擎 | 策略语言 | 适用场景 |
|---|---|---|
| ValidatingAdmissionPolicy | CEL | 原生、轻量、无需额外组件 |
| OPA/Gatekeeper | Rego | 复杂逻辑、跨资源查询、审计 |
| Kyverno | YAML 规则 | Kubernetes 原生体验、策略生成与突变 |
1.4 两者关系：左移与门禁的互补闭环
Kustomize 插件与准入策略并非替代关系，而是构建了 “客户端预处理 + 服务端强制” 的双层治理模型。下图展示了资源从开发到运行的完整策略执行路径：
1.5 联动价值：从“被动防御”到“主动治理”
将 Kustomize 插件与准入策略联动，能够带来以下核心收益：
- 减少反馈循环： 80% 的常见错误在客户端被插件拦截，开发者无需等待 API Server 返回拒绝。
- 统一策略视图： 插件与准入策略共享同一套策略代码库（如 Rego 或 CEL），避免策略碎片化。
- 渐进式采纳： 团队可以先在 Kustomize 插件中启用“警告模式”，待策略成熟后再迁移到服务端强制模式。
- 审计与追溯： 插件在资源上留下转换注解（如
kustomize.toolkit.fluxcd.io/checksum），准入策略可据此判断资源是否经过合规预处理。
常见误区： 不要试图用 Kustomize 插件完全替代准入策略。插件运行在客户端环境，无法防御恶意用户直接调用 API 或绕过
kubectl 的请求。准入策略才是集群安全的最终保障。