kubectx: Rename and Delete Contexts
kubectx NEW=OLD renames a context (e.g. the auto-generated EKS ARN) to a short name, and kubectx -d removes one.
Cloud providers generate enormous context names like an EKS ARN. Aliasing them once makes every later switch and script readable.
What it does
kubectx edits the kubeconfig in place. NEW=OLD renames a context and updates current-context if it pointed there. -d deletes one or more contexts. . as the OLD name renames the current context.
Common usage
kubectx prod=arn:aws:eks:us-east-1:123:cluster/prod
kubectx dev=. # rename the current context to "dev"
kubectx -d old-staging # delete a stale context
kubectx -d ctx-a ctx-b # delete several at onceOptions
| Form | What it does |
|---|---|
| <new>=<old> | Rename context <old> to <new> |
| <new>=. | Rename the current context to <new> |
| -d <name>... | Delete the named context(s) |
| -u, --unset | Unset the current context |
Common errors in CI
error: No context exists with the name: "old-staging" on -d means it was already removed or never present. Renaming with <new>=<old> where <new> already exists fails with context "<new>" already exists; delete or pick another alias. Edits write to the first file in KUBECONFIG; a read-only mounted kubeconfig fails with permission denied.
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