I use Minikube to run a local Kubernetes single node cluster (cluster?). However, I also work with a custom production cluster for work. This cluster consists of development and production nodes. I often need to switch between working on my local Minikube and the online Kubernetes cluster.
TIP: Visit the kubectl Cheat Sheet often.
§2026 Update
This post is from 2018, and the kubectl config commands below all still work exactly as written. The mental model holds: a context ties a cluster, a user, and a namespace together, and you switch between them. Two things are worth adding from here.
First, you rarely hand-build a client-certificate config for a cloud cluster anymore. As of Kubernetes 1.26, the in-tree authentication for GKE, EKS, and AKS was removed in favor of exec credential plugins, and the cloud CLIs write the kubeconfig for you: gcloud container clusters get-credentials, aws eks update-kubeconfig, or az aks get-credentials (GKE also needs the gke-gcloud-auth-plugin binary now). The manual set-cluster / set-credentials / set-context flow in this post is still the right approach for self-managed and bare-metal clusters, and it is the best way to understand what those CLI helpers are actually writing into your config.
Second, you do not have to keep everything in one ~/.kube/config. The KUBECONFIG environment variable merges multiple files, so I keep clusters in separate files and combine them on demand:
export KUBECONFIG=~/.kube/config:~/.kube/prod:~/.kube/staging
kubectl config get-contexts
And for the actual switching, typing kubectl config use-context by hand gets old fast. These days I use kubectx and kubens to jump between contexts and namespaces, and k9s when I want a live terminal UI over a cluster. They take most of the friction out of the local-to-remote switching this post is about.
Original article below. Everything from here down is the post as originally written. The 2026 Update above covers what’s changed since.
The default configuration kubectl is stored in ~/.kube/config and
if you have Minikube installed, it added the context minikube to your config.
With kubectl you can specify a config to use with the command flag --kubeconfig.
Below I am just pointing to default config. However, you can replace that with a different config to test.
kubectl --kubeconfig=/Users/enochroot/.kube/config config view
In addition to specifying a configuration file to use, kubectl configs also contain contexts. Each configuration file can have multiple contexts.
§Current Context
A context is a combination of cluster, namespace and user.
View the current context:
kubectl config view
You should now see the output the default configuration file.
You can see we have only one context by default on a workstation that just installed Minikube. You can also see the key current-context: is set to minikube.
Check the current config context:
kubectl config current-context
Output:
minikube
§Add a Cluster
Get the public certificate from your cluster or use --insecure-skip-tls-verify:
kubectl config set-cluster example --server https://example.com:6443 --certificate-authority=example.ca
Output
Cluster "example" set.
§Add a User
Users in the configuration can use a path to a certificate --client-certificate or use the certificate data directly --client-certificate-data
kubectl config set-credentials example \
--client-certificate=/some/path/example.crt \
--client-key=/some/path/example.key
§Add a Context
Add a context to tie a user and cluster together.
kubectl config set-context deasil --cluster=example \
--namespace=default --user=example-admin
§Change Current Context
At this point you can change your current context from minikube to example:
kubectl config use-context example
Output:
example
Of course, kubectl config use-context minikube will put you back
to managing your local Minikube.
§Port Forwarding / Local Development
Check out kubefwd for a simple command line utility that bulk forwards services of one or more namespaces to your local workstation.