kubectl config: Usage, Options & Common CI Errors
Manage which cluster, user, and namespace kubectl talks to.
kubectl config reads and modifies your kubeconfig: the set of clusters, users, and contexts kubectl can use. In CI it is how you select the target cluster and pin a default namespace.
What it does
kubectl config get-contexts lists available contexts; use-context switches the active one; set-context --current --namespace=X pins a default namespace so you stop typing -n. current-context prints what you are pointed at - the first thing to log in a deploy pipeline to prove you are on the right cluster.
Common usage
kubectl config get-contexts
kubectl config current-context
kubectl config use-context prod-cluster
kubectl config set-context --current --namespace=staging
kubectl config view --minify --flatten # the active context onlyCommon errors in CI
"error: no context exists with the name: \"X\"" means the context is not in the kubeconfig that CI loaded - the runner often has no ~/.kube/config, so set KUBECONFIG to the path you wrote the credentials to, or pass --context. "The connection to the server localhost:8080 was refused" is the tell-tale of no kubeconfig at all: kubectl fell back to its default and found nothing. Always echo kubectl config current-context early so a wrong-cluster deploy fails loudly instead of silently targeting the default namespace of the wrong 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