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
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.