Kubernetes StatefulSet 在删除 Pod 时才触发更新(OnDelete
策略)
一、核心机制:OnDelete
更新策略
1. 定义
在 StatefulSet 的 updateStrategy
中设置为 OnDelete
时,只有手动删除 Pod 后,StatefulSet 才会创建新版本的 Pod。
spec:
updateStrategy:
type: OnDelete # 默认为 RollingUpdate
2. 特点
- 完全手动控制:更新不会自动触发,需显式删除 Pod。
- 适用场景:
- 需要严格确保每次更新经过人工验证(如生产环境的关键数据库)。
- 避免意外滚动更新导致服务中断。
二、工作流程
1. 更新触发条件
- 修改 StatefulSet 的 Pod 模板(如镜像版本、环境变量)。
- 必须手动删除 Pod,新创建的 Pod 才会使用新模板。
2. 操作步骤
-
修改 StatefulSet 配置(如更新镜像):
kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:v2"}]'
- 此时 不会自动更新任何 Pod。
-
选择性删除 Pod(触发更新):
kubectl delete pod web-1 # 删除后,新创建的 web-1 会使用新版本
- 可逐个删除 Pod 实现分阶段更新(类似金丝雀发布)。
三、与 RollingUpdate
的对比
特性 | OnDelete 策略 |
RollingUpdate 策略 |
---|---|---|
更新触发方式 | 必须手动删除 Pod | 自动按顺序更新 Pod |
控制粒度 | 完全手动控制 | 通过 partition 控制部分更新 |
适用场景 | 关键有状态服务(如数据库主节点) | 常规有状态服务(如从节点、消息队列) |
自动化程度 | 低(需人工干预) | 高(适合 CI/CD 流水线) |
四、典型使用场景
1. 数据库主节点升级
- 先删除从节点 Pod(
web-1
,web-2
)验证新版本,最后手动删除主节点(web-0
)。 - 确保主节点稳定性,避免自动更新导致故障。
2. 兼容性验证
- 新版本需要与旧版本共存时(如 Kafka Broker 升级),逐步删除 Pod 并观察集群状态。
五、操作示例
1. 部署 StatefulSet(OnDelete
策略)
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
updateStrategy:
type: OnDelete
replicas: 3
template:
spec:
containers:
- name: nginx
image: nginx:v1
2. 触发更新
# 1. 修改镜像版本(不触发更新)
kubectl patch sts web -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:v2"}]}}}}'
# 2. 手动删除 Pod web-1(新创建的 web-1 使用 nginx:v2)
kubectl delete pod web-1
# 3. 验证 web-1 状态
kubectl get pods -l app=web -w
[!CAUTION]
- 谨慎删除 Pod:
- 确保应用支持优雅终止(配置
terminationGracePeriodSeconds
)。- 避免同时删除多个 Pod(尤其是有主从关系的服务)。
- 存储卷保留:
- 删除 Pod 不会自动删除 PVC,需手动清理(除非配置了
persistentVolumeClaimRetentionPolicy
)。- 监控与回滚:
- 更新后监控业务指标,发现问题时快速回退到旧镜像版本。
评论需开启科学上网!