Skip to content
Latchkey

kubectl api-versions: Usage, Options & Common CI Errors

List every API group/version the cluster currently serves.

kubectl api-versions prints the group/version pairs the API server exposes, so you can confirm a manifest's apiVersion is actually served before applying. It is the quick guard against deploying against an API a cluster upgrade removed.

What it does

kubectl api-versions outputs lines like apps/v1, batch/v1, networking.k8s.io/v1 - the served group/versions only, not the resource kinds inside them. For the kinds (and their short names and namespaced flag) use kubectl api-resources; api-versions answers "is this apiVersion available?".

Common usage

Terminal
kubectl api-versions
kubectl api-versions | grep networking.k8s.io
kubectl api-versions | grep -q 'batch/v1' || echo 'batch/v1 missing'

Common errors in CI

The failure this prevents is "no matches for kind \"X\" in version \"Y\"" at apply time, which happens when a cluster upgrade removed a beta API your manifest still targets (the perennial example was Ingress/HPA/CronJob beta removals). Check api-versions in CI before applying so the pipeline fails with a clear reason. Note api-versions reflects what the server serves now, which can differ from what a CRD declares as storage version, so a freshly installed CRD may not appear until its API is registered. Pin manifests to stable (v1) groups wherever possible.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →