kubectl "no matches for kind in version" (apiVersion) in CI
kubectl maps each kind+apiVersion to a served API. When a manifest uses a version the cluster has dropped (a removed beta API) or a CRD that is not installed, there is no match to apply against.
What this error means
A kubectl apply step fails to recognize a manifest with "no matches for kind X in version Y", typically after a cluster upgrade removed a deprecated apiVersion.
kubectl
error: unable to recognize "ingress.yaml": no matches for kind "Ingress" in
version "extensions/v1beta1"Common causes
Removed deprecated apiVersion
A cluster upgrade dropped a beta API (for example extensions/v1beta1 Ingress) the manifest still uses.
CRD not installed
A custom kind's CRD is absent, so its apiVersion is not served.
How to fix it
Migrate to the served apiVersion
- Update the manifest to the current stable apiVersion for the kind (for example
networking.k8s.io/v1Ingress). - Confirm with
kubectl api-resources/kubectl api-versionswhat the cluster serves. - For CRDs, install the operator/CRD first.
Terminal
kubectl api-versions | grep networkingHow to prevent it
- Track apiVersion deprecations against your cluster version (use
kubectl deprecationstooling). - Lint manifests against the target cluster version in CI.
- Install CRDs before the resources that use them.
Related guides
kubectl "the server doesn't have a resource type" (CRD/API version) in CIFix kubectl "the server doesn't have a resource type" in CI - the custom resource's CRD is not installed, or…
kubectl "error validating data: ValidationError" in CIFix kubectl "error validating data: ValidationError" in CI - a manifest has an unknown or wrongly-typed field…
kubectl "error parsing ... yaml" on apply in CIFix kubectl "error parsing ... yaml" in CI - a manifest is not valid YAML (bad indentation, tabs, or a templa…