有序还是并行
StatefulSet 默认使用 OrderedReady：按序创建副本（0、1、2 依次），前一个就绪后才创建下一个，缩容与删除则按相反顺序进行。把 podManagementPolicy 设为 Parallel 后，所有 Pod 同时创建与删除，不再等待前一个就绪。它只改变创建与删除的并发度，不改变 Pod 的网络标识与存储绑定：序号命名、稳定的 DNS 名与各自的卷始终不变。
基本信息
| 适用对象 | 各版本的 StatefulSet |
|---|---|
| 关键字段 | spec.podManagementPolicy |
| 取值 | OrderedReady（默认，按序）｜Parallel（并行） |
| 影响范围 | 创建与删除顺序，不改变 Pod 身份与存储绑定 |
| 观察方式 | kubectl get pods -w，看副本进入就绪状态的节奏 |
典型使用场景
- 有主从依赖的系统：需要主节点先就绪再拉起从节点，用默认顺序模式
- 无依赖的分布式组件：副本之间互不等待，用并行模式加快拉起
- 扩容提速：副本数多且启动慢的服务，评估是否可改为并行
- 故障恢复：单副本异常后快速重建，顺序模式下的等待是否符合预期
- 演练验证：观察两种策略在实际环境中的启动时间差异
配置对比
配置对比
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: db
spec:
serviceName: db-headless
replicas: 3
podManagementPolicy: Parallel # 默认是 OrderedReady
selector:
matchLabels:
app: db
template:
metadata:
labels:
app: db
spec:
containers:
- name: db
image: registry.example.com/db:8.0观察差异
观察差异
kubectl get pods -l app=db -w # 并行模式下几乎同时进入 Running
kubectl get sts db -o jsonpath='{.spec.podManagementPolicy}'
kubectl rollout status sts/db # 滚动更新仍按序进行
kubectl get pods -l app=db -o wide # 核对序号与所在节点两种策略对照
| 取值 | 行为 | 适用 |
|---|---|---|
| OrderedReady | 按序创建，前一个就绪再下一个 | 存在启动依赖的有状态系统 |
| Parallel | 所有副本同时创建与删除 | 副本之间无依赖、需要快速拉起 |
| 对身份的影响 | 两种策略下都按序号命名 | 身份与存储绑定不受策略影响 |
| 对更新的影响 | 滚动更新仍按序滚动 | 并行策略不等于并行更新 |
顺序启动是许多有状态系统的前提，例如先选主再挂从；改成并行前必须确认应用能处理多个副本同时初始化，否则容易触发选举冲突。
扩容耗时差异在副本数多时最明显：顺序模式下的总耗时随副本数累加，长启动时间的应用容易触发超时类告警。