Hacker News Reader

Comment by rsanheim | Hacker News Reader

I'm sure all this complexity makes sense for all sorts of reasons buried in the history of Kubernetes development at Google. "Things are the way they are because they got that way."

The fact that so many other orgs, many of which are startups or just small to medium sized tech companies, use a system this complex is ludicrous to me.

View on HN

Hi! Small tech company that uses k8s here. Much of the complexity is irreducible and has to go somewhere, and it's much better to have it in a single, stateless, well-defined place that's also easy too introspect.

I've seen way too many Ansible nightmares grown out of deceptively "simple" mutable VM deployments.

k8s makes our life so much easier because it eliminates a whole bunch of other complexity. Easily reproducible development environments, workload scheduling, sane config management...

My favorite opposite of this is companies running k8s, using a ansible to build state on launch..

The practical change that's happening is that in future versions of Kubernetes, they're removing support for using a shim for telling the Docker daemon to run containers, and focusing on just using containerd (which Docker uses under the covers anyway).

It's kind of like if you had a shell script to launch programs, and it used to move the mouse to press icons, but now you've deprecated that and will only run programs directly.

Well, I might have designed it differently, but I wasn't there. For what it does, this architecture works well. More to the point: none of it is visible to end-users of Kubernetes. You send a Pod definition, some magic happens, pow! running software.

Except when it doesn't, at which point you're lost.

Well, like I said, I might have done it differently. But there's a consistent logic to how it works[0]. That carries a lot of water.

[0] most folks emphasise the control loop aspect, I think it's more helpful to point to blackboard / tuple-space systems as prior art.

> I think it's more helpful to point to blackboard / tuple-space systems as prior art

Ah, nevermind then, that gives me rest concerning the viability and transparency of it all.

I'm glad I could help.

It's a generic API for automated provisioning. It asks you to make some decisions up front (what do you want to do when an instance goes down or has a new version available), and lets you forgo making some (like which nodes your instance should run on).

It's not more complex. If you're small, the overhead is probably not worth it. If you're big enough, you manage the k8s control plane, and you don't have to manage your tenants infra.

Is a programming language too complex for hello world? Perhaps, but that's not all it does.

You don't need the complexity until you do, and then you're facing a rewrite into the complex system. Defining a deployment in YAML isn't really all that hard.

Reply on news.ycombinator.com