StatefulSet 怎么更新
StatefulSet 默认采用逆序滚动更新：从序号最大的副本开始，逐个替换，并且必须等当前副本就绪后才继续下一个。这样有状态服务在更新期间不会同时失去多个实例。updateStrategy 里的 partition 可以把更新范围限制在序号不低于某个值的副本上，让改动先落到高序号实例上观察。
基本信息
| 两种策略 | RollingUpdate（默认）与 OnDelete |
|---|---|
| 更新顺序 | 序号从大到小逐个进行 |
| 灰度字段 | updateStrategy.rollingUpdate.partition |
| 推进条件 | 当前副本就绪后才处理下一个 |
| 失败行为 | 停在该序号不再推进，不会自动回滚 |
典型使用场景
- 数据库集群先把最后一个副本升级，验证兼容性后再滚动全量
- 需要人工确认窗口的服务用 OnDelete，手动删除副本才触发更新
- 镜像或配置改动影响面大，先在非主节点序号上试运行
- 配合就绪探针确保新版本真正可用，避免带病推进
- 回滚同样逆序执行，把影响控制在单个副本内
更新策略与灰度配置
更新策略与灰度配置
spec:
updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 2 # 只更新序号 >= 2 的 Pod操作与观察
操作与观察
kubectl patch sts/db -p '{"spec":{"updateStrategy":{"rollingUpdate":{"partition":2}}}}'
kubectl rollout status sts/db # 观察推进到哪个序号
kubectl get pods -l app=db -o custom-columns='POD:.metadata.name,IMAGE:.spec.containers[0].image'
kubectl rollout undo sts/db # 需要回滚时执行参数与表现
| 配置 | 含义 | 注意点 |
|---|---|---|
| RollingUpdate | 自动逆序滚动更新 | 逐个等待就绪，整体耗时较长 |
| partition: N | 只更新序号大于等于 N 的 Pod | 递减到 0 才算完成全量更新 |
| OnDelete | 不自动更新，删除 Pod 才重建 | 适合需要人工窗口的场景 |
| rollout status | 查看更新进度 | 卡住时先看该序号副本的就绪状态 |
灰度从高序号开始：先把分区设成比总副本数少一，只更新最后一个副本，验证通过后逐步下调分区值，直到设为零完成全量。
分区只约束控制器的自动更新，不会阻止你手动删除低序号 Pod。被删掉的实例会用新模板重建，灰度范围就被破坏了。