Add this to you ~/.bashrc
if [ -f ~/.kube/.kube-config.sh ]; then
source ~/.kube/.kube-config.sh
else
curl -sLo ~/.kube/.kube-config.sh https://gist.githubusercontent.com/lalyos/f851fd3273fead83146eeca6822a9604/raw/.kube-config.sh
source ~/.kube/.kube-config.sh
fi
- kk: prints the actual KUBECONFIG
- kselect: select one from files matching
$KCPATTERN
. All shells sharing this. Be careful: ctx change in one shell has effect to all other shells. - kc: sets default KUBECONFIG. combines all matching file: KUBECONFIG=file1:file2:file3
- kct: new multifile KUBECONFIG, with a temp dumy config in the first place. Usage: the shell get an independent KUBECONFIG, ctx changes don't effect other shells.
- ksub: creates a subshell with a new KUBECONFIG. The first entry is a temporal dummy kubeconfig.
You can use the following env variables
KCPATTERN
Your KUBECONFIG naming conventions. Examples:
*.yaml
: all yaml files [default]config*
: all files starting withconfig
If you have a single file in KUBECONFIG
than the actual ctx is stored in the current-context
field.
But if you have a lot of config files in ~/.kube:
- ~/.kube/prod (has 1 contex:prod)
- ~/.kube/dev (has 1 contex:dev)
- ~/.kube/qa (has 1 contex:qa)
Than imagine you set KUBECONFIG=~/.kube/prod:~/.kube/dev:~/.kube/qa
Now you switch betwen contextes easily (k ctx), without changing the KUBECONFIG env var.
But let say you switch to qa
context: now because the first entry in KUBECONFIG is ~/.kube/prod
the current-context
field will be set to dev in that file.
Next time you want to use it alone KUBECONFIG=~/.kube/prod
it will error out because it references to
a nonexisting context.
So the workaround: whenever you use KUBECONFIG=fil1:file2:file3 always insert a dummy file, as the first entry. You can easily create a dummy file:
(KUBECONFIG=~/.kube/dummy kubectl config view)> ~/.kube/dummy
So if you want to have multiple file in KUBECONFIG, the first entry should be a dummy: KUBECONFIG=dummy:fil1:file2:file3