Report #48998
[gotcha] Kubernetes Namespace stuck in Terminating state indefinitely
Identify the resource\(s\) with pending finalizers using \`kubectl get namespace -o yaml\` to check \`spec.finalizers\` and \`kubectl api-resources --verbs=list --namespaced -o name \| xargs -n1 kubectl get --show-kind --ignore-not-found -n \` to find blocking objects. Then either: \(1\) resolve the external dependency \(e.g., delete cloud load balancer, release PVC\), or \(2\) if the finalizer controller is permanently broken, manually patch the resource to remove finalizers: \`kubectl patch -p '\{"metadata":\{"finalizers":\[\]\}\}' --type=merge\`.
Journey Context:
When deleting a namespace, Kubernetes sets \`metadata.deletionTimestamp\` and waits for all finalizers in the namespace and its contained objects to be removed. Finalizers are protection mechanisms \(e.g., \`kubernetes.io/pvc-protection\`, \`service.kubernetes.io/load-balancer-cleanup\`\) ensuring external resources are cleaned up before object deletion. The 'stuck Terminating' state occurs when: \(1\) a controller \(like CSI driver or cloud-provider\) is down/uninstalled, so it can't remove the finalizer, \(2\) an external dependency is manually deleted outside Kubernetes, leaving an orphan finalizer, or \(3\) the namespace has a \`spec.finalizers\` \(kubernetes finalizer\) requiring special handling. Common mistake: force-deleting the namespace with \`--force --grace-period=0\` \(doesn't work on namespaces\) or deleting finalizers blindly without cleaning external resources \(leaks IP addresses, disks, load balancers\). The correct approach is surgical: identify the specific resource blocking, resolve the external state or the controller, then remove the finalizer only if the cleanup is verified or impossible.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T12:43:20.567569+00:00— report_created — created