StatefulSet 使用 Parallel 滚动更新，minReadySeconds 没有等满

StatefulSet 配置了 podManagementPolicy: Parallel、RollingUpdate 和非零 minReadySeconds。滚动更新时，一个新 Pod 刚变为 Ready，控制器就继续更新下一实例，没有等满配置的稳定时间。旧版本中，这可能是 StatefulSet 的可用性判断遗漏，不能仅靠把秒数调得更大解决。

先确认实际更新策略和连续 Ready 时间，再核对控制器版本。本文讨论已经变为 Ready 后的等待不足；坏镜像始终无法就绪、回退模板仍卡住的情况，可看 StatefulSet 坏版本回退恢复。

看时间线，而不是只看最后一行 Ready

以下命令只读取版本与对象，名称需要替换：

kubectl version -o yaml
kubectl get statefulset web -n team-app -o yaml
kubectl get pod web-2 -n team-app -o yaml
kubectl get pod web-1 -n team-app -o yaml
kubectl describe statefulset web -n team-app

核对实际的 podManagementPolicy、updateStrategy.type、minReadySeconds 和滚动更新分区。不要只读本地待发布清单，也不要把 Deployment 的字段和行为套到 StatefulSet 上。

在受控测试或已有部署记录中，对齐新 Pod 的 Ready 状态转换时间、revision，以及下一实例开始终止的时间。minReadySeconds 要求连续处于 Ready；期间再次变为不就绪，会改变稳定时间判断。一次截屏显示 Ready，并不能说明之前已连续就绪足够久。

还要检查是否有 Operator、发布脚本或人工操作在直接删除 Pod。控制器等待没有满足，与外部操作自行推进，可以产生相似表象。测试时不要反复对生产 StatefulSet 发起 rollout restart 来猜原因。

修复进入 1.34.0，不能泛称全部旧补丁都相同

Kubernetes 1.33.0 的相关控制器路径仍使用不包含完整稳定时间的旧判断；1.34.0 已包含修复，将 minReadySeconds 纳入相应的不可用状态检查。修复覆盖常规滚动更新路径，也调整了并发更新相关的不可用计数。

具体平台可能回补修复，应核对准确补丁版本与平台发布说明，不能仅凭小版本号断言所有 1.33.x 都未修复。StatefulSet 由控制平面的控制器管理；只更新工作节点 kubelet，也不能证明控制器已采用新逻辑。

支持并发更新的配置会影响同一时间允许不可用的实例数。即使版本修复到位，也不意味着所有配置都会严格“一次只更新一个 Pod”。需要结合实际策略、分区及允许的不可用数量判断推进是否正确。

不把 Parallel 改成 OrderedReady 当作随手可用的补丁

更新前保存 StatefulSet、其管理来源和当前 revision，确认业务备份、允许中断的范围，以及有状态应用的副本恢复流程。优先通过平台支持的兼容升级路径使用包含修复的控制器版本。

podManagementPolicy 不是任意可原地修改的滚动更新参数。要改变管理策略，可能涉及工作负载重建、控制器接管和实例生命周期，不能用一条强制替换命令处理生产有状态服务。保留 PVC 和后端数据，并先验证存储、节点放置和应用的写入者约束。

minReadySeconds 本身也不代表数据复制完成、仲裁成立或缓存已预热。它只是以 Ready 为基础的持续时间条件；探针和业务恢复标准不完整时，等待秒数不能补齐这些保证。

在可接受的测试更新中验证推进

使用原来的模板管理入口，在隔离环境或已批准的维护流程中进行一次有明确回退的更新。记录每个实例的 revision、Ready 转换和后续更新时间，确认稳定条件参与了推进判断，同时业务请求、数据一致性与存储挂载正常。

若仍提前推进，保存实际控制器版本、完整策略、时间线和外部操作记录，再沿证据定位。若变成一直等待，则查看未就绪原因；镜像、探针和应用错误不会因控制器修复自动恢复。

回退要分别核对控制器版本和应用模板的兼容性。模板回退不撤销已经发生的数据写入或 Pod 终止，回到受影响的控制器版本也可能重新出现等待遗漏。不要通过删除 PVC 或强制终止所有实例来验证一个时间参数。