Live data from Hacker News

Dear friend, you have built a Kubernetes (2024)

macchaffee.com

11–20 of 183 posts

Re: Dear friend, you have built a Kubernetes (2024)

#11
This is obviously slightly exaggerated, but I do feel like this whenever people dismiss Kubernetes as either too complicated or not needed.

The response I always got when suggesting Kubernetes is "you can do all those things without Kubernetes"

Sure, of course. There are a million different ways to do everything Kubernetes does, and some of them might be simpler or fit your use case more perfectly. You can make different decisions for each choice Kubernetes makes, and maybe your decisions are more perfect for your workload.

However, the big win with Kubernetes is that all of those choices have been made and agreed upon, and now you have an entire ecosystem of tools, expertise, blog posts, AI knowledge, etc, that knows the choices Kubernetes made and can interface with that. This is VERY powerful.

Re: Dear friend, you have built a Kubernetes (2024)

#12
post #4

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

And if you want your Helm to run on certain deploys, and maintain a declarative set of the variables given to charts over time, thinking you can use Helmfile and some custom GitHub Actions… “my dear friend you have built a GitOps.”

(I tend to think this one is acceptable in the beginning, but certainly doesn’t scale.)

Re: Dear friend, you have built a Kubernetes (2024)

#14
post #4

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

I have been using Kubernetes for 7 or 8 years now, and have nearly 100% stayed away from Helm. Some Kustomize, a little bit of envsubst and we're good to go thank you very much.

How do you handle cleanups and hooks? The best way to do helm, at least for me, seems to be about limiting its use to simple templating use cases; if you end up needing an if, you've probably done something terribly wrong.

Re: Dear friend, you have built a Kubernetes (2024)

#15

Criticisms of Kubernetes generally come from a few places: - People who would prefer their way of doing this, whether that's deployments on VMs, or use some sort of simpler cloud provider. I had the same opinion a few years ago, but have kind of come to like it, because I can cleanly deploy multiple applications on a cluster in a declarative fashion. I still don't buy the "everything on K8s", and my personal setup is…

Another case: People who want to run workloads that are inherently incompatible with Kubernetes networking model.

For example:

* For some cursed reasons you want to make sure every single one instance of a large batch job see just one NIC in its container and they are all the same IP and you NAT to the outside world. Ingress? What ingress? This is a batch job!

* Like the previous point, except that your "batch job" somehow has multiple containers in one instance now, and they should be able to reach each other by domain.

Re: Dear friend, you have built a Kubernetes (2024)

#17

Earlier quoted context omitted.

I have been using Kubernetes for 7 or 8 years now, and have nearly 100% stayed away from Helm. Some Kustomize, a little bit of envsubst and we're good to go thank you very much.

How do you handle cleanups and hooks? The best way to do helm, at least for me, seems to be about limiting its use to simple templating use cases; if you end up needing an if, you've probably done something terribly wrong.

Seems to be a case of the XY problem. What do you need cleanups and hooks for?

Re: Dear friend, you have built a Kubernetes (2024)

#18
post #4

The saddest part about Kubernetes is… after you set it all up, you still need a hacky deploy.sh to sed in the image tag to deploy! And pretty soon you’re back to “my dear friend you have built a Helm”. And so the configuration clock continues ticking…

I have been using Kubernetes for 7 or 8 years now, and have nearly 100% stayed away from Helm. Some Kustomize, a little bit of envsubst and we're good to go thank you very much.

Going on 10 years now for me, tried Helm a bit and yep - all I've really needed was a package.json deploy script with sed to bump the image version.
Post reply on HN