3 ms·
A lot of people like kubectx. Or specifying contexts. Personally I hate both approaches. For the several dozen clusters that I manage, I have separate kubeconf
by busterarm 5y ago
A lot of people like kubectx. Or specifying contexts. Personally I hate both approaches.
For the several dozen clusters that I manage, I have separate kubeconfig files for each and I use the --kubeconfig flag.
It's explicit and I have visual feedback in the command I run for the cluster I'm running against, by short name. No stupidly long contexts.
- icythere 5y agoExactly! Having separate config is very easily. I had that support in my tool ;)
- kemitche 5y agoMy approach was to have a default kubeconfig for dev/QA environments, and a separate for production. I had a quick wrapper script to use the prod config file - it would set the KUBECONFIG env car to use the prod file, and update my PS1 to be red, a clear differentiator that reminds me I'm pointed at prod.