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