1. 课程导论：节点滚动升级的挑战、Policy as Code 概念、窗口控制的价值
1.1 节点滚动升级的核心挑战
在 Kubernetes 集群运维中，节点滚动升级（Rolling Upgrade）是最常见的操作之一，用于更新节点操作系统、kubelet 版本或运行时组件。然而，这一过程并非简单的“逐台替换”，它面临多重风险与复杂性。
| 挑战维度 | 具体问题 | 典型后果 |
|---|---|---|
| 业务连续性 | Pod 驱逐导致服务容量下降，突发流量下可能触发级联故障 | SLO 违约、用户请求超时 |
| 节奏失控 | 升级速度过快，未给集群健康检查留出足够观察窗口 | 未检测到异常即继续下一节点，故障扩散 |
| 合规与审计 | 升级操作缺乏审批与时间窗口约束，无法满足变更管理要求 | 审计失败、安全策略违规 |
| 多团队协作 | 平台团队与业务团队对升级窗口的期望冲突，缺乏统一策略 | 沟通成本高、升级被频繁阻塞 |
关键洞察： 传统脚本或手动流程难以在“升级速度”与“安全窗口”之间建立可编程的、可审计的平衡。这正是 Policy as Code 介入的切入点。
1.2 Policy as Code 概念
Policy as Code（策略即代码）是将基础设施与工作负载的治理规则以声明式代码形式编写、版本化、测试并自动执行的方法论。在 Kubernetes 生态中，它通常通过准入控制器（Admission Controller）实现，在资源创建或更新时拦截请求并执行策略评估。
- 声明式规则： 策略使用 Rego、CEL 或 YAML DSL 编写，而非自然语言文档。
- 自动化执行： 策略在 API 请求路径中强制生效，无需人工审批环节。
- 可审计： 每次策略评估结果均可记录，满足合规追溯需求。
- 版本化： 策略代码与应用代码一同存储在 Git 仓库中，支持 CI/CD 流程。
推荐工具： 本课程将基于 Kyverno 作为 Policy as Code 引擎，因其原生支持 Kubernetes 资源类型、无需学习新语言，且内置节点滚动升级相关的策略模式。
1.3 窗口控制的价值
“窗口控制”是指在节点滚动升级过程中，通过策略定义可执行升级的时间段、速率、并发数以及健康检查等待时长，从而将升级行为约束在安全边界内。其核心价值体现在以下四个维度：
- 风险隔离： 将升级限制在业务低峰期（如凌晨 2:00-5:00），避免影响核心交易。
- 速率限制： 控制同时升级的节点数量（如 max=1），防止集群容量急剧下降。
- 健康门禁： 每升级一个节点后，强制等待至少 5 分钟并验证集群健康状态，再继续下一节点。
- 合规审计： 所有升级操作的时间戳、窗口匹配结果、策略评估日志均可追溯。
常见误区： 窗口控制不等于“减慢升级速度”。它的目标是建立可预测、可编程的升级节奏，在安全与效率之间取得平衡。没有窗口控制的升级，往往在出问题时才发现已经“升级过头”。
1.4 本课程学习路径
本课程将围绕“节点滚动升级的 Policy as Code 窗口控制”这一主题，从策略设计、Kyverno 实现、CI/CD 集成到生产运维，构建完整的知识体系：
| 模块 | 核心内容 | 实践产出 |
|---|---|---|
| 策略设计 | 窗口规则建模、时间表达式、并发控制逻辑 | Rego/CEL 策略原型 |
| Kyverno 实现 | ClusterPolicy 编写、准入测试、策略调试 | 可部署的 Kyverno 策略集 |
| CI/CD 集成 | GitOps 工作流、策略预检、自动化测试 | GitHub Actions + Kyverno CLI 流水线 |
| 生产运维 | 监控告警、策略热更新、审计日志 | 生产级窗口控制方案 |
前置要求： 建议具备 Kubernetes 基础操作经验（kubectl、节点管理）、了解 Kyverno 基本概念。本课程将提供完整的示例代码与测试环境配置。