Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything useful I know about kubectl

atomiccommits.io

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Everything useful I know about kubectl

#31

Post by busterarm »

kube-system wrote: post #20
tut-urut-utut wrote: post #6

I would add one more important point about kubectl? If you don't work at Google, you don't need a complexity of kubernetes at all, so better forget everything you already know about it. The company would be grateful. Joke aside, trying to sell something to the masses that could potentially benefit only 0.001% of the projects is just insincere. Pure CV pump and dump scheme.

Kubernetes is much more simple than what we would have to do without it, and my team is much much smaller than anything at Google. For what it does, it offers some good opinions for what might otherwise be a tangle of dev ops scripts. If what you want to deploy is best described as “an application” it’s probably not the right tool for the job. If what you want to deploy is best described as “50 interconnected applica…

As someone who runs both in production, Nomad would almost certainly meet your needs.

Learning how to operate Kubernetes well takes a while and I would say is only worth the investment for a extremely tiny percentage of companies.

Re: Everything useful I know about kubectl

#32

Post by icythere »

Osiris wrote: post #23
icythere wrote: post #17

One of the issues I've often seen that my team mates send "right command" to wrong cluster and context. We have a bunch of clusters and it's always surprising to see some laptop deployments on ... production cluster. So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…

k9s is a fantastic tool. It's a CLI GUI written in go.

I used k9s before and that's an awesome tool. Tho it doesn't help when I want to send a command to my team mate and he just executes them on wrong cluster. It's the problem I want to solve

Re: Everything useful I know about kubectl

#33

Post by pchm »

icythere wrote: post #17

One of the issues I've often seen that my team mates send "right command" to wrong cluster and context. We have a bunch of clusters and it's always surprising to see some laptop deployments on ... production cluster. So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…

Agree, this is a huge pain point when dealing with multiple clusters. I wrote a wrapper for `kubectl` that displays the current context for `apply` & `delete` and prompts me to confirm the command. It's not perfect, but it's saved me a lot of trouble already — but encouraging other members of the team to have a similar setup is another story.

Here's the script (along with a bunch of extra utils): https://github.com/pch/dotfiles/blob/master/kubernetes/utils...

Re: Everything useful I know about kubectl

#34

Post by icythere »

busterarm wrote: post #30
icythere wrote: post #17

One of the issues I've often seen that my team mates send "right command" to wrong cluster and context. We have a bunch of clusters and it's always surprising to see some laptop deployments on ... production cluster. So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…

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.

Exactly! Having separate config is very easily. I had that support in my tool ;)

Re: Everything useful I know about kubectl

#35

Post by busterarm »

nvarsj wrote: post #12
imglorp wrote: post #10

Earlier quoted context omitted.

This is getting downvoted for cynicism maybe, but I feel it's the most important advice here. Know /when/ to use Kubernetes. It's very often the wrong tool to deploy our tiny app but many of us go along with it because it ticks some management boxes for various buzzwords, compliance, hipness, or whatever. Once you get out this hammer factory, it's a big and complicated one, so you will probably need a full time team…

This kind of comment is on every single HN post about Kubernetes and is tiresome. I also think it's off topic (TFA is about kubectl tricks, not about the merits of K8s).

I think it's important to have comments like those as Google, who does not use Kubernetes, is exerting a lot of pressure on the industry to adopt it. It is an extremely complicated tool to learn to use well and companies act like there aren't reasonable alternatives.

Those of us who have gone through it are often coming back with war stories saying to use something else. Some of us have invested thousands of man hours into this already and have strong opinions. At the very least, give Nomad a look. It is maybe a tenth of the effort to run for exactly the features most people want and then some.

People need to be made aware that there are options. I have friends at companies that have large teams just dedicated to managing Kubernetes and they still deal with failure frequently or they spend their entire day-to-day tuning etcd.

Re: Everything useful I know about kubectl

#36

Post by icythere »

pchm wrote: post #33
icythere wrote: post #17

One of the issues I've often seen that my team mates send "right command" to wrong cluster and context. We have a bunch of clusters and it's always surprising to see some laptop deployments on ... production cluster. So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…

Agree, this is a huge pain point when dealing with multiple clusters. I wrote a wrapper for `kubectl` that displays the current context for `apply` & `delete` and prompts me to confirm the command. It's not perfect, but it's saved me a lot of trouble already — but encouraging other members of the team to have a similar setup is another story. Here's the script (along with a bunch of extra utils): https://github.com/p…

Very valuable script. Thanks for your sharing.

Re: Everything useful I know about kubectl

#38

Post by vasergen »

In case you work a lot with k8s, you can take a look as well at k9s, hightly reccomend it. It can save a lot of time with typings, especially to quickly check what pods/deployments are running, execute command in pod, describe to understand why did it fail, change cluster / namespace and so on

Re: Everything useful I know about kubectl

#39

Post by sgarland »

busterarm wrote: post #31
kube-system wrote: post #20

Earlier quoted context omitted.

Kubernetes is much more simple than what we would have to do without it, and my team is much much smaller than anything at Google. For what it does, it offers some good opinions for what might otherwise be a tangle of dev ops scripts. If what you want to deploy is best described as “an application” it’s probably not the right tool for the job. If what you want to deploy is best described as “50 interconnected applica…

As someone who runs both in production, Nomad would almost certainly meet your needs. Learning how to operate Kubernetes well takes a while and I would say is only worth the investment for a extremely tiny percentage of companies.

Maybe, but for better or worse it's also become the industry standard, much like Terraform.

If you don't know k8s and Terraform, you're shooting yourself in the foot for future jobs.

Re: Everything useful I know about kubectl

#40

Post by throwaway984393 »

icythere wrote: post #17

One of the issues I've often seen that my team mates send "right command" to wrong cluster and context. We have a bunch of clusters and it's always surprising to see some laptop deployments on ... production cluster. So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…

I'm lazy and I don't like having to remember "the right way" to run something, so my solution is directories and wrappers. I keep a directory for every environment (dev, stage, prod, etc) for every account I manage.

  env/
      account-a/
                dev/
                stage/
                prod/
      account-b/
                dev/
                stage/
                prod/
I keep config files in each directory. I call a wrapper script, cicd.sh, to run certain commands for me. When I want to deploy to stage in account-b, I just do:

  ~ $ cd env/account-b/stage/
  ~/env/account-b/stage $ cicd.sh deploy
  cicd.sh: Deploying to account-b/stage ...
The script runs ../../../modules/deploy/main.sh and passes in configs from the current directory ("stage") and the previous directory ("account-b"). Those configs are hard-coded with all the correct variables. It's impossible for me to deploy the wrong thing to the wrong place, as long as I'm in the right directory.

I use this model to manage everything (infrastructure, services, builds, etc). This has saved my bacon a couple times; I might have my AWS credentials set up for one account (export AWS_PROFILE=prod) but trying to deploy nonprod, and the deploy immediately fails because the configs had hard-coded values that didn't match my environment.

Post reply on HN