GKE删除Deployment后ReplicaSet未被删除问题求助

结合你在GKE v1.15.9-gke.24版本遇到的异常，核心问题出在Deployment资源的API组差异及版本兼容性上，下面拆解根源和对应的正规解决方法：

一、问题核心原因 #

1. API组版本冲突：在Kubernetes 1.15版本中，Deployment同时存在于apps/v1和extensions/v1beta1两个API组（1.16版本开始extensions组的Deployment被彻底废弃）。你创建的是deployment.apps（即apps/v1组资源），但删除时调用的是deployment.extensions——这会导致kubectl尝试删除extensions/v1beta1组的Deployment，而该资源实际不存在（你创建的是apps/v1的），因此无法触发关联ReplicaSet和Pod的级联删除，最终导致资源残留。

2. kubectl与集群版本不匹配：如果本地kubectl版本和GKE集群版本（v1.15.9）不一致，可能出现资源API组解析错误，比如高版本kubectl默认用apps/v1，低版本优先走extensions组，导致删除操作没命中目标资源。

3. OwnerReference异常：少数情况下，若Deployment创建ReplicaSet时未正确设置ownerReferences字段（Kubernetes级联删除的核心依赖），删除Deployment时不会触发RS的清理。你可以通过kubectl describe replicaset <你的RS名称>查看Owner References部分，确认是否指向对应的Deployment。

二、正规解决方案 #

1. 明确指定API组删除Deployment #

删除时直接指定apps/v1组资源，确保操作目标精准：

kubectl delete deployment.apps <你的Deployment名称>

或者完整指定API版本：

kubectl delete deployment.v1.apps/<你的Deployment名称>

这样能匹配你创建的deployment.apps资源，触发Kubernetes默认的级联删除逻辑，自动清理关联的ReplicaSet和Pod。

2. 强制指定级联删除策略 #

如果默认级联删除失效，可显式指定前台级联策略，确保按依赖顺序清理：

kubectl delete deployment.apps <你的Deployment名称> --cascade=foreground

注：Kubernetes默认级联策略是Background，但部分版本bug中可能出现异常，Foreground会更严格地执行依赖删除逻辑。

3. 对齐kubectl与集群版本 #

确保本地kubectl版本和GKE集群版本（v1.15.9）一致，避免版本差异导致的API解析问题。以Linux为例，安装对应版本kubectl的命令：

curl -LO "https://dl.k8s.io/release/v1.15.9/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

4. 排查OwnerReference（若上述方法无效） #

如果执行后RS仍残留，检查RS的ownerReferences：

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

如果没有指向对应的Deployment，说明创建Deployment时出现异常（比如用了错误的API版本），此时可手动清理：

kubectl delete replicaset <你的RS名称>
kubectl delete pod -l app=<你的应用标签>

同时建议重新创建Deployment时，确保配置文件的apiVersion设为apps/v1，避免再次出现OwnerReference异常。

三、关于“先设副本数为0再删除”的疑问 #

不需要先将副本数设为0——这是冗余操作。正常情况下，删除Deployment会自动触发级联删除，清理所有关联资源。只有极端异常场景（比如Kubernetes控制器故障）才需要临时手动清理，但这并非正规流程。

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