1. 课程导论：为什么需要关注滚动更新中的镜像安全与容量？

Kubernetes Deployment 的滚动更新（Rolling Update）是生产环境中发布新版本应用的标准策略。它通过逐步替换旧 Pod 实例来保证服务不中断。然而，在实际运维中，许多团队只关注更新策略的配置（如 maxSurge、maxUnavailable），却忽视了镜像安全水位与集群容量这两个关键维度，导致更新过程成为安全漏洞的窗口期或集群资源耗尽的风险点。

1.1 为什么镜像安全水位是滚动更新的“隐形红线”？

滚动更新本质上是一个“镜像替换”过程。新镜像的安全水位直接决定了更新后的集群是否暴露于已知漏洞之下。以下是三个核心风险场景：

• 基础镜像漏洞蔓延： 开发团队使用过时的 node:14 或 python:3.8-slim 基础镜像，其中包含大量已知 CVE（如 Log4j、OpenSSL 高危漏洞）。滚动更新后，这些漏洞会瞬间扩散到整个集群。
• 镜像签名与完整性缺失： 未验证镜像签名或摘要（Digest），导致更新时可能拉取到被篡改的恶意镜像，造成供应链攻击。
• 合规水位不一致： 不同环境（开发/预发/生产）的镜像安全扫描策略不一致，导致生产环境滚动更新时，新镜像未通过安全准入检查而被拒绝调度，引发更新卡死。

1.2 为什么容量巡检是滚动更新的“资源护栏”？

滚动更新过程中，新旧 Pod 会短暂共存。如果集群容量规划不足或未考虑更新时的资源峰值，极易触发节点资源竞争、Pod 驱逐甚至级联故障。

1.3 课程目标与受众

本课程旨在帮助运维与安全团队建立一套可落地的 滚动更新镜像安全水位与容量巡检体系，从策略定义、工具链集成到自动化巡检，覆盖更新全生命周期。

课程目标

1. 掌握镜像安全水位的定义方法（CVE 阈值、签名验证、基础镜像策略）。
2. 学会在滚动更新前自动执行镜像安全扫描与准入检查。
3. 理解滚动更新过程中的容量模型（临时资源峰值、节点碎片、弹性伸缩）。
4. 能够搭建容量巡检指标与告警体系，在更新前发现资源瓶颈。
5. 通过实际案例，掌握更新失败时的回滚与应急处理流程。

目标受众

• Kubernetes 运维工程师： 负责集群日常管理与更新发布，需要避免更新引发的故障。
• DevOps 工程师： 设计 CI/CD 流水线，需要将安全与容量检查嵌入发布流程。
• 安全架构师： 制定容器镜像安全策略与合规基线，确保供应链安全。
• 平台工程师： 构建内部开发者平台（IDP），需要提供安全的滚动更新能力。

1.4 滚动更新安全与容量巡检全景图

下图展示了滚动更新过程中，镜像安全水位与容量巡检的协同工作流程：

1.5 课程章节速览