Contexts & Namespaces
kubectl contexts + namespaces: switch between clusters, point to the right one, and never apply to prod by accident.
Kubernetes — kubectl contexts
EXAMPLE
# ===== List + select ===== kubectl config get-contexts kubectl config current-context kubectl config use-context my-cluster # ===== Set the default namespace ===== kubectl config set-context --current --namespace=dev # ===== Add a context manually ===== kubectl config set-cluster prod \ --server=https://k8s.prod.example.com \ --certificate-authority=./prod-ca.crt kubectl config set-credentials prod-user \ --client-certificate=./prod.crt \ --client-key=./prod.key kubectl config set-context prod \ --cluster=prod \ --user=prod-user \ --namespace=apps kubectl config use-context prod # Or just edit ~/.kube/config in YAML. # ===== Multi-file KUBECONFIG ===== export KUBECONFIG=~/.kube/config:~/.kube/prod.yaml:~/.kube/staging.yaml kubectl config get-contexts # Merge them into one file: KUBECONFIG=~/.kube/dev.yaml:~/.kube/prod.yaml kubectl config view --flatten > ~/.kube/merged.yaml # ===== Quality of life ===== # kubectx: switch contexts fast brew install kubectx kubectx # list kubectx prod # switch kubectx - # previous kubectx -d old-context # delete # kubens: switch namespaces fast kubens kubens kube-system # Prompt indicator: # Use kube-ps1 or starship to show context + namespace in the shell prompt. # ===== Per-shell context (avoid cross-talk) ===== # Use KUBECONFIG per shell: export KUBECONFIG=~/.kube/prod.yaml kubectl get nodes # Or use kubie / kubectx -t for shell-scoped switching. # ===== Safety patterns ===== # - Prod context name has 'prod' in it; configure your shell prompt to colour red # - Require confirmation for destructive ops: alias kdel='kubectl delete --dry-run=client' # default to dry-run; override consciously # - Read-only kubeconfig for production audits # ===== Pitfalls ===== # - Sharing a single ~/.kube/config across many clusters -> easy to mis-target # - Forgetting which context you're on (set up a prompt!) # - Old contexts left in config -> autocomplete confusion # - 'kubectl --context prod-X' typed wrong while in another context # ===== Pattern: scripts that are explicit ===== #!/usr/bin/env bash set -euo pipefail CONTEXT=$(kubectl config current-context) EXPECTED=staging if [ "$CONTEXT" != "$EXPECTED" ]; then echo "refusing: expected $EXPECTED, got $CONTEXT"; exit 1 fi kubectl apply -f deploy.yaml # ===== Patterns to internalise ===== # - Multiple kubeconfig files merged via KUBECONFIG env var # - kubectx + kubens for daily switching # - Shell prompt indicator showing context + namespace # - Scripts verify expected context before mutating # ===== Pitfalls ===== # - Cross-context kubectl apply -> wrong cluster gets changes # - Cached credentials in kubeconfig that have expired # - Pinning long-lived tokens in kubeconfig instead of using OIDC / SSO # - 'use-context' globally when a single command would have done it (--context flag)
Why it matters
Contexts are your seatbelt. Multiple kubeconfigs merged via KUBECONFIG, kubectx + kubens for switching, prompt indicator showing where you are, scripts that refuse to run in the wrong context. Most kubectl-against-prod accidents come from forgetting which cluster you are in.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
kubectl config get-contexts kubectl config use-context my-cluster kubectl create namespace shopTry it Yourself »
Discussion
Loading…