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

11–20 of 90 posts

Re: Everything useful I know about kubectl

#11

Post by nvarsj »

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.

Re: Everything useful I know about kubectl

#12

Post by nvarsj »

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…

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

Re: Everything useful I know about kubectl

#13

Post by theden »

One useful debugging trick I use often is to edit a deployment or pod via `kubectl edit` and update the command to be `tail -f /dev/null`

e.g.,

    spec:
      containers:
      - command:
        - bash
        - -c
        - tail -f /dev/null
(and comment out any liveness or readiness probes)

Very useful to then `exec` with a shell in the pod debug things or test out different configs quickly, check the environment etc.

Re: Everything useful I know about kubectl

#14

Post by throwaaskjdfh »

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 of Kubernetes superheroes, well versed in these commands, is necessary to make Continuous Integration and/or Continuous Deployment work?

Re: Everything useful I know about kubectl

#15

Post by mdavid626 »

theden wrote: post #13

One useful debugging trick I use often is to edit a deployment or pod via `kubectl edit` and update the command to be `tail -f /dev/null` e.g., spec: containers: - command: - bash - -c - tail -f /dev/null (and comment out any liveness or readiness probes) Very useful to then `exec` with a shell in the pod debug things or test out different configs quickly, check the environment etc.

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

Re: Everything useful I know about kubectl

#16

Post by seneca »

alek_m wrote: post #3

Every time I'm starting a new service to run internally or reviewing something we have going, I find myself struggling to find the right instance type for the needs. For instance, there are three families (r, x, z) that optimize RAM in various ways in various combinations and I always forget about the x and z variants. So I put together this "cheat sheet" for us internally and thought I'd share it for anyone interest…

It seems this may have been posted on the wrong article, as it's completely unrelated to the topic.

Re: Everything useful I know about kubectl

#17

Post by icythere »

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.

Edit: Fix typo err0rs

Re: Everything useful I know about kubectl

#18

Post by geofft »

mdavid626 wrote: post #15
theden wrote: post #13

One useful debugging trick I use often is to edit a deployment or pod via `kubectl edit` and update the command to be `tail -f /dev/null` e.g., spec: containers: - command: - bash - -c - tail -f /dev/null (and comment out any liveness or readiness probes) Very useful to then `exec` with a shell in the pod debug things or test out different configs quickly, check the environment etc.

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

Re: Everything useful I know about kubectl

#19

Post by lazyant »

nsxwolf wrote: post #8

I’d love to know the easiest way to answer this question: “what IP address and port is the microservice pod the CI server just deployed listening on?”

For the port is trivial: `kubectl get pod --output jsonpath={.spec.ports[*].port}` or if you don't remember the json path just `k get pod |grep Port`.

For the IP address, why do you need that? with k8s dns you can easily find anything by name.

Re: Everything useful I know about kubectl

#20

Post by kube-system »

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

Post reply on HN