You’ve just been bitten by the .
Mastering the art of kubectl config use-context before you accidentally deploy your test app to the live cluster. Let me paint a picture. It’s 3:00 PM on a Tuesday. You’ve been debugging a tricky authentication bug in your staging environment for two hours. You finally fix it. You type kubectl apply -f deployment.yaml and hit Enter. kubectl change context
kubectl config use-context <context-name> For example: You’ve just been bitten by the
We’ve all been there. And the single most important command to break that curse is: kubectl config use-context . By default, kubectl doesn't care about your feelings—or your environment. It remembers the last cluster you touched. If you were troubleshooting in dev-east yesterday, you’re likely still pointing at dev-east today. It’s 3:00 PM on a Tuesday
| CURRENT | NAME | CLUSTER | NAMESPACE | |---------|--------------------|--------------------|-----------| | * | dev-local | kind-dev | default | | | staging-gcp | gke-staging | frontend | | | prod-aws | arn:aws:eks:... | prod | Here’s where most tutorials stop, but you shouldn’t. A context is actually a triple: (cluster, user, namespace) .