Kubernetes中Deployment与StatefulSet滚动更新差异及无停机优化咨询

差异原因 #

1. 设计定位与Pod特性不同 #

• Deployment面向无状态应用：所有Pod完全等价，没有固定的网络标识、专属存储或启动顺序要求，Pod之间可随意替换。滚动更新时默认允许临时超额创建Pod（maxSurge默认25%，最少1个），因此副本数为1时，会先启动新Pod，待其就绪后再终止旧Pod，保证服务不中断。
• StatefulSet面向有状态应用：每个Pod拥有稳定的唯一标识（如固定名称xxx-0）、专属存储卷绑定，部分场景还依赖严格的启动/终止顺序。默认滚动更新策略中maxSurge=0（不允许超额创建）、maxUnavailable=1（允许最多1个Pod不可用），所以副本数为1时，必须先删除旧Pod释放标识和存储，才能创建新Pod，导致短暂停机。

2. 更新策略参数默认值差异 #

• Deployment默认参数：maxSurge=25%（至少1）、maxUnavailable=25%，天然支持单副本时的滚动无停机更新。
• StatefulSet默认参数：maxSurge=0、maxUnavailable=1，这是为了避免有状态应用出现多实例冲突（比如数据库主节点不能同时存在两个），但牺牲了单副本场景的无停机能力。

优化方案 #

1. 调整StatefulSet更新策略参数 #

修改StatefulSet的spec.updateStrategy.rollingUpdate配置，将maxSurge设为1，maxUnavailable设为0：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: your-statefulset
spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  # 其他配置...

这样单副本更新时，会先创建新Pod（临时副本数变为2），待新Pod就绪后再删除旧Pod。注意：需确保你的有状态应用支持同时运行两个实例（比如部分分布式数据库允许临时双实例，或缓存类应用无冲突），否则可能引发数据一致性问题。

2. 临时扩容副本数再更新 #

如果应用不支持双实例共存，可以先将副本数扩容至2：

kubectl scale statefulset your-statefulset --replicas=2

等第二个Pod完全就绪后执行更新，更新完成再缩回到1：

kubectl scale statefulset your-statefulset --replicas=1

此方法利用多副本保证更新过程中始终有可用Pod，适用于大多数有状态应用。

3. 蓝绿/金丝雀更新模式 #

对于对可用性要求极高的场景，可以部署一个新的StatefulSet实例（比如命名为your-statefulset-v2），通过Service逐步切换流量到新实例，确认正常后再删除旧StatefulSet。这种方式完全避免停机，但需要应用支持流量切换，且额外增加资源开销。

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