# kubectl version: Usage, Options & Common CI Errors

> kubectl version reports client and server versions. The skew policy, scripting with -o json, and the connection error when the server is unreachable.

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

Print the kubectl client and cluster server versions.

kubectl version reports the version of the kubectl binary and, by contacting the cluster, the API server version. In CI it is both a preflight connectivity check and a guard against unsupported client/server skew.

## What it does

kubectl version prints the client version and the server version (the latter requires a reachable cluster). --client skips the server call for an offline check; -o json or -o yaml makes the output machine-readable so a pipeline can assert on the minor version. --short was removed; the default output is already concise.

## Common usage

```Terminal
kubectl version
kubectl version --client
kubectl version -o json
kubectl version -o json | jq -r '.serverVersion.minor'
```

## Common errors in CI

kubectl supports only +/-1 minor version of skew from the API server; a runner pinning an old kubectl against a freshly upgraded cluster (or vice versa) can hit "the server could not find the requested resource" or odd field errors - print kubectl version early to catch skew. Without --client, kubectl version makes a real API call, so on a runner with no kubeconfig it errors "The connection to the server localhost:8080 was refused" - use --client when you only need the client version. Pin the kubectl version in CI to a known-good minor for the target cluster.

## 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 version: Usage, Options & Common CI Errors?

kubectl version reports the version of the kubectl binary and, by contacting the cluster, the API server version. In CI it is both a preflight connectivity check and a guard against unsupported client/server skew.

### What it does?

kubectl version prints the client version and the server version (the latter requires a reachable cluster). --client skips the server call for an offline check; -o json or -o yaml makes the output machine-readable so a pipeline can assert on the minor version. --short was removed; the default output is already concise.

### Common errors in CI?

kubectl supports only +/-1 minor version of skew from the API server; a runner pinning an old kubectl against a freshly upgraded cluster (or vice versa) can hit "the server could not find the requested resource" or odd field errors - print kubectl version early to catch skew.

---

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