1. 课程导论：为什么集群升级前需要容量水位检查？Kyverno 在其中的角色与价值
1.1 集群升级的“黑天鹅”风险
Kubernetes 集群升级是平台工程中最常见、也最具破坏性的操作之一。即使遵循官方滚动升级策略，升级过程中节点驱逐、Pod 重建、控制面组件重启等动作，都会对集群的瞬时容量产生巨大冲击。如果升级前没有对集群的容量水位进行精确评估，极易触发以下连锁故障：
- 节点资源过载：驱逐 Pod 后剩余节点无法承载全部工作负载，导致 CPU/内存压力飙升，引发 OOM Killer 或节点 NotReady。
- PVC 与本地存储溢出：有状态应用在节点间迁移时，本地临时存储或挂载卷容量不足，造成 Pod 启动失败。
- IP 地址池枯竭：CNI 插件分配的 Pod IP 或节点 IP 在升级过程中被大量占用，新 Pod 无法获取 IP 地址。
- 控制面组件过载：API Server、etcd 或调度器在升级期间承受额外请求，导致响应延迟或领导者选举超时。
⚠️ 常见误区：很多团队仅依赖 Prometheus 告警阈值（如节点 CPU > 80%）来判断升级条件，但告警阈值通常针对稳态运行设计，无法模拟升级过程中“节点逐台下线 + Pod 重新调度”的叠加效应。容量水位检查必须覆盖升级前、升级中、升级后三个阶段的资源约束。
1.2 容量水位检查的核心维度
一个完整的升级前容量水位检查，至少需要评估以下五个维度。下表列出了每个维度的检查对象、典型阈值及检查时机：
| 维度 | 检查对象 | 典型阈值（示例） | 检查时机 |
|---|---|---|---|
| 计算资源 | 节点 CPU / 内存可分配量 | 剩余可分配 CPU > 集群总 CPU 的 20% | 升级前 24h 内 |
| 存储资源 | 节点本地存储、PVC 剩余容量 | 节点根分区使用率 < 70% | 升级前 1h |
| 网络资源 | Pod CIDR 剩余 IP、NodePort 端口 | Pod IP 池剩余 > 集群 Pod 总数的 30% | 升级前 1h |
| 控制面健康 | etcd 存储大小、API Server 请求延迟 | etcd DB 大小 < 2GB | 持续监控 |
| 工作负载冗余 | PDB 配置、HPA 最小副本数 | 所有关键工作负载 PDB 允许至少 1 个副本离线 | 升级前 48h |
1.3 传统检查方式的痛点
在引入 Kyverno 之前，团队通常通过以下方式实现容量检查，但每种方式都存在明显短板：
- Shell 脚本 + kubectl：临时编写脚本采集节点状态，但脚本难以复用、缺乏版本控制，且无法在集群内统一执行。
- CI/CD 流水线预检：在 Jenkins/GitLab CI 中嵌入检查步骤，但流水线通常运行在集群外部，无法直接访问集群内部状态，且对策略变更不敏感。
- 手动检查清单：依赖运维人员逐项核对，效率低且容易遗漏，尤其在多集群环境中不可持续。
💡 核心矛盾：容量检查需要“在集群内部、在升级操作之前、以策略即代码的方式”自动执行。传统工具要么在集群外（CI），要么需要额外部署 Admission Webhook（开发成本高），而 Kyverno 正好填补了这一空白。
1.4 Kyverno 在容量水位检查中的角色与价值
Kyverno 是一个为 Kubernetes 设计的策略引擎，它作为 Dynamic Admission Controller 运行在集群内部，能够拦截资源变更请求并执行策略。在集群升级前容量水位检查场景中，Kyverno 扮演了以下三个关键角色：
- 策略定义者：通过
ClusterPolicy资源定义容量检查规则，例如“节点内存可分配量低于 20% 时拒绝升级操作”。 - 实时检查者：在升级操作（如节点排水、Pod 驱逐）发生前，Kyverno 通过
validate规则实时校验集群当前状态是否满足容量阈值。 - 自动化门禁：当容量水位不达标时，Kyverno 可以自动拒绝变更请求并返回详细失败原因，阻止升级操作继续执行。
下图展示了 Kyverno 在集群升级流程中的位置与交互关系：
1.5 Kyverno 策略即代码的独特价值
相比传统检查方式，Kyverno 在容量水位检查中提供了以下不可替代的价值：
| 价值维度 | 传统方式 | Kyverno 方式 |
|---|---|---|
| 部署位置 | 集群外部（CI/CD、脚本） | 集群内部，原生 Admission Controller |
| 策略表达 | Shell 逻辑、YAML 模板 | Kubernetes 原生资源（ClusterPolicy） |
| 实时性 | 定时触发或手动触发 | 实时拦截资源变更请求 |
| 可观测性 | 日志、告警 | PolicyReport + 事件 + Metrics |
| 版本管理 | Git 仓库管理脚本 | GitOps 原生支持，策略即代码 |
| 扩展性 | 需要开发自定义 Webhook | 无需编码，纯 YAML 定义规则 |
📌 关键认知：Kyverno 不是容量检查的“数据采集器”，而是“策略执行引擎”。数据采集仍然依赖 Kubernetes 原生 API（如
kubectl get nodes -o json），但 Kyverno 将这些数据与策略规则进行实时比对，并在升级操作发生前做出准入决策。这种“数据 + 策略”分离的架构，使得容量检查规则可以独立于数据源演进。
1.6 本课程的学习路径
在后续章节中，我们将从零开始构建一套完整的 Kyverno 容量水位检查策略体系：
- 第 2-5 章：Kyverno 基础与环境搭建，包括安装、策略语法、调试方法。
- 第 6-12 章：五大容量维度的策略实现（计算、存储、网络、控制面、工作负载冗余）。
- 第 13-18 章：高级策略模式，包括上下文变量、预聚合、外部数据源集成。
- 第 19-24 章：策略测试、CI/CD 集成、PolicyReport 与告警。
- 第 25-30 章：生产级最佳实践，包括多集群策略分发、性能调优、故障排查。
通过本课程，你将掌握如何用 Kyverno 将集群升级前的容量检查从“人工操作”转变为“自动门禁”，从根本上降低升级风险。