2. 核心概念解析：Deployment、ReplicaSet、Pod、版本漂移、滚动更新、回滚机制

在深入版本漂移容量规划之前，必须精确理解 Kubernetes 中与版本管理直接相关的核心对象与机制。这些概念构成了版本漂移发生的底层逻辑，也是后续容量测试方案设计的理论基础。

2.1 核心对象层级关系

Deployment、ReplicaSet、Pod 三者构成了 Kubernetes 无状态工作负载的经典三层抽象模型。每一层负责不同的职责，并通过标签选择器（Label Selector）和所有者引用（OwnerReference）建立严格的父子关系。

2.2 版本漂移（Version Drift）

版本漂移是指在集群升级过程中，由于 Deployment 的 Pod 模板（PodTemplate）被自动或手动修改，导致同一 Deployment 下同时运行多个不同版本的 Pod。这种现象在集群升级场景中尤为突出，是容量规划测试需要重点模拟和测量的核心风险点。

2.3 滚动更新（Rolling Update）机制

滚动更新是 Deployment 默认的更新策略，通过逐步替换旧版本 Pod 来实现零停机发布。理解滚动更新的参数配置是版本漂移容量测试的前提。

2.3.1 核心参数

2.3.2 滚动更新流程

1. 创建新 ReplicaSet： Deployment 控制器根据新的 Pod 模板创建新的 ReplicaSet，初始副本数为 0。
2. 逐步扩容新 RS： 按照 maxSurge 的限制，逐步增加新 ReplicaSet 的副本数。
3. 逐步缩容旧 RS： 同时按照 maxUnavailable 的限制，逐步减少旧 ReplicaSet 的副本数。
4. 健康检查验证： 新 Pod 通过就绪探针（Readiness Probe）后才被视为可用，继续下一批替换。
5. 完成更新： 旧 ReplicaSet 副本数降为 0，新 ReplicaSet 达到期望副本数。

2.4 回滚机制（Rollback Mechanism）

回滚是 Deployment 版本管理的安。当新版本出现故障时，可以快速恢复到之前的稳定版本。回滚操作本身也会引发版本漂移，是容量测试必须覆盖的场景。

2.4.1 回滚触发条件

• 手动回滚： 使用 kubectl rollout undo deployment/<name> 命令。
• 自动回滚： 配置 progressDeadlineSeconds 超时后自动触发。
• 健康检查失败： 新版本 Pod 持续无法通过就绪探针或存活探针。

2.4.2 回滚流程与版本漂移

2.5 版本漂移的容量规划核心公式

基于上述概念，可以推导出版本漂移期间的容量规划关键公式：

# 版本漂移期间最大 Pod 数
max_pods = desired_replicas × (1 + maxSurge)

# 版本漂移期间最小可用 Pod 数
min_available = desired_replicas × (1 - maxUnavailable)

# 混合版本资源消耗模型
total_resource = Σ(version_i_pods × resource_per_pod_i)

# 漂移窗口期
drift_window = (desired_replicas × maxSurge) / (rolling_update_speed_pods_per_second)

# 回滚场景最大版本数
max_versions_during_rollback = 3  # 旧版 + 新版 + 回滚目标版

2.6 概念关系总结

下表总结了本章核心概念在版本漂移容量规划中的角色定位：