kubectl config set-context: Usage, Options & Common CI Errors

Create a context or pin a default namespace so you stop typing -n.

kubectl config set-context creates or modifies a context, most commonly to pin a default namespace so every later command targets it without -n. It is the small ergonomics fix that prevents whole classes of wrong-namespace CI bugs.

What it does

kubectl config set-context --current --namespace=NS sets the default namespace on the active context. set-context NAME --cluster=... --user=... --namespace=... creates or edits a named context from its parts. After pinning, kubectl get pods queries NS without needing -n NS each time.

Common usage

kubectl config set-context --current --namespace=staging
kubectl config set-context ci --cluster=dev --user=ci --namespace=pr-${PR_NUMBER}
kubectl config use-context ci
kubectl config view --minify | grep namespace        # confirm the pin

Common errors in CI

Pinning a namespace that does not exist yet does not error here, but later commands fail with "namespaces \"X\" not found" - create the namespace first. set-context mutates shared kubeconfig state, so like use-context it races across parallel jobs sharing one KUBECONFIG; use a per-job copy. A common subtlety: --current edits the active context, while set-context NAME without --current edits (or creates) a named one - mixing them up silently writes to the wrong context. After pinning, verify with kubectl config view --minify so a deploy does not land in the default namespace by accident.

Related guides