1. 课程导论
1.1 传统资源配额管理的“七宗罪”
在云原生环境中，资源配额（Resource Quota）是保障多租户稳定性与公平性的第一道防线。然而，大多数团队仍在使用“手动配置 + 事后告警”的粗放模式，导致以下系统性痛点：
| 痛点 | 典型表现 | 后果 |
|---|---|---|
| 配置碎片化 | YAML 散落在不同仓库、不同 Namespace，缺乏统一视图 | 审计困难，违规配置难以追溯 |
| 变更不可控 | 运维人员直接编辑 ConfigMap 或通过 Dashboard 修改 | 无审批流，误操作导致生产故障 |
| 策略与实现耦合 | 配额逻辑硬编码在 Operator 或 Admission Webhook 中 | 升级困难，策略复用率为零 |
| 缺乏分层抽象 | 集群级、租户级、应用级配额混为一谈 | 资源争抢时无法精准限流 |
| 合规审计缺失 | 配额变更无版本记录，无法回答“谁在何时改了什么” | 无法通过 SOC2/ISO 27001 审计 |
| 反馈周期长 | 配额超限后仅靠 Prometheus 告警，开发者感知滞后 | 业务受损后才被动扩容 |
| 环境不一致 | 开发/测试/生产环境的配额规则各自维护 | “在我机器上能跑”现象蔓延 |
核心矛盾： 云原生基础设施的弹性与动态性，与传统“静态配置 + 人工干预”的配额管理模式之间存在根本性错配。
1.2 策略即代码（Policy as Code）的破局思路
策略即代码将配额规则从“静态文档”和“人工操作”中解放出来，转化为版本化、可测试、可自动执行的代码资产。其核心价值体现在三个维度：
- 声明式定义： 使用 DSL（如 Rego、CEL）描述“配额应该是什么”，而非“如何执行配额”。
- 自动化执行： 通过 Admission Controller、GitOps 流水线或策略引擎，在资源创建/更新时实时拦截与校验。
- 可观测与审计： 每次策略评估都产生结构化日志，支持全链路追溯与合规报告。
关键认知： 策略即代码不是简单的“把 YAML 放到 Git 里”，而是建立一套从策略定义 → 策略分发 → 策略评估 → 策略审计的完整生命周期管理体系。
1.3 架构视角的价值：从“点状解决”到“分层设计”
大多数团队在引入策略即代码时，容易陷入“工具导向”的误区——直接选用 OPA/Gatekeeper 或 Kyverno，却忽略了顶层架构设计。这导致策略库迅速膨胀、规则冲突、评估性能下降。
架构视角要求我们回答三个关键问题：
- 分层： 配额策略应该在哪几层定义？（集群层、租户层、应用层、运行时层）
- 抽象： 如何将业务需求（如“核心业务优先保障”）转化为可执行的策略规则？
- 治理： 策略的版本、发布、回滚、灰度机制如何与现有 CI/CD 体系融合？
下图展示了传统配额管理与策略即代码分层架构的本质区别：
1.4 本课程的核心交付
本课程将围绕“分层设计”这一架构主线，系统性地交付以下能力：
| 模块 | 核心内容 | 产出物 |
|---|---|---|
| 策略模型设计 | 四层配额抽象模型（集群/租户/应用/运行时） | 分层策略模板 + 属性映射表 |
| 策略引擎选型 | OPA/Gatekeeper vs Kyverno vs CEL 对比 | 选型决策矩阵 |
| 策略即代码流水线 | GitOps + CI 策略测试 + 灰度发布 | 可运行的 Pipeline 配置 |
| 合规与审计 | 策略变更追溯 + 违规事件聚合 | 审计 Dashboard 设计 |
| 生产化实践 | 性能优化、故障排查、多集群策略同步 | 运维手册 + 故障树 |
前置提醒： 本课程不讨论“如何安装 OPA/Gatekeeper”这类工具级操作，而是聚焦于架构决策与模型设计。工具只是策略即代码的载体，分层模型才是长期可演进的基石。
1.5 谁应该学习本章节？
- 云原生架构师： 需要设计多租户资源隔离体系，保障 SLA。
- 平台工程团队： 正在建设内部开发者平台（IDP），需要将配额策略作为平台能力之一。
- 安全与合规工程师： 负责云原生环境下的策略治理与审计。
- 高级 SRE： 希望从“被动救火”转向“主动策略防御”。