Most smaller teams do not need a full fledge kubernetes anyways.

There's no one size fits all approach. There are trade offs. The Kubernetes tractor needs lots of oiling and what not for all the bells and whistles.

Trade offs is the keyword here.

Unfortunately, the above statement also applies to kubernetes.

A pithy response to be sure, but is it true? Every Kubernetes object type exists within a well-specified hierarchy, has a well-specified specification, an API version, and documentation. Most of the object families' evolution are managed by a formal SIG. Not sure how any of that qualifies as ad-hoc or informal.

"It's not a mess! it was designed by committee!"

I'm not sure what to say here. The kubernetes docs and code speak for themselves. If you actually think that it's clean, simple, well designed, and easy to operate, with smooth interop between the parts, I can't change your mind. But in practice, I have found it very unpleasant. It seems this is common, and the usual suggestion is to pay someone else to operate it.

First you were complaining that it was ad hoc and informal. Now you seem to be complaining that it's too formal and designed by committee.

Also I never said Kubernetes was well-designed, easy, or simple.

You say that as though bureaucracy is equivalent to formalism. It's not.

Kubernetes is anything but adhoc. That's the best thing, but can also be the most annoying, part about it