Comment by jrs95 | Hacker News Reader

Comment by jrs95 | Hacker News Reader

Parent Full thread

The complexity of Kubernetes largely reflects the complexity of the problem. Nobody has delivered anything significantly simpler that hasn’t had a much smaller scope, and those tools approach the same level of complexity when composed with others to get the same level of functionality. But setting up Kubernetes is both well documented and automated on multiple cloud providers, whereas something like Nomad & Consul doesn’t really have a good end to end walk through to get you to the same destination as Kubernetes. I suppose if you’re fine with pushing that complexity into service clients you can avoid the need for a lot beyond what Nomad and Consul give you by themselves — but then you end up with the downsides that something like the Netflix microservices stack gets you. Fat clients ultimately leave the developer with more complexity, and Kubernetes helps you eliminate that in favor of more SRE/Ops/whatever-you’d-like-to-call-it complexity. Since cloud platforms can take a lot of the edge off of Ops complexity, that’s my preferred approach.

> The complexity of Kubernetes largely reflects the complexity of the problem.

I can solve most of these problems with a simple Linux + systemd in a much more readable way and am finished much quicker, even now that I am using k8s full time for 2 years.

So, no. What it represents is the complexity of the community having multiple sources of requirements, and the complexity of the landscape with everybody trying to make a claim with their name+logo without investing too much into a full stack answer.

How is systemd going to help you with service discovery, load balancing, autoscaling, automated rolling deployments, etc?

That being said, if you don’t need any of those things you probably don’t need Kubernetes either.

> service discovery

only used internally and not in a scaling fashion

> load balancing

External component that is hooked into k8s in some way

> autoscaling

External component that is hooked into k8s in some way

> automated rolling deployments

I doubt that many people are at a point yet where they can reliably do that. There are basic assumptions baked into that feature like that the k8s cluster survives until the next update comes out.

I would also argue that Kubernetes is less complex than it seems at first glance.

Yes, if you look at all the possible parts, and at the current monolithic codebase, there's a lot of complexity. It also supports umpteen cloud providers, volume providers, networking stacks, etc., and comes with a whole swathe of bootstrapping tools for various environments (e.g. AWS).

But if you strip it down, Kubernetes is "simple": There's a consistent object store made out of JSON structures, and then there's a bunch of controllers listening to changes to that store to make stuff real. That is the core. Everything is, in principle, controllers mediating between the data model and the real world. Very elegant and orthogonal.

You also have an API, a scheduler, and a thing called Kubelet that runs on each node to manage containers and report node-specific metrics. And of course you have Docker, though with 1.10 you can more easily run dockerless via containerd, which is a great thing indeed.

The complexity comes from the operational part, when the pieces come together. And as you say, there's not really any way around it.

It's certainly a lot easier to do "kubernetes the hard way" than it is to do "Linux from scratch", and I don't see a lot of FUD about how we should stop using Linux because it's too complex. That might seem like an extreme comparison, but I think the number & quality of comparable alternatives is similar between the two.

>Everything is, in principle, controllers mediating between the data model and the real world. Very elegant and orthogonal.

If you distill k8s down to this model alone, k8s becomes nothing but a pattern that has existed for decades. Maintaining "desired state" and "operational state" as separate things is not new.

You missed my point; I didn't say it's new, I said it was simpler than it might seem, and that thinking of it as a state machine makes it easier to understand what the core of Kubernetes really is.

And of course "nothing but a pattern" is nonsense. Pre-container systems like Puppet and Chef -- which are also, vaguely, based on converging real state towards desired state -- are firmly rooted in the traditional Unix model of mutable boxes. You can't implement a consistent reconciliation loop if your state can't be cleanly encapsulated (as with containers).

Reply on news.ycombinator.com