no matches for kind: The cluster does not recognise the resource type in your manifest

unable to recognize …: no matches for kind "X" in version "Y" means the API version and kind combination is not served by this cluster — the CRD is missing, or the version was removed.

Applies to: All Kubernetes versions

What it means

Before sending an object, kubectl resolves its apiVersion and kind against the cluster's discovery information. If no served resource matches, the request never leaves the client. Two distinct situations produce this. Either the type is a custom resource whose CustomResourceDefinition is not installed — very common when a manifest bundle applies a CRD and an instance of it in the same pass, and the instance is processed before the definition is established. Or the type is built in but the manifest names an API version the cluster no longer serves, which happens on upgrades that complete a long-announced deprecation.

Most common causes

The CustomResourceDefinition for this kind is not installed.
A CRD and an instance of it applied together, where the CRD is not yet established when the instance is processed.
A deprecated API version removed in the cluster's Kubernetes version.
A typo in apiVersion or kind — both are case-sensitive.
An operator or controller not installed, so the kinds it defines do not exist.
An aggregated API server that is unavailable, so its resources vanish from discovery.

How to diagnose it

List what the cluster serves: kubectl api-resources, and kubectl api-versions for versions.
Check for the CRD: kubectl get crd | grep KIND.
Check whether an existing CRD is established: kubectl get crd NAME -o jsonpath='{.status.conditions}'.
For built-in kinds, check the deprecation guide for the cluster's version to find the replacement.
If an aggregated API is involved, check its APIService is available: kubectl get apiservices | grep -v True.

How to fix it

Install the CRD or the operator that provides the kind, and wait for it to be established before applying instances.
Split manifest application into stages so CRDs are applied and established before their instances.
Update the manifest to a served API version.
Correct spelling and capitalisation in apiVersion and kind.
Restore an unavailable aggregated API server.

Notes

Because this check happens client-side against discovery, a stale discovery cache can produce the error for a kind that does exist. Clearing the cache, usually under the kubectl cache directory, resolves that case and rules it out quickly.

Sources

Pages on this site are written with AI assistance from the primary sources listed on each page, then checked against those sources before publishing.