Error from server (NotFound): The named object does not exist in the namespace that was searched

A NotFound error means Kubernetes looked and found nothing. Most often the object is in a different namespace than the one the command defaulted to.

Applies to: All Kubernetes versions

What it means

Kubernetes returns 404 when a named object does not exist in the scope searched. The scope is the part that catches people: kubectl uses the namespace from the current context unless told otherwise, and that context is easy to forget. A second, subtler case is a resource kind that does not exist in the cluster at all — a custom resource whose definition has not been installed produces a similar-looking failure, though the wording differs, saying the server has no such resource rather than no such object. Distinguishing a missing object from a missing kind saves searching for something that could never have been there.

Most common causes

• The object is in a different namespace than the current context.
• The object name is misspelled — names are case-sensitive.
• The object was deleted, by a person, by a controller, or by a garbage collector after its owner was removed.
• The resource kind is not installed in the cluster, in the case of a custom resource.
• The object exists but the API version requested does not serve it, after a deprecation removal.
• A namespace that itself does not exist, in which case nothing in it can be found.

How to diagnose it

1. Search across namespaces: kubectl get RESOURCE --all-namespaces | grep NAME.
2. Check the current namespace: kubectl config view --minify -o jsonpath='{..namespace}'.
3. Check whether the kind exists at all: kubectl api-resources | grep RESOURCE.
4. Look for a recent deletion in events: kubectl get events --all-namespaces --field-selector reason=Killing, or check audit logs if available.
5. If the object had an owner, check whether the owner was deleted — cascading deletion removes dependents automatically.

How to fix it

1. Add -n NAMESPACE, or change the context's default namespace.
2. Correct the name.
3. Install the CustomResourceDefinition before creating objects of that kind.
4. Use a served API version: kubectl api-versions lists what the cluster offers.
5. Recreate the object if it was genuinely deleted, and check ownership references if you did not expect it to be.

Notes

Cascading deletion via owner references removes dependent objects silently and correctly. An object that vanished without anyone deleting it directly usually had an owner that was deleted, and its ownerReferences would have named it.

Related

• no matches for kind — The cluster does not recognise this resource type
• Error from server (Forbidden) — RBAC denied the request

Sources

• Kubernetes documentation — Object Names and IDs
• Kubernetes documentation — Kubernetes API Concepts
• Kubernetes documentation — Custom Resources