【Kubernetes】使用StatefulSet进行的资源调度，删除更新策略

K8s StatefulSet 删除更新策略（OnDelete）实战演示

在 Kubernetes 中，StatefulSet 作为管理有状态应用的核心控制器，其更新策略直接影响应用的稳定性和升级效率。本文将通过实战操作，详细讲解 OnDelete 这种更新策略的工作原理和使用场景，非常适合初学者理解和上手。

什么是 StatefulSet 更新策略？

StatefulSet 的更新策略用于定义当 StatefulSet 配置（如镜像版本、资源限制等）发生变化时，如何更新其管理的 Pod。Kubernetes 提供两种主要更新策略：

• RollingUpdate（滚动更新）：默认策略，会按顺序自动更新 Pod（从编号最大的开始），旧 Pod 终止后才创建新 Pod，保证服务连续性。
• OnDelete（删除触发更新）：手动触发策略，配置修改后不会自动更新 Pod，只有当用户手动删除 Pod 时，StatefulSet 才会创建新的 Pod 应用新配置。

---

实战准备：环境与初始状态

环境说明

• 已创建名为 web 的 StatefulSet，管理 5 个 Pod（web-0 到 web-4）
• 关联的 Headless Service 为 nginx（ClusterIP: None）
• 当前所有 Pod 使用的镜像为 nginx:1.7.9

初始状态验证

通过 kubectl get po,svc,sts 查看资源状态：

# 输出显示 5 个 web 开头的 Pod 均正常运行，StatefulSet 就绪状态为 5/5
NAME                   READY   STATUS    RESTARTS   AGE
pod/web-0              1/1     Running   0          4m27s
pod/web-1              1/1     Running   0          4m29s
pod/web-2              1/1     Running   0          4m31s
pod/web-3              1/1     Running   0          6m26s
pod/web-4              1/1     Running   0          6m28sNAME                  TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/nginx         ClusterIP   None         <none>        80/TCP    10mNAME                   READY   AGE
statefulset.apps/web   5/5     10m

通过 kubectl describe po <pod名称> 查看镜像版本（以 web-4 为例）：

# 关键信息：Containers.nginx.Image 为 nginx:1.7.9
Containers:nginx:Image:          nginx:1.7.9Image ID:       docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451

步骤1：修改 StatefulSet 更新策略为 OnDelete

首先通过 kubectl edit sts web 编辑 StatefulSet 配置，将更新策略修改为 OnDelete：

# 编辑时需修改的关键配置
spec:updateStrategy:type: OnDelete  # 将默认的 RollingUpdate 改为 OnDelete

修改后无需重启 Pod，配置会立即生效，但此时 Pod 仍使用旧镜像（nginx:1.7.9）——这正是 OnDelete 的特性：配置修改不触发自动更新。

---

步骤2：修改镜像版本并验证效果

在 kubectl edit sts web 中进一步修改容器镜像为 nginx:1.21：

spec:template:spec:containers:- name: nginximage: nginx:1.21  # 从 1.7.9 改为 1.21

修改后再次查看所有 Pod 状态，会发现 所有 Pod 仍正常运行且镜像未变化（因为 OnDelete 策略下，仅修改配置不会触发更新）。

---

步骤3：手动删除 Pod 触发更新

OnDelete 策略的核心逻辑是：只有手动删除 Pod 时，StatefulSet 才会创建新 Pod 并应用新配置。我们通过以下操作验证：

操作1：删除 web-4 并查看效果

kubectl delete po web-4  # 删除旧 Pod

等待几秒后，StatefulSet 会自动重建 web-4。通过 kubectl describe po web-4 查看新 Pod 信息：

# 关键变化：镜像已更新为 nginx:1.21
Containers:nginx:Image:          nginx:1.21Image ID:       docker-pullable://nginx@sha256:2bcabc23b45489fb0885d69a06ba1d648aeda973fae7bb981bafbb884165e514

---

操作2：批量验证选择性更新

继续删除 web-3 和 web-0，保留 web-1 和 web-2：

kubectl delete po web-3
kubectl delete po web-0

通过对比所有 Pod 的镜像版本，可得到如下结果：

Pod 名称	操作前镜像	操作后镜像	说明
web-0	1.7.9	1.21	被删除后重建，应用新镜像
web-1	1.7.9	1.7.9	未被删除，保持旧镜像
web-2	1.7.9	1.7.9	未被删除，保持旧镜像
web-3	1.7.9	1.21	被删除后重建，应用新镜像
web-4	1.7.9	1.21	被删除后重建，应用新镜像

---

关键结论：OnDelete 策略的特点与适用场景

通过上述实验，我们可以总结 OnDelete 策略的核心特性：

1. 手动控制更新时机：更新完全由用户决定，删除哪个 Pod 就更新哪个，灵活性高。
2. 支持灰度更新：可先更新部分 Pod（如先更 web-4、web-3 验证稳定性，再更新其他），降低风险。
3. 无自动干扰：配置修改后不会自动操作 Pod，适合对稳定性要求极高的场景（如数据库集群）。

适用场景

• 有状态应用的灰度升级（需验证新版本兼容性）
• 数据库等敏感服务（避免自动更新导致的数据不一致）
• 需要精确控制更新顺序的场景（如主从架构需先更从节点）

---

对比：OnDelete 与 RollingUpdate 的核心差异

特性	OnDelete	RollingUpdate（默认）
更新触发方式	手动删除 Pod 时触发	配置修改后自动触发
更新顺序	无强制顺序（用户手动控制）	从编号最大的 Pod 开始（倒序）
服务连续性	需手动保证（可保留旧 Pod 运行）	自动保证（旧 Pod 终止前不删新 Pod）
适用场景	灰度更新、敏感服务	常规滚动升级、无状态服务

总结

演示了 StatefulSet 的 OnDelete 更新策略

1. OnDelete 是“手动触发”型更新策略，配置修改不自动更新 Pod；
2. 需手动删除 Pod，StatefulSet 才会重建并应用新配置；
3. 适合灰度更新、敏感服务等需要精确控制的场景。

---