使用--cascade=false删除Kubernetes StatefulSet仍删除Pod问题排查

你的思路是对的——通过删除StatefulSet但保留Pod来绕过Helm升级的冲突，但--cascade=false的使用可能因为Kubernetes版本的变化导致不符合预期，下面一步步帮你排查：

1. 先确认Kubernetes版本与参数兼容性 #

从Kubernetes 1.21版本开始，kubectl delete的--cascade参数已经被废弃，参数取值也从true/false改为了background（默认）、foreground、orphan。如果你用的是1.21+版本，原来的--cascade=false需要替换为--cascade=orphan才能实现“删除StatefulSet但保留Pod”的效果。

先执行命令确认版本：

kubectl version --short

如果服务器版本≥1.21，建议重新执行删除命令：

kubectl delete statefulsets/trendy-grasshopper-sts --cascade=orphan

2. 检查Pod的终止原因 #

即使参数正确，Pod仍被终止的话，得看Pod的事件日志定位触发源：

kubectl describe pod <你的Pod名称>

重点看Events部分：

• 如果看到Deletion triggered by StatefulSet/trendy-grasshopper-sts，说明参数没生效，StatefulSet删除还是触发了Pod删除；
• 如果看到其他控制器（比如另一个Helm Release、自定义控制器）的删除事件，就要排查是否有其他组件在管理这些Pod。

3. 验证Pod与StatefulSet的关联状态 #

删除StatefulSet后，立即查看Pod的ownerReferences字段，确认它是否已经和原StatefulSet解除关联：

kubectl get pod <你的Pod名称> -o jsonpath='{.metadata.ownerReferences}'

如果输出为空，说明Pod已经变成无主对象，理论上不会被自动删除；如果输出里还包含原StatefulSet的信息，说明--cascade=orphan参数没生效，大概率是kubectl客户端版本和服务器版本不匹配导致的。

4. 排查是否有其他关联资源影响 #

• PodDisruptionBudget（PDB）：虽然PDB不会主动删除Pod，但如果升级过程中触发了驱逐，可能会被误判为删除，这种情况会有对应的事件日志；
• Helm钩子：你的Helm Chart里是否包含删除Pod的钩子？可以查看Chart的templates目录下是否有pre-upgrade或upgrade阶段的钩子资源；
• Kubernetes Admission控制器：如果集群里有自定义的Admission Webhook，可能会拦截并删除无主Pod，这种情况需要联系集群管理员排查。

临时替代方案 #

如果上述排查后还是无法解决，可以先给Pod打临时标签，修改StatefulSet的selector使其不匹配现有Pod，这样Helm升级时就不会影响到这些Pod，之后再调整配置：

# 给Pod打标签
kubectl label pod <你的Pod名称> keep-me=true
# 修改StatefulSet的selector，使其不匹配现有Pod
kubectl patch statefulsets/trendy-grasshopper-sts -p '{"spec":{"selector":{"matchLabels":{"keep-me":"false"}}}}'
# 执行Helm升级
helm upgrade <你的release名称> <chart路径>
# 升级完成后，再调整StatefulSet的selector并迁移Pod

内容的提问来源于stack exchange，提问作者Jacxel