[manigandham]

Part of the problem is that Kubernetes itself is still changing rapidly and already has design-by-committee cracks in the API.

It would help if the community took a break from new features and worked on stability first so that Operators and other extensions can finally take off. Some of the things being developed now are so esoteric that it seems to be more about finding the next exciting thing to add than usability.

[shaklee3]

You're using that term in a derogatory sense. Would you rather have Google decide how everything is designed, and everyone else has to deal with it? I think you'd see a ton of GCP-specific stuff if that were the case.

I used to think how you did about kubernetes because I saw just how long it took for features I really wanted to get in. Then I attended some of the SIGs, and realized that there are so many use cases out there unlike mine, and that doing what I want may break what others want. So instead of making a decision that screws over everyone but one cloud provider, what I've seen is very methodical and careful decision making from many companies working together. This usually means that you get something that may not do exactly what you want out of the box, but there are hooks to do it if you'd like. I'd much prefer this over nothing at all.

It would be worth sitting in on a SIG you're interested in, and see how @smarterclayton and @thockin handle these kinds of decisions. I see so much negativity on HN about k8s, and it really seems like people just don't appreciate the amount of attention that goes into each decision. I think if you spend the time to trace the history of a feature and understand why things are done, it may change your mind about how complex k8s is.

[smarterclayton]

What are some of the design by committee cracks that you think should be addressed?

[derefr]

> Some of the things being developed now are so esoteric that it seems to be more about finding the next exciting thing to add than usability.

Or perhaps it's real ops people with particular arcane needs, each scratching their own itches?

K8s is a large FOSS project; and like most large FOSS projects, most PRs are from corporate contributors that wrote the code for their own purposes and then wanted to upstream it to avoid having to maintain a fork.

[bogomipz]

>"Part of the problem is that Kubernetes itself is still changing rapidly and already has design-by-committee cracks in the API."

Could you elaborate a bit on what those "cracks" are?

[shaklee3]

Stability of what?