[atombender]

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.

[jrs95]

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.

[hueving]

>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.

[lobster_johnson]

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).