Openstack is the same way. However, people want something simple by default. Do not underestimate how poisonous "too complex" can be as a label for a project.

While kubernetes has a lot of concepts, its deployment is a lot more straightforward than OpenStack: https://dague.net/2014/08/26/openstack-as-layers/

Everything should be as simple as possible. It's the mark of good design

As simple as possible, but no simpler.

Minikube—and by extension, basing all the starting tutorials off minikube—is approaching this ideal, IMHO. A year ago, the first time I tried it, it was frustrating to even get up and running. This year I was actually able to get some examples running locally... and that's progress :)

As someone who uses minikube every day to work on an aggregated apiserver, my impression is that minikube is incredibly fragile. I have to reset the VM more than a few times a week. Which isn't that bad considering getting back up and running is pushing one big yaml file down kubectl, but still. It could be much better.

Same with kubeadm. It's pretty okay for a test cluster, but it can't even do a HA setup out of the box. That's an absolute must-have if you have a project big and serious enough to warrant using kubernetes.

There's no single design that suits everyone.

It's a toolbox. The job of choosing the right tool is on you.

There’s a big difference between a toolbox and a box with those same tools jumbled up inside.

One is organized and sensible. The other is a mess.

Just because they are both technically capable of the same things doesn’t mean we shouldn’t hold ourselves to the higher standard.

(Haven’t used Kubernetes, just going with the analogy)

Kubernetes has some bad organization and some terrible naming due to it's rapid pace of development, but it's getting better and is much nicer than any other existing system that can provide the same functionality.

I think you'd be surprised how quickly you can understand > 80% of it with just an hour spent reading the docs.

Don't pile in on k8s criticism without familiarizing yourself, please.

IMO it's a bit like Java for the cloud, the write once run anywhere bit (same caveats, but the win is still there). It intermediates the differences between cloud platforms. That alone makes it strategically worthwhile even if it was overcomplicated. But I don't think it is. Its core control loop is simple in principle, and the concepts and extension points fall out pretty naturally from it. It is a well-designed system at core and can support improvements over time without accruing cruft indefinitely, for example. Part of that makes it look like a bag of decoupled tools. But that's a strength of the system in the longer term.

I explicitly said I hadn’t used k8.

I was simply commenting on the “it’s a complex thing so it had to be complex” line of reasoning. It’s faulty, you can make complex thing easier with good design.

Complexity doesn't go away, but it shifts and becomes a lot more manageable with the right tools. Clustering is inherently complex, k8s allows you to centralise, structure and manage it in a way that brings it to the masses, where before it was limited to large companies like Google, Amazon, Facebook, ... spending considerable amounts of engineering resources in large scale deployments.

> Kubernetes isn't supposed to be simple

Disagree, it's a tool designed to abstract away the complexity of deployment and operations, simplicity of use/management sound like should be a design goal.

It will probably get there but for now it's hard to disagree with the "complex" label.

By analogy (likely a bad one) Kubernetes is the C++ of automated infrastructure?