iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

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 shop
Try it Yourself »

Discussion

Loading…