kubectl config use-context: Usage, Options & Common CI Errors
Switch kubectl to the cluster/user/namespace of a named context.
kubectl config use-context sets which context - the cluster, user, and default namespace triple - kubectl uses for subsequent commands. In CI it is how you point the pipeline at the right cluster before deploying.
What it does
kubectl config use-context NAME makes NAME the current-context in the active kubeconfig. get-contexts lists what is available; current-context prints the active one. For a single command you can avoid switching global state with the per-invocation --context=NAME flag, which is safer in parallel CI.
Common usage
kubectl config get-contexts
kubectl config use-context prod-cluster
kubectl config current-context
kubectl --context=prod-cluster get pods # per-command, no state changeCommon errors in CI
"error: no context exists with the name: \"X\"" means the context is not in the kubeconfig CI loaded - the runner often has no ~/.kube/config, so set KUBECONFIG to the file you wrote credentials into, or use --context. use-context mutates shared kubeconfig state, so in parallel jobs sharing a KUBECONFIG it races - prefer per-command --context or a per-job KUBECONFIG copy. Always echo kubectl config current-context early so a wrong-cluster deploy fails loudly instead of silently hitting the wrong cluster's default namespace.
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