资源卡在 Terminating 删不掉：一次 finalizer 失控让 600 多个 PVC 僵死 14 小时的排查与摘除实战

一、现象：批量下线 4 个命名空间，600 多个 PVC 集体僵死

先交代规模和现场。Kubernetes 1.28.9（containerd 1.7.4，120 台 worker，8C16G），业务侧用我们自研的存储 operator acme-storage 给每个 Pod 挂 PVC，全集群约 3000 个 PVC。

周五下午要下线 4 个业务命名空间，正常操作就是 kubectl delete namespace 然后等。结果 4 个命名空间全部卡在 Terminating，kubectl get ns 里那 4 个一直显示 Terminating，怎么删都删不掉。

拆开看，卡住的根子都在 PVC 上：4 个命名空间里加起来 612 个 PVC 全卡在 Terminating，kubectl delete pvc --grace-period=0 --force 也纹丝不动，命名空间删除请求就一直挂着。从 14:20 到第二天早上 04:10，僵了 14 小时，运维群里催了三轮。

二、根因：finalizer 没被摘，etcd 里的对象就永远不会被真正删除

K8s 的对象删除是两阶段的，很多人只记了前半段：

1. 你 delete 一个对象，apiserver 不是直接把它从 etcd 抹掉，而是先给它打上 metadata.deletionTimestamp，对象进入“待删除”状态；
2. 然后 etcd 里这条记录原样留着，直到 metadata.finalizers 数组变空，apiserver 才真正把它删掉。

也就是说：只要 finalizers 数组非空，对象就删不干净。这个数组里每一个条目，都意味着“有一个控制器承诺：在我做完清理工作之前，别删我”。

这次 acme-storage 在 PVC 上挂了一个自定义 finalizer acme.io/volume-provision，本意是 PVC 删除前先把底层云盘做快照、解除挂载、做一致性处理。问题出在 operator 的 reconcile 里一段云盘 API 调用：下线那批 PVC 对应的云盘，有一批已经因为之前的故障被运维在控制台手动删掉了，operator 调 DescribeDisks 持续拿到 InvalidVolume.NotFound，reconcile 直接 panic，没有走到摘 finalizer 那一步。

结果就是：deletionTimestamp 已经打上了，但 acme.io/volume-provision 这个 finalizer 永远没人摘——对象就僵在那儿，删不掉、也活不了。

三、具体做法：先确认是谁挂的 finalizer，再决定摘不摘

第一步：把 finalizer 列表打出来，看清是谁。

kubectl get pvc data-pod-7f2c -n biz-a -o jsonpath='{.metadata.finalizers}'
# [ "kubernetes.io/pvc-protection"   "acme.io/volume-provision" ]

这里有两个 finalizer，含义完全不同：

• kubernetes.io/pvc-protection 是系统自带的保护型 finalizer，只要还有 Pod 在用这个 PVC，它就会一直在——这种不能盲摘，先 kubectl get pod -A -o wide | grep <pvc> 把用它的 Pod 干掉；
• acme.io/volume-provision 是我们自己挂的，摘不摘取决于底层清理是否真的完成了。

第二步：确认底层资源状态，再摘自定义 finalizer。

摘之前必须确认：对应云盘是不是已经在控制台 / 其它渠道被清理掉了。这次恰好是云盘已不存在（NotFound），operator 自己也清理不了，摘 finalizer 是安全的。

# 摘除单个 PVC 上的自定义 finalizer（merge 会覆盖整个数组）
kubectl patch pvc data-pod-7f2c -n biz-a --type=merge \
  -p '{"metadata":{"finalizers":["kubernetes.io/pvc-protection"]}}'

注意：patch 是“覆盖整个数组”，所以这里把要保留的 pvc-protection 显式列出来，把 acme.io/volume-provision 去掉。如果用 null 会把系统 finalizer 也一起干掉，那是另一类事故。

第三步：批量处理 612 个。

kubectl get pvc -A \
  --field-selector='metadata.deletionTimestamp!=null' \
  -o custom-columns=NS=.metadata.namespace,NAME=.metadata.name \
| awk 'NR>1{print $1"/"$2}' \
| while read ref; do
    ns=${ref%%/*}; name=${ref##*/}
    kubectl patch pvc "$name" -n "$ns" --type=merge \
      -p '{"metadata":{"finalizers":["kubernetes.io/pvc-protection"]}}'
  done

612 个 PVC，脚本跑了 3m12s 全部摘除；命名空间随后自动走完删除流程，4 个 Terminating 的 ns 在 20 秒内全部消失。

四、踩过的坑（都是反直觉的）

1. --force --grace-period=0 删不掉带 finalizer 的对象。 这是最普遍的误解。--force 只是让 apiserver 跳过服务端的 grace period，完全不碰 finalizer。只要 finalizers 数组非空，force 就是空话。
2. finalizers: null 是双刃剑。 它会把系统保护型 finalizer 一起干掉。对 pvc-protection 这种，摘了之后如果还有 Pod 在用，底层存储会在被使用中被释放——这是数据丢失级事故。摘除前必须确认底层资源状态。
3. 命名空间卡在 Terminating，finalizer 往往不在 ns 上，而在里面的资源上。 先 kubectl get all -n <ns> 找到卡住的子资源，逐个处理，最后 ns 自己就走了。
4. 给自研 operator 的 reconcile 加超时和重试是必修课。 这次根因是 reconcile 里对 NotFound 直接 panic。正确做法是：识别“底层资源已不存在”这种终态，主动摘除自己的 finalizer，而不是卡死。

五、结论与可复用清单

• 删不掉，先打 finalizers：kubectl get <obj> -o jsonpath='{.metadata.finalizers}'，看清是谁挂的、是保护型还是自定义；
• 区分两类 finalizer：保护型（pvc-protection、serviceaccount 的 kubernetes.io/bootstrapping）先解除保护条件再删；自定义型先确认底层清理完成再摘；
• 摘除用 --type=merge 显式列保留项，别用 null 一把清；
• 给自研控制器加 finalizer 泄漏告警：对 deletionTimestamp != null 且存活 > 5 分钟的对象建 Prometheus 告警，别让 14 小时变成 14 小时才被发现；
• reconcile 里对“底层资源已不存在”做幂等处理，识别终态后主动摘自己的 finalizer，而不是无限重试或 panic。

一句话：finalizer 是 K8s 给控制器的“清理承诺”，承诺没兑现，对象就删不掉——删不掉的本质，几乎从来不是 K8s 的问题，而是某个控制器的 reconcile 卡住了。