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

41–50 of 90 posts

Re: Everything useful I know about kubectl

#41

Post by cfors »

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

Not a perfect solution but I add a prompt signaling both my current namespace and cluster, along with some safeguards for any changes on our production environment. In practice I haven't deployed something wrongfully in production ever.

I use a custom written script but I've used this one in the past - its pretty nice.

https://github.com/jonmosco/kube-ps1/blob/master/kube-ps1.sh

Re: Everything useful I know about kubectl

#42

Post by busterarm »

sgarland wrote: post #39
busterarm wrote: post #31

Earlier quoted context omitted.

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.

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 understand this tool and it's not necessary for everyone.

Re: Everything useful I know about kubectl

#43

Post by kube-system »

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 so, but anyone should definitely use more criteria than my few word generalization to choose their deployment infrastructure. :)

We (mostly) chose k8s over other solutions because of other tools/providers in the ecosystem that made business sense for us. But we did need something to abstract our deployment complexity.

I’m mostly suggesting that I suspect many of the people with bad k8s experience didn’t really need it.

I’ve seen a number of people wrap a simple application in a container, slap it in a deployment/service/ingress and call it a day, it works, but using k8s that way doesn’t really add much value.

Re: Everything useful I know about kubectl

#44

Post by namelosw »

I have been using kubectl + zsh for quite a while.

But now my choice is Intellij (or other IDEs from JetBrains) + Lens, which I find more productive and straightforward (more GUI, fewer commands to memorize). Here's my setup and workflow:

1. For each repository, I put the Kubernetes deployment, service configurations, etc. in the same directory. I open and edit them with Intellij.

2. There's also a centralized repository for Ingress, Certificate, Helm charts, etc. I also open with Intellij. Spend some time to organize Kubernetes configs really worth it. I'm working with multiple projects and the configs gets overwhelming very quickly.

3. Set shortcuts for applying and deleting Kubernetes resources for current configs for Intellij. So I can create, edit, and delete resources in a blink.

4. There's a Kubernetes panel in Intellij for basic monitoring and operations.

5. For more information and operations, I would use Lens instead of Intellij. The operations are very straightforward, I can navigate back and forth, tweak configurations much faster than I could with the shell command only.

Re: Everything useful I know about kubectl

#45

Post by kemitche »

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.

My approach was to have a default kubeconfig for dev/QA environments, and a separate for production. I had a quick wrapper script to use the prod config file - it would set the KUBECONFIG env car to use the prod file, and update my PS1 to be red, a clear differentiator that reminds me I'm pointed at prod.

Re: Everything useful I know about kubectl

#47

Post by [deleted] »

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…

[deleted]

Re: Everything useful I know about kubectl

#48

Post by pgwhalen »

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…

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

Re: Everything useful I know about kubectl

#50

Post by majewsky »

cfors wrote: post #41
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.…

Not a perfect solution but I add a prompt signaling both my current namespace and cluster, along with some safeguards for any changes on our production environment. In practice I haven't deployed something wrongfully in production ever. I use a custom written script but I've used this one in the past - its pretty nice. https://github.com/jonmosco/kube-ps1/blob/master/kube-ps1.sh

I have a prompt display as well, but to my own dismay, earlier that year, I applied some QA config to a prod system. (It did not cause substantial harm, thankfully.) After that, I changed my prompt display so that names of productive regions are highlighted with red background. That seems to really help in situations of diminished attentiveness from what I can tell.
Post reply on HN