副本数为1时Rolling Update的maxUnavailable差异及无停机配置疑问

两种场景的差异分析 #

场景1（maxUnavailable: 0） #

当replicas=1、maxSurge=1、maxUnavailable=0时，滚动更新流程为：

• 先启动1个新Pod（此时集群同时运行旧Pod+新Pod，共2个，符合maxSurge=1的限制）
• 等待新Pod进入就绪状态后，再删除旧Pod
• 全程保证至少1个可用Pod，无服务中断

场景2（maxUnavailable: 1） #

当replicas=1、maxSurge=1、maxUnavailable=1时，Kubernetes允许更新过程中所有Pod不可用，实际流程通常是：

• 先删除旧Pod（此时可用Pod数为0，满足maxUnavailable=1的限制）
• 再启动新Pod并等待其就绪
• 该过程会出现短暂服务中断，因为旧Pod已删除但新Pod尚未就绪

虽然Kubernetes也可能选择先启新Pod再删旧Pod（和场景1流程一致），但由于maxUnavailable=1允许无可用Pod，调度器更倾向于先删后启以节省资源，所以大概率会出现停机。

无停机部署的条件说明 #

不是必须配置replicas≥2，分场景来看：

• 应用更新场景：当replicas=1时，只要设置maxUnavailable=0且maxSurge≥1，就能实现无停机更新——更新时会先启动新Pod，确认就绪后再删除旧Pod，全程有可用实例。
• 节点扩缩容/维护场景：如果replicas=1，当节点被驱逐或维护时，旧Pod会被删除，新Pod需要在其他节点重新调度启动，中间必然出现服务中断。这种情况下需要：
  • 配置replicas≥2
  • 配合PodDisruptionBudget（PDB），设置minAvailable=1或maxUnavailable=0，确保节点维护时至少有一个Pod保持可用

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