Everything useful I know about kubectl • Hacker News Board

Re: Everything useful I know about kubectl

#51

Post by 0xEFF » Mon, Jul 05, 2021, 6:15 PM UTC

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…

Modern istio provides a lot of value to a single application. mTLS security, telemetry, circuit breaking, canary deployments, and better external authentication and authorization. I’ve seen each done so many different ways. Nice to do it once at the mesh layer and have it be done for everything inside the cluster.

Re: Everything useful I know about kubectl

#52

Post by alexhwoods » Mon, Jul 05, 2021, 6:20 PM UTC

bobbyi_settv wrote: post #49

How is this command from the page: # Lint a Helm chart # Good to put in pre-merge checks $ helm template . | kubeval - different/ better than "helm lint" ( https://helm.sh/docs/helm/helm_lint/ )?

I could be wrong here, but I think `helm lint` just checks that the chart is formed correctly — Go templating and all.

I don't think it validates the Kubernetes resources.

Here's an example:

$ helm create foo

$ cd foo

Then change "apiVersion" in deployment.yaml to "apiVersion: nonsense"

In the linting, I got

$ helm lint ==> Linting . [INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

$ helm template . | kubeval -

ERR - foo/templates/deployment.yaml: Failed initializing schema https://kubernetesjsonschema.dev/master-standalone/deploymen...: Could not read schema from HTTP, response status is 404 Not Found

Re: Everything useful I know about kubectl

#53

Post by nielsole » Mon, Jul 05, 2021, 6:25 PM UTC

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

Re: Everything useful I know about kubectl

#54

Post by alexhwoods » Mon, Jul 05, 2021, 6:30 PM UTC

busterarm wrote: post #42

sgarland wrote: post #39

Earlier quoted context omitted.

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.

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…

Agreed. I think overtime we'll just get more abstracted away from it. GKE Autopilot, for example.

I think you still have to understand the lego block in your hand though, so you can combine it well with the other parts of your system.

Re: Everything useful I know about kubectl

#55

Post by iechoz6H » Mon, Jul 05, 2021, 6:47 PM UTC

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

We partially resolve this by having different namespaces in each of our environments. Nothing is ever run in the 'default' namespace.

So if we think we're targeting the dev cluster and run 'kubectl -n dev-namespace delete deployment service-deployment' but our current context is actually pointing to prod then we trigger an error as there is no 'dev-namespace' in prod.

Obviously we can associate specific namespaces to contexts to traverse this safety net but it can help in some situations.

Re: Everything useful I know about kubectl

#56

Post by dmitryminkovsky » Mon, Jul 05, 2021, 6:58 PM UTC

Nice list. Learned a couple neat things. Thank you!

Would like to add that my favorite under-appreciated can't-live-without kubectl tool is `kubectl port-forward`. So nice being able to easily open a port on localhost to any port in any container without manipulating ingress and potentially compromising security.

Re: Everything useful I know about kubectl

#57

Post by ithkuil » Mon, Jul 05, 2021, 7:00 PM UTC

dmitryminkovsky wrote: post #56

Nice list. Learned a couple neat things. Thank you! Would like to add that my favorite under-appreciated can't-live-without kubectl tool is `kubectl port-forward`. So nice being able to easily open a port on localhost to any port in any container without manipulating ingress and potentially compromising security.

Not only containers, it can also forward services!

Re: Everything useful I know about kubectl

#58

Post by [deleted] » Mon, Jul 05, 2021, 7:05 PM UTC

ithkuil wrote: post #57

dmitryminkovsky wrote: post #56

Nice list. Learned a couple neat things. Thank you! Would like to add that my favorite under-appreciated can't-live-without kubectl tool is `kubectl port-forward`. So nice being able to easily open a port on localhost to any port in any container without manipulating ingress and potentially compromising security.

Not only containers, it can also forward services!

[deleted]

Re: Everything useful I know about kubectl

#59

Post by birdyrooster » Mon, Jul 05, 2021, 7:23 PM UTC

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

Create a User/Role for deleting (or whatever dangerous action) resources in prod cluster/namespace. Setup RBAC which allows your employees to impersonate as that user/role using kubectl --as. This way if you send your coworkers a command for dev environment and they try to run it in prod it will fail because they didn’t run kubectl as that impersonated user.

Re: Everything useful I know about kubectl

#60

Post by forestgagnon » Mon, Jul 05, 2021, 7:37 PM UTC

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 example), but it does make it simple to have isolated shell history, specific kubectl versions, etc.