Hacker News Reader

Comment by ed_mercer | Hacker News Reader

I got burned by this recently and came to the conclusion that the concept of a current context is evil. Now I always specify —-context when running kubectl commands.

View on HN

I also got burned by this, pretty badly, and ever since it happened, I don't even have a default kubeconfig, have to specify it for every single kubectl run.

This is the way. Same for awscli profiles.

I never even set up a default context. I sussed out that problem from the get-go and always use `--context`. But that's not really enough if you use shell history, or if your clusters differ in few letters that are easy to typo.

Got burned too, we've all been there I guess :)

I also tried to avoid current context initially, but it just slowed me down. Switching between clusters is so much easier with the current context and kubectx.

That’s why I built kubesafe. In this way I can keep using the current context without worrying about screwing up. If I accidentally target the wrong context, at least I get a warning before executing the command.

The only hassle now is remembering to add new prod contexts to the safe list, but that’s about to change with regex support coming soon :)

I actually go a step further and keep multiple kubeconfigs and have a load of shell aliases for managing them.

Active one is in $PS1 somewhere.

I found that some cloud providers and other tools like minikube don't play nice with other clusters in the same config. I now use a tiny shell function that selects KUBECONFIG out of a folder, and adds the current cluster name's to my prompt.

Check out direnv, and use a shell alias for kubectl. And yeah, current context is evil.

This is a good suggestion, but keep in mind that you can accidentally run a command in the wrong directory. I've certainly done that too, with painful results.

What kind of command was it?

If I’m doing something more involved, I’ve got a k9s window open in another pane, making sure the command is having the intended effect.

I guess the riskiest commands would be things like deleting persistent volumes. But our storage class doesn’t automatically clean up the disk in the cloud provider, so we could recover from that too.

What if you have dev and prod clusters/namespaces for the same project (and thus directory)?

We’ve avoided that situation with kustomize. Common resources go into a ‘bases’ directory, and if two clusters have identical resources, then they both have their own directories and reference all the base resources from there.

In practice, there are always slight differences between cluster config between test and prod (using different S3 buckets, for example) so this is needed anyway.

I just print the current context in my shell, next to the git branch.

Reply on news.ycombinator.com