滚动更新场景下Deployment与ReplicaSet的职责划分及副本调整确认

一、职责划分 #

• Deployment：是整个更新流程的「总指挥」，只负责定义应用的最终期望状态（包括镜像版本、总副本数、滚动更新规则等），不直接操作Pod。更新触发后，它会根据预设策略创建新ReplicaSet，同时全程监控新旧ReplicaSet的运行状态，确保更新过程严格遵循配置的规则（比如必须等新版本Pod就绪后再缩容旧Pod）。
• 旧ReplicaSet：更新前是旧版本Pod的「管家」，负责维持旧Pod的数量匹配原定期望值。更新启动后，它只执行Deployment下达的缩容指令，逐步减少自己管理的Pod数量，直到完成使命（要么旧Pod全被替换，要么按配置保留少量历史副本），本身不会参与更新策略的制定。
• 新ReplicaSet：由Deployment主动创建，作为新版本Pod的「管家」。更新过程中，它会根据Deployment的指令逐步扩容，确保新版本Pod的数量和健康状态符合要求，最终接管所有Pod的管理工作。

二、副本数调整的主体 #

没错，新旧ReplicaSet的期望副本数完全由Deployment负责逐步调整。

Deployment会依据你配置的滚动更新参数（比如maxSurge、maxUnavailable）来控制每一步的扩缩容节奏：

• maxSurge：定义更新期间最多可以超出总期望副本数的Pod比例/数量（比如设为25%，总副本数4的话，最多同时运行5个Pod）；
• maxUnavailable：定义更新期间最多允许处于不可用状态的Pod比例/数量（比如设为25%，总副本数4的话，最多允许1个Pod不可用）。

更新过程中，Deployment会按规则交替调整新旧ReplicaSet的副本数：比如先给新ReplicaSet加1个副本，等新Pod就绪后，再给旧ReplicaSet减1个副本；重复这个过程，直到旧ReplicaSet的副本数降到0（或配置的保留数），新ReplicaSet的副本数达到总期望数量。

内容的提问来源于stack exchange，提问作者Pieter