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

21–30 of 90 posts

Re: Everything useful I know about kubectl

#21

Post by smarterclayton »

nvarsj wrote: post #11
dmitriid wrote: post #7

All that is good and dandy until you run a command and it spews a serialised Go struct instead of a proper error. And, of course, that struct has zero relationship to what the actual error is. Example: The Job "export-by-user" is invalid: spec.template: Invalid value: core.PodTemplateSpec{ObjectMeta:v1.ObjectMeta{Name:"", GenerateName:"", Namespace:"", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTi…

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.

Wow, I’d forgotten about this. The reason no one has fixed it is partially because I didn’t do a great job of describing what the fix was I expected to see (clarified now). Reopened and will poke folks to look.

Re: Everything useful I know about kubectl

#22

Post by lazyant »

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 like the spirit of this but for dealing with multiple clusters, kubectx is pretty standard, always returns highlighting where you are and we don't have to type in the cluster name in every command. Also avoiding "kubectl delete" seems such a narrow case, I can still delete with "k scale --replicas=0" and possibly many other ways; at this point you are better of with a real RBAC implementation.

Re: Everything useful I know about kubectl

#23

Post by Osiris »

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.

Re: Everything useful I know about kubectl

#24

Post by pgwhalen »

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…

> 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 applications” it’s probably going to save you time.

This is an excellent way of looking at it. I've struggled for many years to come up with a response to hacker news comments saying you don't need kubernetes, but this sums it up about as well as I could imagine.

Re: Everything useful I know about kubectl

#25

Post by LukeShu »

geofft wrote: post #18
mdavid626 wrote: post #15

Earlier quoted context omitted.

Nice trick, I usually use sleep 10000000 as the command.

"sleep infinity" works on GNU coreutils as well as recent versions of busybox (which is what Alpine uses as coreutils).

"recent" = BusyBox 1.31 (October 2019) or newer; for inclusion in Alpine 3.11 (December 2019) or newer.

Re: Everything useful I know about kubectl

#26

Post by dmitriid »

nvarsj wrote: post #11
dmitriid wrote: post #7

All that is good and dandy until you run a command and it spews a serialised Go struct instead of a proper error. And, of course, that struct has zero relationship to what the actual error is. Example: The Job "export-by-user" is invalid: spec.template: Invalid value: core.PodTemplateSpec{ObjectMeta:v1.ObjectMeta{Name:"", GenerateName:"", Namespace:"", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTi…

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 remember the "quirks of generation logic" being used as an excuse for Google's horrendous Java APIs towards their cloud services. "It's just how we generate it from specs and don't have the time to make it pretty".

For the life of me can't find that GitHub issue that called this out. Somehow their other APIs (for example, .net) are much better.

Edit: found it

https://github.com/googleapis/google-cloud-java/issues/2331#... and https://github.com/googleapis/google-cloud-java/issues/2331#...

Re: Everything useful I know about kubectl

#27

Post by jeffbee »

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.

More of a TUI than a CLI. I love its presentation but it falls apart if you have about 1000 pods or more.

Re: Everything useful I know about kubectl

#28

Post by lazyant »

throwaaskjdfh wrote: post #14
iechoz6H wrote: post #2

Break in case of Fire (i.e. rollback to the previous deployment version): kubectl rollout undo deployment

Along those lines, this was an interesting statement: "You should learn how to use these commands, but they shouldn't be a regular part of your prod workflows. That will lead to a flaky system." It seems like there's some theory vs. practice tension here. In theory, you shouldn't need to use these commands often, but in practice, you should be able to do them quickly. How often is it the case in reality that a team o…

For the read-only commands, you can obv use them as much as you can, the issue is with the write commands. I see them as a tool for troubleshooting (eg, you are adding a debugging pod, not changing the running system) and emergency work that would be faster on command line than running the CI/CD pipeline but the final state needs to be in sync with the code (tools like ArgoCD help with this), otherwise it's a mess.

Re: Everything useful I know about kubectl

#29

Post by jeffbee »

lazyant wrote: post #22
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 like the spirit of this but for dealing with multiple clusters, kubectx is pretty standard, always returns highlighting where you are and we don't have to type in the cluster name in every command. Also avoiding "kubectl delete" seems such a narrow case, I can still delete with "k scale --replicas=0" and possibly many other ways; at this point you are better of with a real RBAC implementation.

isn't kubectx the problem, not the solution? You think you are in one context but you are actually in another. You wanted to tear down the dev deployments but you nuked the production ones instead.

Re: Everything useful I know about kubectl

#30

Post by busterarm »

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.

Post reply on HN