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

> kubectl api-versions lists the API group/versions the cluster serves. Guarding manifests against removed APIs in CI, and api-versions vs api-resources.

Source: https://latchkey.dev/learn/command-reference/kubectl-api-versions  
Updated: 2026-06-25

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.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

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

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

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt