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

151–160 of 183 posts

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

#151

Post by physicsguy »

zdw wrote: post #2

IMO, Kubernetes isn't inevitable, and this seems to paint it as such. K8s is well suited to dynamically scaling a SaaS product delivered over the web. When you get outside this scenario - for example, on-prem or single node "clusters" that are running K8s just for API compatibility, it seems like either overkill or a bad choice. Even when cloud deployed, K8s mostly functions as a batteries-not-included wrapper around…

It's also difficult for data pipelines or data intensive things. At several companies we've run into the "Need to put ML model behind API and pods get killed because health checks via API are basically not compatible with container fully under load but still working"

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

#153

Post by antonvs »

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

Earlier quoted context omitted.

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.

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.

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

#154

Post by antonvs »

waterTanuki wrote: post #104

I'll just say the quiet part out loud: A pile of shell scripts that no one else understands is job security. If your work is easily googleable/parseable by an AI, why would anyone pay you?

I worked with a guy who fits this description. If there’s something he can reinvent poorly, he’d do it. A big part of what I did while working on the same team as him was slowly chipping away at his weird domain by introducing standard tools. I always had to advocate for them in such a way that they were solving a different problem, and then slowly work towards a point where some of his homegrown stuff became unnecessary.

As to the job security idea: the only people who do this are people who aren’t good at creating real value, so they have to try to create niches where they’re needed.

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

#155

Post by chuckadams »

physicsguy wrote: post #150
chuckadams wrote: post #109

Earlier quoted context omitted.

Ingress is frozen, not deprecated. Gateway does more, but Ingress isn’t going anywhere. It’s a stable API, which is the opposite of churn.

Til there's a security issue, right? Nginx is a big target.

The API of Ingress is not Nginx's API. The spec itself is basically a yaml schema, it's hard to have a vulnerability in that.

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

#156

Post by chillfox »

turtlebits wrote: post #136
chillfox wrote: post #126

Earlier quoted context omitted.

lol, the big problem with kubernetes is that none of the choices have been made, it's not opinionated at all, there's no conventions. It's all configuration and choices all the way down. There's way too much yaml, and way to many choices for ever tiny component, it's just too much. I do run a k3s cluster for home stuff... But I really wish I could get what it provides in a much simpler solution. My dream solution wou…

You're going to have to write some sort of config. It not being opinionated it a good thing. It lets you deploy just about anything under the sun.

Well... we have k8s for that... I do not wish to take k8s away from those who like it, I am asking for a new solution that's very opinionated, and as close to zero config as practical.

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

#157

Post by quadruple »

analyte123 wrote: post #125
28304283409234 wrote: post #114

Earlier quoted context omitted.

Kubernetes is a complicated solution to a complicated problem. A lot of companies have different problems and should look for different solutions. But if you are facing this particular problem, Kubernetes is the way to go. The trick is to understand which problem you are facing.

Kubernetes can be a sign that are you making things more complicated than they should be, too early. But if you actually have made things complicated enough (whether through essential or accidental complexity) that you have problems that k8s is good at solving, I really hope you have it instead of some hand rolled solution. I feel the same way about commercial APM tools. Obviously in a perfect world, you would have s…

> But if you actually have made things complicated enough [...]

The only problem I see in this case is that complexity doesn't come all at once. By the time you reach a problem that k8s is good at solving, you've probably already accidentally made a k8s alongside your piece of software.

In my(quite short) SWE career, I've seen software evolve, even ones with a proper design stage. Maybe I just don't have enough experience to have seen a properly designed project, but I don't know what I don't know after all.

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

#158

Post by SOLAR_FIELDS »

ablob wrote: post #37
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…

I just feel like "you can do this with Kubernetes" is a slippery slope. "You can do X with Y, so use Y" is a great way to add a dependency, especially if it is "community vetted" already. Sometimes simple is better - you don't need to add anything that implements some of you logic as a dependency to stay DRY or whatever you want to call it. It really feels like we are drowning in self-imposed tech debt and keep addin…

The thing about Kubernetes is its a standardization of deployment. Kubernetes is complicated because deploying software is complicated. You might try to YAGNI hand wave it away, but as the article points out, over time, you end up building Kubernetes anyway

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

#159

Post by SOLAR_FIELDS »

cortesoft wrote: post #76
throwawaypath wrote: post #53

Earlier quoted context omitted.

>And portable. This made me audibly guffaw. Kubernetes is a lot of things, but "portable" is not one of them. GKE, EKS, AKS, OCP, etc., portability between them is nowhere near guaranteed.

It is if you stick to standard Kubernetes resources, and it has gotten even easier with better storage class and load balancer support. All of the cloud providers now give you default storage classes and ingresses when you provision a cluster on them, so you can use the exact same deployment on any of them an automatically get those things provisioned in the right way out of the box.

I'm a Kubernetes user and advocate but to call it "portable" just tells me you've never actually tried to deploy the similar thing on multiple different clouds. Even the standardized kubernetes resources behave differently due to various cloud idiosyncracies. You can of course make the situation easier, but to call it entirely portable is probably a misnomer.

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

#160

Post by SOLAR_FIELDS »

chuckadams wrote: post #109
throwawaypath wrote: post #79

Earlier quoted context omitted.

>It is if you stick to standard Kubernetes resources "If you stick to standard C..." No one does, that's the issue. Helm charts that only support certain cloud providers, operators and annotations that end up being platform specific, etc. >now give you default storage classes and ingresses Ingress is being deprecated, it's Gateway now! Welcome to hell, er, Kubernetes.

Ingress is frozen, not deprecated. Gateway does more, but Ingress isn’t going anywhere. It’s a stable API, which is the opposite of churn.

Would love to use Gateway! Every time I spin up a new cluster it goes like this:

- New cluster setup, time to use gateway! Yay!

- Oh crap, like 80% of the helm chart and other existing configurations I need for the softwares I'm trying to deploy STILL doesn't use gateway, this new API that's been out for... like half a decade at least.

- Even core networking things like Istio/Envoy only have limited gateway support compared to ingress

- Sigh. Ingress again.

It's been like this since gateway's inception and every time I check the needle has moved like 2% towards gateway. So I'm looking forward to year 2050 when I can use gateway!

The problem, as CNCF knows, if they pushed Gateway and deprecated ingress the world would revolt due to the amount of work involved to migrate stuff. Therefore, they leave it up to "the people" to do the extra work themselves, who have no incentive to do so since for many usecases it's not materially better.

Post reply on HN