Skip to content
Latchkey

kubectl "no matches for kind ... in version" (removed API) in CI - Fix it

The manifest declares an apiVersion that this cluster no longer serves. Kubernetes removes deprecated API versions (for example extensions/v1beta1 Ingress, apps/v1beta2 Deployment) at known releases, and applying the old group/version fails outright.

What this error means

A kubectl apply fails with error: unable to recognize "ingress.yaml": no matches for kind "Ingress" in version "extensions/v1beta1" after a cluster upgrade.

kubectl
error: unable to recognize "ingress.yaml": no matches for kind "Ingress" in
version "extensions/v1beta1"

Common causes

The apiVersion was removed in this cluster version

A manifest pinned to a beta group/version that was dropped in a newer Kubernetes release no longer maps to any served resource.

A manifest written for an older cluster

The YAML predates an upgrade and was never migrated to the stable apiVersion.

How to fix it

Migrate the manifest to the served apiVersion

  1. List which versions the cluster serves for that kind.
  2. Update apiVersion (for example networking.k8s.io/v1 for Ingress) and adjust any renamed fields.
  3. Re-apply against the cluster.
Terminal
kubectl api-resources | grep -i ingress
kubectl api-versions | grep networking

Catch removed APIs before upgrading

A deprecation scanner flags manifests that use APIs removed in the target version so the migration lands first.

Terminal
# example: scan manifests for removed/deprecated APIs
kubectl apply -f k8s/ --dry-run=server

How to prevent it

  • Migrate manifests to stable apiVersions before upgrading the cluster.
  • Scan for deprecated APIs in CI ahead of cluster version bumps.
  • Pin manifests to GA group/versions, not beta ones.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →