1. 架构视角概述：从传统运维到策略即代码的演进

1.1 传统运维的困境：静态配置与人工干预

在云原生架构普及之前，资源配额管理主要依赖静态配置和人工操作。运维人员通过 SSH 登录服务器、修改配置文件、执行脚本，甚至手动调整云控制台的配额滑块。这种模式在规模较小时尚可维持，但随着微服务数量和集群规模的爆炸式增长，其弊端日益凸显：

• 配置漂移：手动修改导致环境间配置不一致，难以追溯变更历史。
• 响应滞后：配额调整需要审批流程和人工执行，无法应对突发流量。
• 审计困难：缺乏统一的策略版本管理，合规审计依赖人工回忆和日志翻查。
• 环境割裂：开发、测试、生产环境的配额策略各自为政，缺乏统一治理。

1.2 策略即代码的演进路径

策略即代码（Policy as Code, PaC）将基础设施策略从人工决策和静态配置中剥离，以声明式代码的形式进行版本管理、自动化执行和持续验证。其演进路径可分为三个阶段：

在云原生环境中，策略即代码的典型实现是准入控制器（Admission Controller）。当用户提交资源创建或更新请求时，策略引擎拦截请求，根据预定义的策略规则进行校验，通过则放行，拒绝则返回错误信息。整个过程无需人工介入，策略变更通过 Git 提交即可生效。

1.3 资源配额模型在云原生架构中的核心地位

资源配额模型是云原生多租户环境下的资源隔离与公平调度基石。在 Kubernetes 生态中，ResourceQuota 和 LimitRange 是原生资源配额对象，但它们仅提供基础的 CPU/内存限制。在复杂的企业级架构中，需要更精细的配额模型：

• 多维度配额：不仅限制 CPU/内存，还包括 GPU、存储卷、网络带宽、自定义资源（CRD）。
• 分层配额：支持集群级、命名空间级、应用级的分层配额继承与覆盖。
• 动态配额：根据业务优先级、时间窗口、集群负载动态调整配额上限。
• 配额审计：记录配额使用历史，支持容量规划和成本分摊。

下图展示了资源配额模型在云原生架构中的位置与交互关系：

1.4 从传统运维到策略即代码的架构对比

下表从架构视角对比传统运维与策略即代码模式在资源配额管理上的关键差异：

1.5 策略即代码的典型工作流

在云原生架构中，策略即代码与资源配额模型的结合遵循以下工作流：

1. 策略定义：开发或运维人员在 Git 仓库中编写策略代码（如 Rego 规则），定义资源配额的上限、默认值、继承关系。
2. 策略测试：通过单元测试和集成测试验证策略逻辑，确保配额规则符合预期。
3. 策略部署：通过 GitOps 流水线将策略同步到集群中的策略引擎（如 OPA Gatekeeper）。
4. 准入控制：当用户提交资源创建请求时，策略引擎拦截请求，根据配额模型进行校验。
5. 配额审计：策略引擎记录每次决策的输入、输出和上下文，供后续审计和容量规划使用。
6. 策略优化：根据监控数据和业务反馈，迭代更新策略代码，形成持续改进的闭环。

下图展示了策略即代码与资源配额模型结合的详细工作流：

1.6 本章小结

从传统运维到策略即代码的演进，本质上是资源治理从“人治”到“法治”的转变。资源配额模型作为云原生架构中的核心治理组件，通过策略即代码实现了：

• 可编程：配额规则以代码形式管理，支持版本控制、代码审查和自动化测试。
• 可审计：每次配额决策都有完整记录，满足合规和容量规划需求。
• 可扩展：支持自定义资源、动态配额和分层模型，适应复杂业务场景。
• 可协作：开发、运维、安全团队通过 Git 协作，共同维护资源治理策略。