Once you know what tools to ignore, and build scripts around the ones you need, it's very powerful.
This line of thinking is like faulting the golang stdlib for having a lot of useful stuff in it.
It's a toolbox. The job of choosing the right tool is on you.
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)
I think you'd be surprised how quickly you can understand > 80% of it with just an hour spent reading the docs.
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 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.
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.
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.