Manage multiple Kubernetes cluster configs cleanly using KUBECONFIG, improve CLI safety by showing your current context in the prompt, and enable autocompletion to boost productivity.
Introduction
When working with multiple Kubernetes clusters—whether across environments like dev, staging, and production or across different cloud providers—it’s easy to end up with a cluttered and fragile ~/.kube/config file.
Manually merging and switching between contexts can be tedious and error-prone. Fortunately, kubectl supports reading multiple config files by using the KUBECONFIG environment variable.
In this post, you’ll learn a clean, scalable way to manage multiple kubeconfigs, visualize your current context directly in your shell prompt, and enable command autocompletion for a smoother more efficient Kubernetes CLI experience.
Managing multiple Kubernetes Contexts
When you start working with Kubernetes you probably have a small number of Clusters so naturally you start to append new clusters and contexts manually to the kubeconfig or maybe rename the kubeconfig files to switch between contexts. This is exactly how I got started. But after a while as the number of clusters grows, this way simply won’t work anymore. To solve this problem, kubectl offers another way. Instead of reading the configuration from the default path ~/.kube/config, it supports setting the Environment Variable KUBECONFIG, which can contain multiple paths to multiple Kubeconfigs in the following format
KUBECONFIG=/path/to/config1:path/to/config2:
Organizing Your Kubeconfigs
First, create a dedicated folder to store your individual cluster contexts:
mkdir ~/kubeconfigs
Place your individual kubeconfig files in this folder.
Export KUBECONFIG to Read Multiple Configs
Set the KUBECONFIG environment variable to include all the files:
export KUBECONFIG=$(find ~/kubeconfigs/ -type f | tr '\n' ':')
This will dynamically load all the kubeconfigs from that folder into your current shell session.
Preview the Merged Kubeconfig
If you’d like to see how the combined file looks:
kubectl config view --flatten
(Optional) Generate a New Static Kubeconfig
If you prefer a single file after merging, which is not necessary if you export the KUBECONFIG Environment Variable
kubectl config view --flatten > ~/.kube/config
Persisting the Setup via .bashrc
To avoid manually exporting KUBECONFIG every time, add the export command to your shell startup file:
# ~/.bashrc or ~/.zshrc
#Set KUBECONFIG environment variable
export KUBECONFIG=$(find ~/kubeconfigs/ -type f | tr '\n' ':')
Then apply the changes:
source ~/.bashrc
Now every new shell will automatically have access to all your cluster contexts.
Show the Current Kubernetes Context in Your Shell Prompt
To avoid accidentally working in the wrong context, I developed this simple bash script to display the active Kubernetes context in your terminal prompt.
Add This to Your .bashrc:
## Get current Kube Context
k8s_info() {
kubectl config view --minify --output 'jsonpath={.current-context}' 2> /dev/null
}
## Add Kube Context to bash prompt
PS1="\[\e[01;33m\](\$(k8s_info))\[\e[0m\][\u@\h \w]\$ "
Example:
(my-kube-context)[user@centos ~]$
This helps prevent running kubectl commands on the wrong cluster.
Enable kubectl Autocompletion
Adding bash completion saves time and reduces typos.
Append this to your .bashrc:
#Kubernetes Bash Completion
source <(kubectl completion bash)
Then reload:
source ~/.bashrc
Now kubectl will autocomplete commands and resource names like deployments, pods, etc.
Conclusion
Managing multiple Kubernetes clusters doesn’t have to be a mess. By storing individual kubeconfigs in a folder and using the KUBECONFIG environment variable, you can switch between clusters cleanly, avoid merge conflicts, and reduce human error. Furthermore if you prefer a single kubeconfig you can automerge them with kubectl using the --flatten flag.
Adding context visibility to your shell prompt and enabling autocompletion further boosts your productivity and safety.
🙂 Happy coding!