Prod++[2]: Managing Kubernetes Context Files

In this mini-series I will walk you through some habits I replaced in recent times, which have shown to pay off and make me a more productive programmer/power-user of my computer. All these changes should be easy to gradually adopt, so I would highly recommend checking them out. If you’ve any suggestions ☝️ or improvements ✍️, then email me at or reach out using any of the social media listed here.

Prod++[2]: Managing Kubernetes Context Files

For anyone who ever worked a bit with Kubernetes, kubectx is probably quite familiar. Nothing painful there when you’re just running a local Minikube cluster, which auto-magically seems to add and update its configuration. In practice it’s updating the ~/.kube/config file every time you create or remove a cluster.

This kind of magic is all fine when you’re getting started, but soon enough you will find that Minikube is merely one of the sources of Kubernetes contexts. You might also be running kind, spin up some clusters in the cloud, or have your colleague share some with you. Soon the amount of different context credentials starts ramping up. kubectl doesn’t come with an elegant solution out of the box.

You might end up trying this config flattening solution suggested at StackOverflow. Great, now whenever you want to remove a context from your configuration you have to manually sift through this configuration file and delete all references — spoiler alert: this requires editing the space in two or more places. Also, assuming you were successful and didn’t overwrite the previous config, you now duplicated your configuration file.

So what are you going to do with this old configuration file? If you let it hang around, then you will slowly start collecting all these files, soon enough you will lose track which files are already merged and which are not. A mess is imminent if you do not delete them, but the flip side is that removing these files could be irrecoverable.

The Official Way

Luckily the official documentation has a suggestion on how to solve this issue: Append the new configuration file to the list of configuration files stored in the KUBECONFIGenvironment variable. Manually adding and removing paths to this environment variable remembered me of all the fun times with managing the PATH in Windows, which would never get even close to fit on my screen, let alone the small text field they reserved for it.

Don’t despair, here’s the real solution. Add it to your ~/.bashrc or ~/.zshrc and no need to ever touch KUBECONFIG manually again:

# Set the location of the Kubernetes configs
export KUBECONFIG=$(find ~/.kube/config ~/.kube/configs -type f 2>/dev/null | paste -s -d : -)

Now, every time you start your shell it will join all paths to ~/.kube/config or ~/.kube/configs and set them as your KUBECONFIG. Both can be either files or directories. I kept config as the default file, which Minikube and kind can use for their auto-magic. configs is a directory which contains all the context files. Now, adding or removing a file is as easy as respectively copying and deleting a file in ~/.kube/configs - don’t forget to restart the shell to take effect - which made managing all my configs so much easier.

To briefly touch upon how this piece of Bash works, find is used to list all file paths. Then paste merely joins all these file paths with a colon and violà, we got our KUBECONFIG.