1. 课程导论：为什么需要资源配额自动校准？集群升级带来的资源变化挑战

Kubernetes 集群升级是运维中最常见也最具风险的操作之一。升级不仅涉及控制面组件版本变更，还会引发节点资源拓扑、调度器行为、默认资源预留策略的连锁变化。如果资源配额（ResourceQuota）仍沿用升级前的静态配置，轻则导致 Pod 调度失败、应用扩缩容受阻，重则引发集群级联故障。

本课程将系统讲解如何利用 Kyverno 策略引擎，在集群升级时自动校准资源配额，消除人工调整的滞后性与误操作风险。本节作为导论，先剖析升级带来的资源变化挑战，以及为什么静态配额无法应对这些变化。

1.1 集群升级引发的资源变化全景

Kubernetes 集群升级（如从 v1.24 升级到 v1.28）会在多个层面改变资源可用性与分配逻辑。下表总结了主要变化维度及其影响：

1.2 静态资源配额的三大缺陷

传统资源配额管理采用“配置即静态”模式——运维人员在集群初始化或应用上线时设定配额，之后仅在出现故障时被动调整。这种模式在集群升级场景下暴露出三个致命缺陷：

1. 滞后性：从升级完成到发现配额不足，中间存在数小时甚至数天的监控盲区。期间 Pod 创建失败、HPA 无法扩缩容，直接影响业务可用性。
2. 不精确：人工调整往往基于经验估算，而非实际资源消耗数据。例如升级后节点可分配 CPU 从 8 核降至 7.2 核，但运维人员可能仍按 8 核计算配额，导致超配风险。
3. 不可审计：静态配额变更缺乏版本记录与合规校验。升级后谁改了什么、为什么改、是否经过审批，这些信息通常散落在聊天记录或工单系统中，无法形成可追溯的策略基线。

1.3 自动校准的核心价值

资源配额自动校准通过策略引擎（如 Kyverno）监听集群升级事件，自动计算并调整配额值，实现三个核心目标：

• 实时响应：在升级完成后的第一个调度周期内完成配额校准，消除滞后窗口。
• 数据驱动：基于节点实际 Allocatable 资源、历史 Pod 资源使用百分位、升级前后资源变化率等指标，生成精确的配额建议。
• 策略即代码：校准规则以 Kyverno ClusterPolicy 形式管理，支持 GitOps 版本控制、合规审计与回滚。

1.4 为什么选择 Kyverno？

在众多策略引擎中，Kyverno 因其 Kubernetes 原生设计、无需学习新语言、支持 mutate/validate/generate 三种动作，成为资源配额自动校准的理想选择。下表对比了 Kyverno 与其他方案：