4 ms·

I’m a little confused, what would the alternative be?

• kobalsky 6y ago
  What I have been doing is a directory per namespace/context. I have a common Makefile that I link there which creates the namespace and does all the basic initialization stuff like inserting deny-all netpol rules, credentials for our docker registry. It also runs a puppet task that creates scripts to use kubectl and helm with the correct context. An optional config file let's me change the defaults, like pointing it to a different cluster. I also keep context specific notes and files, scripts, etc. in this directory. Everything under version control, except for the autogenerated stuff. For normal usage I always just run ./kubectl.sh. I switch between contexts by changing directories and the commands to get pods and talk with the cluster don't change. I just go nuts with ctrl+r. I also can run commands on different contexts easily, lets me pipe the output from one context into another just running: namespace1/kubectl.sh exec ... | namespace2/kubectl2.sh run ... namespace1/mysqldump.sh mydb | namespace2/mysql.sh myotherdb Each kubectl.sh points to the correct version of kubectl for each cluster, so you don't get weird kubectl errors from mixing stable clusters with more modern ones. The config file being a puppet script is a very powerful tool. I use it to for example generate the config files for our software and the yaml files for helm. Also for doing the vendor specific stuff like allocating volumes, ips and configuring DNS servers.
• nunez 6y ago
  I would love to use environment variables, like this: KUBE_APISERVER_ADDR=https://foo.com https://foo.com KUBE_CERT_FILE=/tmp/cert KUBE_NAMESPACE=bar kubectl get po This way, I can export them into my environment with my .bash_profile instead of having to persist state just to perform cluster ops