Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear friend, you have built a Kubernetes (2024)

macchaffee.com

Post reply on HN
Print view View original

161–170 of 183 posts

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

#161

Post by esseph »

zmmmmm wrote: post #105
cortesoft wrote: post #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 diffe…

> all of those choices have been made and agreed upon Have they really? I have a few apps deployed on k8s and I feel like every time I need something, it turns out it doesn't do that and I'm into some exotic extension or plugin type ecosystem. Something as simple as service autoscaling (this was a few years ago) was an adventure into DIY. Moving from google cloud to AWS was a complete writeoff almost - just build it…

> Moving from google cloud to AWS was a complete writeoff almost - just build it again.

Yep. Kubernetes is not just kubernetes when moving between clouds, it becomes a very opinionated product (for better or worse) with lots of vendor addons. Could someone that is familiar with one pick up on the other? Sure! But there are gotchas. And then kubernetes on prem adds the hardware lifecycle piece, and potential data locality issues, etc.

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

#163

Post by a456463 »

cassianoleal wrote: post #6
et1337 wrote: 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.

This is why we don't take advice from randos on internet.

I manage 100+ variations on a single helm chart and 50+ such helm charts at work daily for 7 years across 11 datacenters/kubernetes clusters. And I have team members who swear by kustomize. The number of kustomize typo errors and issues that I have deal with is unimaginable. Whereas if I test and deploy a helm chart, I know it will work everywhere in every variation.

Kustomize is just plain terrible and backwards as a solution. It doesn't scale, it is half assed. It tries to basically require you to build your own compiler and parser and transform. With kustomize + envsubst: dear friend, you have built helm.

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

#164

Post by a456463 »

antonvs wrote: post #153
cassianoleal wrote: post #81

Earlier quoted context omitted.

That's my main gripe with Helm. For the simple use case you're describing, Helm is not required. Plenty of other solutions around. For use cases where it starts getting useful, we both agree that something has gone terribly wrong. I still don't know why Helm exists. It's a solution that created lots of problems that didn't exist.

My personal theory is that Helm may be ok for distributing a pre-packaged solution to other people. Then people mistook it for a tool that should be used in-house to deploy a company’s own systems, where it makes much less sense.

It makes absolute sense. You can use no variables and still deploy helm chart. It is a directory of plain old yaml objects. And add customization when you need as you evolve. Good luck doing that with kustomize.

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

#165

Post by a456463 »

supriyo-biswas wrote: post #14
cassianoleal wrote: post #6

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.

This is a BS claim with no proof. This is the strength of helm.

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

#166

Post by turtlebits »

jstanley wrote: post #5

> I know you wanted to "choose boring tech" to just run some containers. The people advocating for boring tech generally aren't interested in containers. You can just run programs.

The problem is that running programs isn't always trivial.

I have no interest in going back to the hell that is deploying a java app.

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

#167

Post by turtlebits »

et1337 wrote: 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…

skaffold. It'll also wait for rollout to stabilize.

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

#168

Post by 0x457 »

jurgenburgen wrote: post #134
0x457 wrote: post #99

Earlier quoted context omitted.

Ingress resource is bassicaly "implementation specific" and isn't portable. It's not deprecated now, but there plans to retire ingress-nginx: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retireme... Anyway, Ingress resource been in "Migrate to Gateway" state for awhile.

> but there plans to retire ingress-nginx To clarify, it’s already retired and the repo has been archived since 24th of March.

Mentally, I'm still in January. For some reason the fact that March 24th, 2026 already passed didn't click in my head.

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

#169

Post by antonvs »

a456463 wrote: post #164
antonvs wrote: post #153

Earlier quoted context omitted.

My personal theory is that Helm may be ok for distributing a pre-packaged solution to other people. Then people mistook it for a tool that should be used in-house to deploy a company’s own systems, where it makes much less sense.

It makes absolute sense. You can use no variables and still deploy helm chart. It is a directory of plain old yaml objects. And add customization when you need as you evolve. Good luck doing that with kustomize.

> And add customization when you need as you evolve.

Using one of the most horrible templating languages since ASP. Helm is what happens when a devops team decides to yolo into software development.

What's the issue with kustomize? It works well for us.

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

#170

Post by physicles »

esseph wrote: post #161
zmmmmm wrote: post #105

Earlier quoted context omitted.

> all of those choices have been made and agreed upon Have they really? I have a few apps deployed on k8s and I feel like every time I need something, it turns out it doesn't do that and I'm into some exotic extension or plugin type ecosystem. Something as simple as service autoscaling (this was a few years ago) was an adventure into DIY. Moving from google cloud to AWS was a complete writeoff almost - just build it…

> Moving from google cloud to AWS was a complete writeoff almost - just build it again. Yep. Kubernetes is not just kubernetes when moving between clouds, it becomes a very opinionated product (for better or worse) with lots of vendor addons. Could someone that is familiar with one pick up on the other? Sure! But there are gotchas. And then kubernetes on prem adds the hardware lifecycle piece, and potential data loca…

There are differences across vendors, but there’s a way to build with k8s where the benefit far outweighs the cost.

We run a bunch of services in two very different cloud vendors (one of which used to be DIYed with kubeadm), and also on dev machines with k3s. Takes a while to figure this out and to draw the kustomize boundaries in the right place, but once you do, it’s actually really nice.

Two things work in our favor:

- we’ve been at this for around 8 years, so we didn’t have to deal with all the gotchas at once

- we aggressively avoid tech that isn’t universal (so S3 is OK, but SQS or DynamoDB is not; use haproxy instead of ingress controllers; etc)

Post reply on HN