Minikube’s kubeconfig file is the key to unlocking your local Kubernetes cluster, but managing access across multiple clusters or environments can quickly become a tangled mess.
Let’s see it in action. Imagine you have Minikube running, and you want to interact with it. You’d typically run minikube kubectl -- get pods. This command tells Minikube to use its own kubectl instance, configured to talk to the Minikube cluster. But what if you want to use your system’s kubectl?
First, you need to get Minikube’s current configuration.
minikube kubectl -- config view --raw
This outputs a YAML structure that looks something like this:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <base64_encoded_CA_cert>
server: https://192.168.49.2:8443
name: minikube
contexts:
- context:
cluster: minikube
user: minikube
name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
user:
client-certificate-data: <base64_encoded_client_cert>
client-key-data: <base64_encoded_client_key>
This is your cluster’s access recipe. It tells kubectl where to find the cluster (server), how to authenticate (using certificate-authority-data, client-certificate-data, and client-key-data), and which user/cluster combination to use by default (current-context).
The real power comes when you want to combine this with other Kubernetes cluster configurations, perhaps from a cloud provider or another local setup. Your system kubectl usually reads from ~/.kube/config. To merge Minikube’s access into your main config, you use kubectl config commands.
First, let’s make sure you have a ~/.kube/config file. If not, create an empty one:
mkdir -p ~/.kube
touch ~/.kube/config
Now, you’ll export Minikube’s configuration and merge it. The minikube config write command is handy for this. It doesn’t just print; it writes to a specified file.
minikube config write ~/.kube/minikube-config.yaml
This creates a new file ~/.kube/minikube-config.yaml containing only your Minikube cluster’s details.
Next, you merge this into your primary ~/.kube/config.
KUBECONFIG=~/.kube/config:~/.kube/minikube-config.yaml kubectl config view --flatten > ~/.kube/merged-config.yaml
Let’s break this down:
KUBECONFIG=~/.kube/config:~/.kube/minikube-config.yaml: This environment variable tellskubectlto read configurations from both files, separated by a colon.kubectl config view: This command reads the configurations from the files specified inKUBECONFIG.--flatten: This crucial flag merges all the contexts, clusters, and users from the specified files into a single, unified structure. Without it, you’d just get a concatenation of the files’ contents.> ~/.kube/merged-config.yaml: This redirects the output of thekubectl config view --flattencommand into a new file namedmerged-config.yaml.
Now, you can replace your original ~/.kube/config with this merged file:
mv ~/.kube/merged-config.yaml ~/.kube/config
And finally, you can use your system’s kubectl to switch to your Minikube cluster:
kubectl config use-context minikube
kubectl get pods
You should see the pods running within your Minikube cluster. The kubectl config use-context minikube command sets minikube as the current-context in your ~/.kube/config file, ensuring kubectl knows which cluster to talk to.
The most surprising thing about managing multiple kubeconfigs is how kubectl config view --flatten handles conflicting names. If you have two contexts with the exact same name, the latter one in the KUBECONFIG path will overwrite the former in the flattened output. This means the order in your KUBECONFIG environment variable is critical for defining precedence.
Once you’ve merged configurations, you’ll often need to manage multiple contexts. You can list all available contexts with kubectl config get-contexts and switch between them using kubectl config use-context <context-name>.