K8s RollingUpdate超progressDeadlineSeconds时回滚机制说明

给定Deployment配置副本数为2，滚动更新策略为maxSurge: 1、maxUnavailable: 0，该策略强制要求滚动发布全程可用Pod数不低于期望值2，最多允许额外启动1个Pod做版本缓冲。针对描述的「new-pod-1启动成功、old-pod-1已被终止、new-pod-2部署失败」场景，集群表现分两个阶段：

未触发回滚时的稳定状态 #

当new-pod-2持续启动失败、超过progressDeadlineSeconds设定的阈值后，Deployment控制器会将本次滚动更新标记为失败，直接暂停发布流程：

• 不会继续创建新的新版本Pod去替换剩余的旧版本Pod
• 不会主动终止已经通过健康检查、正常运行的new-pod-1和old-pod-2
• 不会自动重建已经被终止的old-pod-1
  此时集群内稳定运行的可用Pod为old-pod-2、new-pod-1共2个，刚好满足副本数要求，新旧版本实例各占一半，发布流程卡在此处不会自动向前推进。

执行kubectl rollout undo回滚后的最终状态 #

回滚操作的本质是把Deployment的Pod模板切回上一个可用的历史版本（也就是旧版本配置），之后复用同一套滚动更新策略完成版本替换，maxUnavailable: 0的约束在回滚流程中同样生效，全程可用Pod数不会低于2：

1. 回滚触发后，控制器首先基于旧版本模板创建1个新的旧版本Pod——配置和之前被终止的old-pod-1完全一致，但Pod名称后缀是重新生成的，不会复用原来的old-pod-1名称
2. 等这个新建的旧版本Pod通过健康检查、进入就绪状态后，控制器会先清理持续启动失败的new-pod-2，再终止正常运行的new-pod-1
3. new-pod-1被终止后，控制器会补建第2个旧版本Pod，等该Pod就绪后回滚流程正式完成
   最终集群内会稳定运行2个完全匹配旧版本配置的Pod，和此前测试的「new-pod-1直接启动失败再回滚」的最终结果一致，仅Pod名称后缀和初始状态的old-pod-1、old-pod-2存在区别。

补充说明：只要不修改滚动更新策略，回滚流程永远遵循「先启动目标版本Pod、等就绪后再删除非目标版本Pod」的逻辑，不会出现先删除可用Pod导致业务容量不足的情况。

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