1. 课程导论：为什么在容量规划中需要策略引擎协同？Kyverno 与 OPA 的定位差异
1.1 容量规划面临的新挑战：策略不再是“静态配置”
在传统 IT 容量规划中，资源配额、Pod 副本数、节点预留等策略通常以静态 YAML 或硬编码阈值的形式存在。然而，云原生环境的动态性（自动扩缩、混部调度、突发流量）使得静态策略极易失效：
- 策略与资源生命周期脱节：Pod 创建时未校验资源声明，导致过载或浪费。
- 多集群策略碎片化：不同团队使用不同工具（OPA、Kyverno、自定义 Webhook），策略难以统一审计。
- 容量变更缺乏准入控制：任意调整 LimitRange 或 ResourceQuota 可能引发级联故障。
因此，策略引擎协同成为容量规划从“静态配置”走向“动态治理”的关键基础设施。
1.2 Kyverno 与 OPA 的核心定位差异
Kyverno 和 OPA（Open Policy Agent）虽然都用于 Kubernetes 策略执行，但在设计哲学、策略定义方式、与 Kubernetes 原生的耦合度上存在本质区别。下表从容量规划视角进行对比：
| 对比维度 | Kyverno | OPA (Gatekeeper) |
|---|---|---|
| 策略定义语言 | Kubernetes 原生 YAML（无需学习新语言） | Rego 声明式查询语言 |
| 与 K8s API 耦合度 | 高：直接使用 K8s 资源字段、标签、注解 | 中：通过 AdmissionReview 接口交互，需自定义数据注入 |
| 策略触发时机 | Mutating / Validating Webhook + 后台扫描（背景模式） | Validating Webhook 为主（默认不提供变更能力） |
| 容量场景适用性 | 资源声明校验、LimitRange 自动注入、ResourceQuota 合规检查 | 复杂跨资源约束（如：总 CPU 请求不超过集群剩余容量） |
| 策略分发与版本管理 | 原生 CRD（ClusterPolicy / Policy），支持 GitOps 原生集成 | ConstraintTemplate + Constraint，需额外管理模板版本 |
| 性能开销（准入阶段） | 较低：内置缓存，规则匹配快 | 中等：Rego 查询复杂度影响延迟，需注意缓存策略 |
容量规划关键结论：Kyverno 更适合“策略即配置”的轻量级资源治理（如自动注入资源请求/限制），OPA 更适合“策略即逻辑”的复杂容量约束（如跨 Namespace 资源总和限制、基于实时集群负载的动态准入）。
1.3 为什么需要协同？—— 容量规划中的“策略分层”模型
单一策略引擎无法覆盖容量规划的全部需求。实际生产环境需要将策略按职责分层：
- 基础合规层（Kyverno 主导）：确保每个 Pod 都声明了资源请求/限制，禁止特权容器，强制设置 Pod 反亲和性。
- 容量约束层（OPA 主导）：校验 Namespace 总 CPU 请求是否超过集群预留容量，拒绝突发性大规模扩容请求。
- 动态优化层（协同）：Kyverno 注入资源推荐值，OPA 校验推荐值是否在安全阈值内，形成闭环。
这种分层模型避免了“用 Rego 写简单校验”或“用 Kyverno 写复杂聚合”的错配，同时降低了策略维护成本。
1.4 协同架构总览
下图展示了 Kyverno 与 OPA 在容量规划中的协同工作流：
实践建议：在容量规划初期，优先用 Kyverno 覆盖 80% 的“资源声明合规”场景，再逐步引入 OPA 处理 20% 的“复杂容量约束”。这种 80/20 策略能快速见效，同时避免 Rego 学习曲线拖慢项目进度。
1.5 课程学习路径
本课程将围绕以下主线展开：
- 第 2-5 章：Kyverno 容量规则深度实践（资源注入、LimitRange 管理、ResourceQuota 审计）。
- 第 6-9 章：OPA 容量约束建模（Rego 聚合查询、集群容量预测、动态阈值）。
- 第 10-12 章：协同策略编排与冲突仲裁（优先级、故障隔离、灰度发布）。
- 第 13-15 章：容量规划可观测性与策略性能调优。
通过本课程，你将掌握如何利用 Kyverno 的“原生简洁”与 OPA 的“逻辑强大”，构建一套可扩展、可审计、高性能的容量策略体系。