2. Kubernetes Deployment 基础回顾：Deployment、ReplicaSet、Pod 的关系与滚动更新机制
在深入镜像安全水位与容量巡检之前，必须彻底理解 Deployment、ReplicaSet、Pod 这三层控制结构的关系，以及滚动更新（Rolling Update）的核心流程。这是后续所有巡检策略和风险判断的基础。
2.1 三层控制模型：Deployment → ReplicaSet → Pod
Kubernetes 通过“声明式控制器”实现应用的生命周期管理。Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接控制 Pod 的副本数量与版本。
| 资源对象 | 职责 | 关键属性 |
|---|---|---|
| Deployment | 声明期望状态（副本数、镜像版本、更新策略）；驱动版本变更与回滚 | replicas、strategy.type、revisionHistoryLimit |
| ReplicaSet | 确保指定数量的 Pod 副本始终运行；每个版本对应一个 RS | replicas、selector.matchLabels、template |
| Pod | 运行容器实例；承载镜像、资源请求、安全上下文 | containers[].image、securityContext、resources |
巡检视角要点： 镜像安全水位检查的对象是 Pod 模板中的
image 字段；容量巡检的对象是 Pod 的 resources.requests 与 limits。Deployment 的更新会创建新的 ReplicaSet，因此巡检必须覆盖新旧两个 RS 中的 Pod。
2.2 滚动更新机制详解
滚动更新是 Deployment 的默认更新策略（strategy.type: RollingUpdate）。它通过逐步替换旧版本 Pod 来保证服务不中断。
2.2.1 核心参数
| 参数 | 默认值 | 含义 | 对巡检的影响 |
|---|---|---|---|
maxSurge |
25% | 更新期间允许超出期望副本数的最大 Pod 数量（值或百分比） | 可能导致集群资源瞬时超用，容量巡检需考虑峰值 |
maxUnavailable |
25% | 更新期间允许不可用 Pod 的最大数量 | 影响服务容错水位，安全巡检需确认旧 Pod 是否被过快销毁 |
2.2.2 滚动更新流程（以 4 副本、maxSurge=25%、maxUnavailable=25% 为例）
- 创建新 RS：Deployment 控制器根据新模板创建 ReplicaSet (v2)，初始副本数为 0。
- 扩容新 RS：允许超出期望副本数 25%（即 1 个 Pod），新 RS 扩容 1 个 Pod。
- 缩容旧 RS：允许不可用 Pod 为 25%（即 1 个 Pod），旧 RS 缩容 1 个 Pod。
- 逐步迭代：重复步骤 2-3，直到新 RS 达到期望副本数（4 个），旧 RS 缩容至 0。
- 保留旧 RS：旧 RS 保留（副本数为 0），用于回滚。
巡检提示： 在滚动更新过程中，集群中同时存在新旧两个版本的 Pod。镜像安全水位巡检必须同时扫描两个版本的镜像摘要；容量巡检必须考虑 maxSurge 带来的资源峰值。
2.3 回滚机制与版本历史
Deployment 每次更新都会生成一个新的 ReplicaSet 版本。通过 kubectl rollout undo 可以回滚到上一个或指定版本。
- 版本存储：旧 ReplicaSet 保留在集群中，受
revisionHistoryLimit（默认 10）限制。 - 回滚触发：回滚时，Deployment 将
.spec.template重置为历史版本，再次触发滚动更新。 - 巡检风险：回滚后镜像版本可能降级到旧版本，导致安全水位重新暴露。巡检系统应记录每次回滚事件并重新评估镜像安全。
2.4 关键巡检启示
安全水位巡检： 滚动更新期间新旧镜像并存，必须同时检查两个版本的镜像摘要、漏洞扫描结果与签名状态。回滚操作可能导致旧漏洞镜像重新上线，巡检系统应触发重新评估。
容量巡检： maxSurge 会导致瞬时资源占用超出期望值，容量巡检应使用
kubectl describe deployment 或 Metrics API 监控实际 Pod 数量峰值，并与节点剩余资源做对比。