Recommended Free Tools
It depends on how the resources are connected to the operator’s custom resource. Kubernetes garbage collection removes dependent Kubernetes objects when valid owner references and a cascading deletion policy apply. The operator’s controller may also perform cleanup required by its implementation. Finalizers can hold an object in a terminating state until a controller completes its cleanup work.
How deletion responsibility is divided
An operator controller watches custom resources and reconciles related resources toward the state the operator defines. When a custom resource is deleted, the controller may need to carry out its own cleanup, but Kubernetes can also remove dependent objects through its garbage collector. Which mechanism applies depends on the object relationships and deletion behavior configured for that resource.
Kubernetes Documentation explains: “Many objects in Kubernetes link to each other through owner references. Owner references tell the control plane which objects are dependent on others.” Kubernetes’ garbage-collection documentation describes this relationship.
Owner references tell Kubernetes what depends on what
A child object’s metadata.ownerReferences identifies its owner. When the owner is deleted with cascading deletion, the garbage collector can find and remove the dependent object. Labels and selectors can help an operator find resources, but they do not establish this garbage-collection relationship by themselves.
#1 Best Overall
Scope matters: a namespaced owner must be in the same namespace as its dependent. A cluster-scoped dependent can refer only to a cluster-scoped owner. An invalid owner reference can therefore prevent the relationship from working as expected. See Kubernetes’ owners and dependents documentation.
Deletion propagation changes the outcome
Kubernetes supports three propagation policies. The policy determines whether dependents are cleaned up in the background, whether their cleanup delays the owner’s removal, or whether they are left behind.
| Policy | What happens to the owner | What happens to dependents |
|---|---|---|
| Background | The owner is removed promptly. | The garbage collector removes dependents afterward; they may remain briefly after the owner disappears from the API. |
| Foreground | The owner remains visible while dependent cleanup is underway. | Dependent cleanup must proceed before the owner is fully removed. |
| Orphan | The owner is deleted without cascading cleanup. | Dependents are deliberately left behind. |
These behaviors are described in Kubernetes’ garbage-collection documentation and its guide to using cascading deletion in a cluster.
Finalizers can keep resources in a terminating state
A finalizer is a signal that required work must happen before Kubernetes can fully delete an object. As Kubernetes Documentation puts it, “Finalizers are namespaced keys that tell Kubernetes to wait until specific conditions are met before it fully deletes resources that are marked for deletion.”
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →When deletion is requested for an object with finalizers, Kubernetes records a deletion timestamp and leaves the object in a terminating state. The controller responsible for the finalizer must complete its work and remove the finalizer before deletion can finish. Finalizers on dependent objects can also affect how dependent cleanup completes. Read Kubernetes’ finalizers documentation for details.
Why operator-created resources may remain
A resource that remains after its custom-resource owner is deleted does not necessarily indicate a Kubernetes failure. Common explanations include:
- No valid owner reference: The operator may have created the object without an owner reference, or the reference may not identify a valid owner in the required scope.
- Orphan propagation: The deletion policy may have intentionally retained dependents.
- Cleanup is still running: Background garbage collection may not have finished, or foreground deletion may be waiting for dependent cleanup.
- A finalizer is still present: The relevant controller has not completed its cleanup or removed its finalizer.
- The resource is outside Kubernetes: Cloud services, databases, and other provider-side resources are not Kubernetes objects for the garbage collector to remove. Their cleanup depends on explicit behavior implemented by the operator.
How to diagnose a leftover resource
- Inspect the child’s owner references. Check
metadata.ownerReferencesand confirm the owner UID, kind, and namespace relationship. Do not infer garbage-collection ownership from labels alone. - Check deletion timestamps and finalizers. Inspect both the owner and the dependent for a deletion timestamp and any remaining finalizers. A finalizer means deletion is waiting on work.
- Identify the propagation policy. Determine whether deletion used background, foreground, or orphan propagation. Orphan propagation retains dependents by design; background cleanup can continue after the owner is gone from the API.
- Check the operator’s cleanup behavior. Review how that operator handles resources without owner references and any external infrastructure it manages. Such behavior is specific to the operator.
Do not remove a finalizer simply to make an object disappear. First determine what cleanup it represents and complete that work where possible; removing it without doing so can leave resources or external infrastructure behind. Kubernetes documents this caution in its finalizers guide.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
