1. 课程导论：什么是准入控制、为什么需要策略即代码、资源配额模型的核心价值
1.1 什么是准入控制（Admission Control）
在 Kubernetes 集群中，准入控制是 API Server 请求处理链路上的一个关键拦截阶段。它位于请求认证（Authentication）与授权（Authorization）之后，对象持久化（etcd 存储）之前。准入控制器（Admission Controller）是一段拦截并处理 API 请求的插件代码，能够对请求进行验证（Validating）或修改（Mutating）。
核心定位：准入控制是集群安全策略的最后一道程序化防线。一旦请求通过准入控制，将被持久化到 etcd 并生效。
准入控制器分为两类：
| 类型 | 执行顺序 | 行为 | 典型场景 |
|---|---|---|---|
| Mutating（变更） | 先执行 | 允许修改请求对象（如注入 Sidecar、设置默认值） | 自动注入 Istio Sidecar、设置资源默认 Limit |
| Validating（验证） | 后执行 | 仅验证请求对象是否符合策略，拒绝不合规请求 | 检查镜像来源、禁止特权容器、验证资源配额 |
Kubernetes 内置了数十个准入控制器（如 NamespaceLifecycle、ResourceQuota、PodSecurity），但内置控制器的策略逻辑是固定的，难以灵活扩展。这正是策略即代码（Policy as Code）的切入点。
1.2 为什么需要策略即代码（Policy as Code）
传统策略管理方式（如人工审核、静态配置文件、脚本检查）存在明显缺陷：
- 手动操作易出错：运维人员通过 SSH 或 Dashboard 手动配置策略，缺乏版本控制与审计。
- 策略分散难审计：安全基线、资源限制、合规要求散落在不同文档、脚本或人脑中。
- 变更周期长：修改策略需要提交工单、人工审批、手动部署，无法快速响应安全事件。
- 缺乏自动化测试：策略上线前无法模拟验证，容易引发生产故障。
策略即代码将策略声明为机器可读的代码文件（如 YAML、Rego、JSON），纳入 Git 版本管理，通过 CI/CD 管道自动测试与部署。其核心优势包括：
| 维度 | 传统策略管理 | 策略即代码 |
|---|---|---|
| 版本控制 | 无或依赖文档版本 | Git 全量历史追溯 |
| 自动化执行 | 手动触发或定时脚本 | 事件驱动（Admission Webhook） |
| 测试能力 | 难以模拟 | 单元测试 + 集成测试 |
| 审计合规 | 日志分散，追溯困难 | 策略即证据，可签名可验证 |
| 变更速度 | 天级 | 分钟级（PR 合并即生效） |
行业实践：Open Policy Agent（OPA）与 Kyverno 是 Kubernetes 生态中最主流的策略即代码引擎。OPA 使用 Rego 语言声明策略，Kyverno 使用 Kubernetes 原生 YAML 资源定义策略，两者均以 Admission Webhook 方式集成。
1.3 资源配额模型的核心价值
资源配额（Resource Quota）是 Kubernetes 内置的命名空间级资源管控机制，用于限制命名空间内所有 Pod 的 CPU、内存、存储等资源总量。然而，原生 ResourceQuota 存在以下局限：
- 静态配置：配额值在创建时固定，无法根据集群负载或业务优先级动态调整。
- 缺乏分层：无法定义“部门 → 项目 → 应用”的多级配额树。
- 无策略联动：无法与安全策略（如禁止特权容器）或合规策略（如镜像必须来自私有仓库）组合执行。
- 审计不足：配额变更无审批流，超配行为难以追溯。
本课程提出的基于准入控制的策略即代码资源配额模型，将资源配额从静态配置升级为动态、可编程、可审计的策略体系。其核心价值体现在：
- 动态配额分配：通过策略引擎实时计算可用配额，支持按优先级、按时间段、按业务标签动态调整。
- 多级配额树：支持组织层级（Org → Team → Project → App）的配额继承与覆盖。
- 策略组合执行：资源配额策略可与安全策略、合规策略在同一 Admission Webhook 中联合判定。
- 全链路审计：每次配额分配与变更均记录策略决策日志，支持合规追溯。
- 声明式 GitOps：配额策略以代码形式存储在 Git 仓库，通过 Pull Request 驱动变更，自动测试与部署。
注意：本课程不讨论原生 ResourceQuota 的简单用法，而是聚焦于如何通过策略即代码引擎（OPA/Kyverno）构建可编程、可测试、可审计的资源配额模型。你需要具备 Kubernetes 基础操作能力与 YAML 编写经验。