A Kubernetes finalizer keeps an object present after deletion is requested so a controller can perform cleanup. The API records a deletion timestamp; the resource remains until the controller removes its finalizer. A stuck finalizer is therefore evidence of unfinished cleanup or a controller that cannot complete its work. Removing it by hand can leave cloud resources, volumes, or dependent objects behind.
Make this comfortable
Stuck finalizers: finish cleanup before removing the guard
Operational decision
A preview namespace remains Terminating after its branch was merged. Read the namespace's deletion timestamp, conditions, finalizers, and remaining namespaced resources. The commands are read-only and assume the current context is the disposable cluster. Check whether the responsible controller is healthy and has permission to delete external load balancers and volumes. Restore that controller or perform the specific cleanup under a tracked incident record. Only after confirming the external objects are gone should an authorized operator consider removing a finalizer, and that procedure depends on the resource type. Verify cloud inventory after deletion; an absent namespace does not prove every billable asset was removed. Preserve any recovery snapshot before deleting claims.
kubectl get namespace billing-review-47 -o yaml
kubectl get all -n billing-review-47
kubectl get pvc -n billing-review-47
kubectl get events -n billing-review-47 --sort-by=.lastTimestampCost and verification
Waiting for the correct controller may prolong preview cost, but bypassing cleanup can create a larger orphan bill or data-retention failure. Listing resources in a terminating namespace can miss provider-owned assets, so reconcile with external inventory. Deletion operations may be retried and must tolerate partial completion. Record which finalizer owner failed and whether the cleanup code needs a fix; merely clearing the field hides the recurring fault.
Common Mistakes
- Do not strip a finalizer merely to make a namespace disappear.
- Do not assume kubectl get all lists every namespaced resource.
- Do not delete the only recovery volume before verifying the retained snapshot.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Ephemeral environments: keep preview access and cost bounded
- Persistent storage: PVC lifecycle and data ownership
- Volume snapshots: test application-consistent restore
- Cloud cost and capacity: assign an owner to each recurring resource
Practice and check
GitOps operating-boundary follow-up
devops
operations