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

61–70 of 90 posts

Re: Everything useful I know about kubectl

#61

Post by pm90 »

forestgagnon wrote: post #60
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 wrote a convoluted tool for this problem which isolates kubectl environments in docker containers: https://github.com/forestgagnon/kparanoid . This approach allows the convenience of short, context-free commands without compromising safety, because the context info in the shell prompt can be relied on, due to the isolation. There are some things which don't work well inside a docker container (port-forwarding for e…

This is really nice. I like that it doesn't munge the `kubectl` command itself.

Re: Everything useful I know about kubectl

#62

Post by pm90 »

icythere wrote: post #32
Osiris wrote: post #23

Earlier quoted context omitted.

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

I'm glad to hear that this is a more common problem. When sharing kubectl commands, I always specify the --context flag explicitly so the person using it has to manually edit the context name to whatever they are using before running it.

Re: Everything useful I know about kubectl

#63

Post by physicles »

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.…

direnv is our magic sauce for this. We enforce that all devs store the current context in an environment variable (KUBECTL_CONTEXT), and define the appropriate kubectl alias to always use that variable as the current context. To do stuff in a cluster, cd into that cluster’s directory, and direnv will automatically set the correct context. I also change prompt colors based on the current context.

(This way, the worst you can do is re-apply some yaml that should’ve already been applied in that cluster anyway)

We also have a Makefile in every directory, where the default pseudo-target is the thing you want 99% of the time anyway: kustomize build | kubectl apply -f -

Re: Everything useful I know about kubectl

#64

Post by arianvanp »

nielsole wrote: post #53

Want a crude way to see pods run on a node with the READY, STATUS and RESTARTS fields instead of the `kubectl describe node` output? kubectl get po --all-namespaces -o wide | grep $NODE_NAME Of course becomes unbearably slow, the more pods you have

You can use fieldSelector

https://stackoverflow.com/questions/39231880/kubernetes-api-...

Re: Everything useful I know about kubectl

#65

Post by busterarm »

pgwhalen wrote: post #48
busterarm wrote: post #42

Earlier quoted context omitted.

K8s is an enormously complex piece of software and I haven't met a great many people who "know" it inside and out. Basic concepts and how to write a job/service/ingress, sure. Knowing the internals and how to operate it? I'd say that's only for specialists. Most people don't need to know what a Finalizer is or does. Most people aren't going to write operators. It is a multi-year investment of time to deeply understan…

The same could be said for the linux kernel, and yet we still run all of our software on it.

Except with the kernel, you only have to be familiar with the system calls and you don't need a team of people just to run, maintain and upgrade the kernel.

That and it tries to make breaking changes on the timescale of decades rather than every other minor release (so, once or twice a year?).

Re: Everything useful I know about kubectl

#66

Post by emptysongglass »

imglorp wrote: post #10
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.

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…

We get paid because we know these tools. It's why we're desired: because the company thinks they want K8s or they're one foot in EKS and they're doubling down. We don't get hired because we dare to suggest they dismantle their pilot cluster and take a sharp turn into Nomad.

Most of us aren't the engineering heads of our departments. So you'll forgive us if we continue pushing the moneymakers we have in our heads and setting up our homelab clusters. I want to be paid, I want to be paid well. It may as well be pushing the technology stack that scales to megacorps because who knows maybe I'll make it there one day.

Re: Everything useful I know about kubectl

#67

Post by busterarm »

dmitriid wrote: post #26
nvarsj wrote: post #11

Earlier quoted context omitted.

That one has annoyed people for a long time. See https://github.com/kubernetes/kubernetes/issues/48388 . I'm pretty sure if you have the time to make a PR to fix it, it would be welcome. But I'm guessing it's non trivial or it would have been fixed by now - probably a quirk of the code generation logic.

> I'm pretty sure if you have the time to make a PR to fix it, it would be welcome. Google had a net income of $17.9 billion in just Q1 of 2021. I believe they have the resources to fix that, and I will not be shamed into "if you have time, please open a PR towards this opensource project". > But I'm guessing it's non trivial or it would have been fixed by now - probably a quirk of the code generation logic. I rememb…

Typically in my experience, the further you get away from AdWords, the more broken Google's client libraries are.

I recall a little more than half a decade ago settling on the PHP version of their Geocoding API client library for a project because it was the only one whose documentation matched how you were actually supposed to authenticate.

Re: Everything useful I know about kubectl

#68

Post by pgwhalen »

busterarm wrote: post #65
pgwhalen wrote: post #48

Earlier quoted context omitted.

The same could be said for the linux kernel, and yet we still run all of our software on it.

Except with the kernel, you only have to be familiar with the system calls and you don't need a team of people just to run, maintain and upgrade the kernel. That and it tries to make breaking changes on the timescale of decades rather than every other minor release (so, once or twice a year?).

> Except with the kernel, you only have to be familiar with the system calls

I think it's safe to assume that any non-trivial use of linux involves non-default configuration.

> you don't need a team of people just to run, maintain and upgrade the kernel.

My relatively small company employed linux admins before we adopted (on prem) kubernetes. Their work has changed a bit since since then, but it isn't meaningfully more laborious.

I assume that less effort is required for cloud kubernetes offerings.

Re: Everything useful I know about kubectl

#69

Post by xyst »

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.…

couldn't that be solved by not allowing production access to those clusters? most k8s providers should allow role based access (read/write/deploy)

Re: Everything useful I know about kubectl

#70

Post by onestone »

throwaway984393 wrote: post #40
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 a…

I simply put my apps in different namespaces on dev/stage/prod/etc. That way a kubectl command run against the wrong cluster will fail naturally.
Post reply on HN