4 ms·

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 comm

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.

cyberpunk 2y ago
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.
lukaslalinsky 2y ago
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.
- vdm 2y ago
  This is the way. Same for awscli profiles.
- cryptonector 2y ago
  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.
physicles 2y ago
Check out direnv, and use a shell alias for kubectl. And yeah, current context is evil.
- 8organicbits 2y ago
  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.
  - physicles 2y ago
    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.
- remram 2y ago
  What if you have dev and prod clusters/namespaces for the same project (and thus directory)?
  - physicles 2y ago
    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.
remram 2y ago
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.
Telemaco019 2y ago
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 :)
rad_gruchalski 2y ago
I just print the current context in my shell, next to the git branch.

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.

cyberpunk 2y ago

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.

lukaslalinsky 2y ago

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.

vdm 2y ago
This is the way. Same for awscli profiles.
cryptonector 2y ago
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.

physicles 2y ago

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

8organicbits 2y ago
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.
- physicles 2y ago
  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.
remram 2y ago
What if you have dev and prod clusters/namespaces for the same project (and thus directory)?
- physicles 2y ago
  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.

remram 2y ago

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.

Telemaco019 2y ago

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 :)

rad_gruchalski 2y ago

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