Well, to be fair, yaml itself doesn't exactly have a stellar reputation, but I've never seen fifty lines of yaml that could convey so little information in any other place.
When you're writing YAML you can absolutely include from elsewhere (it calls it 'aliases', which is... Well, at least it exists) in multuple places - though annoyingly not from other files.
When you're reading (partially) generated YAML, (e.g. kubectl describe or edit) it's IMO a feature that everything is in its place with no indirection. (And as far as I'm aware this is YAML, not kubectl.)
K8s is developed to manage large number of service nodes running docker or oci containers coming from Google borg project. So it was designed for managing google level of service loads. It doesn't help when a service is only for few million users with few hundred or thousand containers. LXD and traditional tools can already do it without learning new way with lots of moving parts.
Well my company switched from VMs to k8s (few hundred containers) and it helped. Proof me wrong.
So in summary:
* we still have same amount of developers
* we still need same amount of sysadmins
* we introduced more complexity
* the application became slower
* the whole thing became much more expensive (managed k8s price, education, consulting, etc.)
* but! we have the same amount of income every month. Surprisingly our users don't pay more for the same service because we run our stuff on k8s
Abstractions have a cost. You either pay the cloud provider or you pay the Ops team that runs the cluster.
If you're fine with that and have evaluated the costs correctly, great!
This is the most frustrating but oft repeated nonsense about k8s.
Kubernetes is an amazingly helpful abstraction for any amount of load on any larger than trivially tiny set of services/storage/etc.
When you, like 90% of systems, don't have Google kind of load, you don't need Google number of nodes.
Machine count corresponds to load; abstraction doesn't.