单Pod副本场景下如何避免Kubernetes集群服务中断？

PodDisruptionBudget（PDB）能否强制触发滚动更新？ #

答案是不能。PDB的核心作用是限制自愿中断操作（比如节点维护、kubectl drain）的Pod数量阈值，确保集群内可用Pod不低于设定值，但它没有创建新Pod的能力，更无法主动触发滚动更新流程。如果给单副本Deployment配置minAvailable: 1的PDB，执行kubectl drain时会直接被阻塞，直到手动删除旧Pod或调整PDB，不会自动启动新Pod。

单副本场景下的可行解决方案 #

1. Deployment滚动更新+PDB组合（最推荐） #

单副本也能适配滚动更新策略，只需调整参数即可实现无中断驱逐：

• 给Deployment配置滚动更新规则：

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0  # 强制要求始终保持1个可用Pod
      maxSurge: 1        # 允许临时额外启动1个Pod
  

• 同时配置对应的PDB：

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: your-app-pdb
  spec:
    minAvailable: 1
    selector:
      matchLabels:
        app: your-app
  

当执行kubectl drain时，PDB会阻止直接删除旧Pod，Kubernetes会先启动新Pod，等新Pod通过就绪检查后再删除旧Pod，实现无中断的驱逐流程。

2. StatefulSet适配有状态服务 #

如果是有状态服务（需要固定网络标识、持久化存储），StatefulSet天生支持有序的Pod创建/删除逻辑：

• 给单副本StatefulSet配置minAvailable:1的PDB；
• 需要驱逐节点时，手动触发滚动更新（比如给Pod模板添加临时注解）：

  kubectl patch statefulset your-statefulset -p '{"spec":{"template":{"metadata":{"annotations":{"force-update":"'$(date +%s)'"}}}}}'
  

Kubernetes会先启动新Pod，确认就绪后再删除旧Pod，避免服务中断。

3. 手动临时扩缩容（适合开发环境） #

开发环境可通过手动调整副本数实现无中断驱逐：

1. 驱逐前先扩容到2个副本：

   kubectl scale deployment your-deployment --replicas=2
   

2. 等新Pod就绪后执行kubectl drain；
3. 驱逐完成后缩回到1个副本：

   kubectl scale deployment your-deployment --replicas=1
   

操作简单但需要人工介入，适合不频繁的节点维护场景。

4. 延长终止宽限期（减少中断窗口） #

若不想调整更新策略，可通过延长终止宽限期降低中断时长：

• 给Pod设置terminationGracePeriodSeconds: 300（根据服务实际情况调整），让旧Pod在Terminating状态下仍能处理请求；
• 确保就绪探针、存活探针配置合理，保证新Pod快速进入就绪状态。
  这种方式无法完全避免中断，但能大幅缩短服务不可用的时间。

总结 #

单副本场景下，PDB本身无法触发滚动更新，但配合Deployment的滚动更新策略是最可靠的无中断方案。无状态服务优先选择Deployment+PDB组合，有状态服务适配StatefulSet，开发环境也可通过手动临时扩缩容实现需求。

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