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

111–120 of 183 posts

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

#111

Post by chuckadams »

drdaeman wrote: post #87

They have built an orchestrator, not Kubernetes. There is one key difference: they know this thing, end-to-end, down to every single bolt and piece of duct tape (with possible exception for Docker internals) And that's a very important distinction when it comes to maintaining complex systems. This could've changed with LLMs (I'm still adjusting to what new capabilities mean for various decision-making logic), but bef…

And chances are only they know it. If my role has enough cluster access, I can muddle through pretty much any helm chart (with lots of cursing, yes) but it might take me days to set up whatever elaborate bespoke environment and script invocations are needed to replicate the current production setup maybe.

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

#112

Post by shrubble »

throwaway041207 wrote: post #90
shrubble wrote: post #58

I can tell you how vendors deliver a software solution that runs on Kubernetes: very poorly. The needed tweaks, the ability to customize things, basically goes to zero because the support staff is technical about the software, but NOT about Kubernetes. I am not joking: a recent deployment required 3x VMs for Kubernetes, each VM having 256 gigabytes of RAM; then a separate 3x VMs for a different piece. 1.5TB of RAM to…

Whether this is deployed via Helm charts or a native controller, there's almost certainly some overlay where you can override resource values, unless this is just a very crappy vendor.

The setting is there, somewhere, I agree; but no one can tell you how to change it or what the implications might be.

So unless I want to dig into their YAML files that are not documented…

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

#113

Post by xyzzy_plugh »

ohNoe5 wrote: post #110
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…

Ephemeral user accounts were agreed upon before that. The OG container Docker and k8s are just wrappers around namespaces, cgroups, file system ACLs, some essential cli commands, which can also be configured per user. We may be headed back there. Have seen some experiments leveraging Linux kernels BPF and sched_ext to fire off just the right sized compute schedule in response to sequences of specific BPF events. Futu…

Something often underappreciated is that, in the possible future you're describing, you can use all of these new fangled "what's old is new again" approaches by continuing to just use Kubernetes. Kubernetes is, in a way, designed to replace itself.

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

#114

Post by 28304283409234 »

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…

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.

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

#116

Post by Havoc »

Literally just finished building a personal orchestrator system I wanted and had this very much in back of my mind.

Ended up doing a mix. Built on compose for now but in a manner that’ll lift and shift to k8s easily enough. Its containers talking over network either way

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

#117

Post by Havoc »

blindlobstar wrote: post #43

Why both posts mention docker compose and not mentioning docker swarm. Being using it for my projects for long time. And it's so nice. Similar syntax, easy networking, rollout strategy, easy to add nodes to cluster. You can have one template docker-compose.yaml file and separate deployment files for different envs, like: docker-compose.dev.yaml, docker-compose.prod.yaml I think swarm is really underrated

It’s in a death spiral - not widely used so people aren’t incentivised to put time into it so not widely used

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

#118

Post by 0xbadcafebee »

srcreigh wrote: post #17
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.

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

There are a multitude of cases of operations which need to be performed before and after specific actions in K8s. It depends on the resource, operator, operational changes, state, bugs, order of operations, and more.

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

#120

Post by 0xbadcafebee »

whynotmaybe wrote: post #9

I need clarifications. I see docker as a way to avoid having a standard dev platform for everyone in the company so that the infra team don't have to worry about patch xyz for library abc, only run docker. But, with all the effort put in place to coordinate docker, k8s and all the shebang, isn't it finally easier to force a platform and let it slowly evolve over time? Is docker another technical tool that tries to so…

Docker is a solution to one specific problem: the need for "a user" to run 10 different potentially conflicting apps, all at the same time, on one machine, and abstract away anything which might make those apps conflict if they ran on a single OS. It provides a dozen different solutions in one package.

K8s is a way to take that and make it scale up for a large number of applications on a large number of hosts in a production business in a way that's automated and resilient to failure.

Post reply on HN