Free tools Windows power users keep installed
One-click scans. No signup required.
Uninstalling a Kubernetes operator is not the same as deleting the custom resources (CRs) it manages or the CustomResourceDefinitions (CRDs) that make those resources available. To avoid losing application data or skipping operator-specific cleanup, inventory what the operator owns, decide what must be retained, let the operator finish any required cleanup, and remove CRs or CRDs only when you have confirmed their scope and consequences.
Know what you are removing
An operator is a controller: it watches resources and reconciles them toward a desired state. A CR is an instance of an extension API and may represent an application or service. A CRD defines that API. These are separate cluster objects, and deleting one does not automatically mean the others have been deleted or cleaned up.
As an Amazon Associate I earn from qualifying purchases.
- Removing the operator stops that controller from reconciling resources. It does not prove that resources it created, or external infrastructure it manages, have been removed.
- Deleting a CR requests deletion of that particular instance. If it has a finalizer, deletion can remain pending while cleanup runs.
- Deleting a CRD removes the API endpoint and all custom objects stored through that definition. Recreating the CRD does not restore those objects.
Owner references and Kubernetes garbage collection affect dependent Kubernetes objects, but they do not establish what an operator does to external services, storage, or application data. Check the documentation for the specific operator and version before choosing a cleanup sequence.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Plan the removal before changing the cluster
1. Identify the installation method and inventory resources
Find out whether the operator was installed through Operator Lifecycle Manager (OLM) or another mechanism, such as a Helm release or directly applied manifests. The removal procedure depends on that method. Record the operator version, namespace, controller deployment or other workload, and any OLM subscription or package objects involved.
#1 Best Overall
Inventory the operator’s CRDs, APIService objects, CRs, and resources it manages. Check both namespaced and cluster-scoped resources; a namespace-only listing will not reveal everything. Use read-only inspection first, and confirm the namespace and resource type in each command:
kubectl get deployments,statefulsets,daemonsets -A
kubectl get crd
kubectl api-resources
kubectl get apiservices
kubectl get <custom-resource-kind> -A
kubectl get <custom-resource-kind> -n <namespace> <name> -o yamlReplace the angle-bracketed values with the actual resource kind, namespace, and name. Some CRs are cluster-scoped, so omit -n when appropriate. Inspect resource metadata, including owner references, labels, finalizers, and deletion timestamps. Labels can help identify a set, but do not assume a label selector precisely matches operator-owned resources unless you have verified it.
2. Decide what must survive and make a recovery plan
Decide separately whether to retain the CRs, their associated application data, dependent Kubernetes objects, and external infrastructure. Confirm what backups exist and how they can be restored before destructive cleanup. If CRs must remain usable, keep their CRD and any other API components they require. Deleting a CRD is not a way to pause or uninstall an operator while preserving its custom objects.
Recommended Free Tools
3. Check whether cleanup needs the operator
Some operators use finalizers to run application-specific or external cleanup when a CR is deleted. A finalizer keeps the object in a terminating state until the responsible cleanup path completes and removes the finalizer. If a CR’s documented deletion process requires the operator, perform that process while the controller is still installed and healthy. Removing the controller or API path too early can leave deletion waiting on work that can no longer run.
Choose the order based on what you want to retain
| Goal | Safer general order | What to verify |
|---|---|---|
| Remove the operator but retain CRs | Use the installer’s operator-removal procedure; retain the CRDs and CRs. | Confirm the API remains available and understand that reconciliation stops when the controller is gone. Check whether the operator has other required components, such as an APIService. |
| Delete CRs and allow operator-specific cleanup | Delete the selected CRs while the operator and its required APIs are available; wait for cleanup to finish; then remove the operator using its installer’s procedure. | Follow the operator’s version-specific deletion instructions and watch for finalizers, events, and controller health. |
| Remove CRs without operator-specific cleanup | Proceed only if the operator documentation and data-retention decision confirm that bypassing or omitting that cleanup is acceptable. Then remove the operator and selected resources deliberately. | Establish the effect on application data, dependent objects, and external infrastructure; do not infer it from a successful controller uninstall. |
| Remove the CRD and all CRs stored through it | First confirm that every object of that type can be discarded and that any required cleanup and backups are complete. Delete the CRD only as an intentional destructive action. | CRD deletion removes the custom API endpoint and its stored custom objects. Re-creating the definition does not bring the objects back. |
Remove the operator using its installation method
If OLM installed the operator
OLM’s uninstall guidance says that an administrator must decide what to do with operator-owned resources. By design, OLM does not remove owned CRDs, APIServices, or CRs when it uninstalls an operator, to help prevent data loss. That retention is not a guarantee that every resource is safe to keep indefinitely: check the installed OLM and operator versions, and follow the operator’s own decommissioning instructions.
Use the OLM procedure applicable to the cluster rather than deleting controller objects ad hoc. Before confirming removal, make sure you have decided whether to retain or later delete the CRs, CRDs, and APIServices. Do not assume the operator uninstall has removed them.
Rank #3
If another mechanism installed it
Use the corresponding package or deployment mechanism’s uninstall procedure, such as the procedure for the actual Helm release or manifest set. Avoid broad cleanup by guessed name, label, or namespace. If using declarative pruning, ensure the manifests, allowlist or ApplySet, labels, and cluster scope identify only the intended objects; pruning an inaccurate set can delete unrelated resources.
Delete selected custom resources deliberately
Before deleting a CR, inspect its namespace or cluster scope, owner references, finalizers, and any dependent resources. Kubernetes supports background, foreground, and orphan cascading deletion. With background deletion, the default for kubectl delete, the owner is deleted before dependents are removed. Foreground deletion waits for dependent objects to be deleted first. Orphan deletion removes the owner but leaves dependents behind; it is not a cleanup of those dependents.
For example, after confirming the exact kind, namespace, and name, choose a cascade policy explicitly when the default is not what you want:
kubectl delete <custom-resource-kind> <name> -n <namespace> --cascade=background
kubectl delete <custom-resource-kind> <name> -n <namespace> --cascade=foreground
kubectl delete <custom-resource-kind> <name> -n <namespace> --cascade=orphanRun only the command that matches the intended outcome. Omit -n <namespace> for a cluster-scoped CR. If deleting a verified, intended set, review the selector and matched objects before using it; do not rely on a selector simply because it resembles an operator label. The kubectl delete reference documents these cascade choices, says background is the default, and notes that --wait defaults to true and waits for finalizers. Avoid --force as a shortcut: the reference warns it can cause inconsistency or data loss for some resources.
Investigate CRs stuck in Terminating
A terminating CR is often waiting for a finalizer to be processed; it is not, by itself, evidence that the object is safe to force-delete. Diagnose why the cleanup path has not completed before changing metadata.
- Inspect the object: check its
metadata.finalizers,metadata.deletionTimestamp, namespace, owner references, and recent events. - Check the responsible controller: verify that the operator and any required components are still running and healthy, and examine their events or logs. Confirm the CRD and any needed APIService remain available.
- Follow the operator’s cleanup instructions: resolve the reported failure or restore the component needed to complete cleanup, then allow the finalizer to be removed through the normal process.
- Escalate before bypassing: manually removing a finalizer can let Kubernetes remove the object without the cleanup it was meant to protect. Do this only after determining what work may be skipped and accepting that consequence.
Removing a finalizer is not equivalent to completing the cleanup. It can leave dependent Kubernetes objects or external resources behind, and recovery may require operator-specific steps.
Delete CRDs only as destructive cleanup
Delete a CRD only after confirming that all CRs stored through it can be discarded and that the intended backup, retention, and cleanup decisions are complete. Removing the CRD removes both the API endpoint and the custom objects under that type. If you intend to retain those objects, retain the CRD instead; reinstalling the definition later does not recover deleted CRs.
After deleting a CRD, the kubectl reference says invalidation of discovery cache may take up to six hours. If discovery appears stale, run kubectl api-resources to refresh it. A stale discovery result is different from proof that the CRD or its data still exists.
Quick Recap
Final checks
- Confirm the operator controller and installer objects were removed as intended.
- Confirm retained CRs still have the CRD and API components they need, while recognizing that they will no longer be reconciled by a removed controller.
- Check for remaining selected CRs, dependents, APIServices, and external resources according to the operator’s documented behavior.
- Confirm any objects left by orphaning are accounted for, rather than assuming they were cleaned up.
- Keep the backup and recovery plan for any retained application data or objects.
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.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →
