📚 课程目录第1章课程导论

1. 课程导论：节点滚动升级的挑战、Policy as Code 概念、差异化准入的价值

在 Kubernetes 集群生命周期管理中，节点滚动升级（Rolling Node Upgrade）是最常见但风险最高的操作之一。无论是内核补丁、kubelet 版本更新还是操作系统升级，都需要逐个替换节点上的 Pod，同时保证集群整体不降级。

实际操作中，运维团队往往面临以下三大痛点：

挑战维度	具体表现	典型后果
安全策略漂移	节点升级后，原有 PodSecurityPolicy / OPA / Kyverno 策略未随新节点环境重新校验	非预期特权容器、hostPath 挂载、hostNetwork 暴露
准入控制盲区	滚动升级期间，新 Pod 调度到新节点时，Admission Webhook 可能因节点标签/污点变化而跳过校验	不合规镜像、缺失资源限制的 Pod 上线
配置一致性断裂	节点升级后，kubelet 配置、CNI 插件版本、节点级安全基线（如 SELinux/AppArmor）与策略预期不符	Pod 启动失败、安全审计告警激增

  关键洞察： 传统“升级前检查 + 升级后修复”模式在节点滚动场景下存在时间窗口漏洞——新节点上的 Pod 可能在策略生效前就已获得运行时权限。

Policy as Code（策略即代码） 是将安全、合规、运维规则以声明式代码形式管理，并通过自动化引擎在 Kubernetes 资源生命周期中强制执行。其核心要素包括：

声明式策略定义：使用 Rego（OPA）、CEL（Kubernetes 原生）、YAML（Kyverno）等 DSL 描述“允许/拒绝”规则。
准入控制集成：通过 ValidatingAdmissionWebhook / MutatingAdmissionWebhook 在资源创建/更新时拦截校验。
持续审计：对已有资源进行周期性扫描，发现策略违反并生成报告。
版本化与 CI/CD：策略存储在 Git 仓库，通过 Pipeline 测试、部署、回滚。

以下对比展示了传统策略管理与 Policy as Code 的差异：

推荐实践： 在节点滚动升级场景中，建议将节点标签、内核版本、kubelet 参数等节点属性作为策略输入变量，实现“节点感知”的准入控制。

差异化准入（Differentiated Admission）是指在节点滚动升级过程中，根据节点状态（旧节点/新节点/正在排空节点）和升级阶段（排空前/排空后/重启后/重新调度），动态调整准入策略的严格程度与校验逻辑。

其核心价值体现在三个层面：

下图展示了节点滚动升级中差异化准入的典型工作流：

注意： 差异化准入并非“放宽安全”，而是“按需调整”。新节点上线初期应执行最严格的策略，待验证通过后再逐步收敛到基线策略。切勿在排空阶段完全关闭准入控制。

本课程将围绕以下主线展开：

通过本课程，你将掌握在节点滚动升级场景下，如何用 Policy as Code 实现“升级不停服、安全不降级、审计可追溯”的差异化准入方案。