• search

Kubectl Get Context 🏆

CURRENT NAME CLUSTER AUTHINFO minikube minikube minikube * prod-dallas prod-cluster-dallas admin-prod staging-eu staging-cluster-eu deployer legacy-bare-metal legacy-cluster old-admin The asterisk told him he was currently pointing at . His heart rate doubled. That was production . Live traffic. Real money. Customers ordering cat-shaped planters at 2 AM.

alias k-get-ctx='kubectl config get-contexts' Then, just before hitting kubectl apply -f payment-fix.yaml , he ran it again. The asterisk still shone beside prod-dallas . Good. No last-minute surprises.

That night, Vlad added a sticky note to his monitor: And from that day on, not once did he deploy staging YAML to prod—or worse, to the do-not-touch cluster that, rumor had it, still ran the original prototype of the cat planter checkout flow from 2018. kubectl get context

kubectl get context But it didn’t work. The terminal spat back: error: unknown command "get context" - did you mean "config get-contexts"? Right. He’d misremembered. He corrected it:

It was Vlad’s first day on the job as a platform engineer at a chaotic startup called Nebulous Systems. The previous “kube-whisperer” had left behind a labyrinth of Kubernetes clusters: staging, prod, legacy, and one ominously named “do-not-touch.” CURRENT NAME CLUSTER AUTHINFO minikube minikube minikube *

kubectl config get-contexts The output appeared like a cryptic map:

kubectl config use-context prod-dallas But instead of applying immediately, he paused. He wrote a tiny bash alias: Live traffic

kubectl config use-context staging-eu Switched to context "staging-eu". He applied the fix. It worked perfectly. Then, with a deep breath, he switched back: