Let's talk about this whole "k8s yaml is assembly" thing. When this gets said, it's often in a protective way. "The reason its so verbose is that it is assembly", or "The reason isn't dynamic is that is assembly". This is.. a bullshit excuse. It's not assembly at all.
What it is, is raw API calls. Without any of the kind of user tooling that might make it okay to make raw API calls. I know the story is, we're supposed to make those tools. But that's an enormous cop-out. A quick survey of the landscape shows that we're already @ ~6.
That's viable paths. None of which you could use effectively if you wanted to remain within the ecosystem broadly - each one will conflict with the others, do things slightly differently, and ultimately all of that will wind up straight on the user.
This is a by-design problem. The public API here is all that YAML. You must generate it. The only sane thing to do is build an anti-corruption layer around it. But if you do - you still have to allow the user to tweak what results, because ultimately that's the real syntax.
To have a complete closure over the entire specification for every possible k8s resource is possible, but awful. Users won't be happy - we learned this with Chef! Cookbooks that do everything the program does were 2x more complex than configuration of the program itself for users
You had to both learn Chef, learn how the cookbook author used Chef to model whatever was being managed, *and* you had to be an expert in the thing that was being modeled. If all 3 were true, you were gtg. If any weren't, well.. it was strictly worse, most of the time.
That's not a Chef problem. That's just the way it goes when the "abstraction" we build is fundamentally just a syntax anti-corruption boundary that must closely mimic the underlying system. As any possible k8s configuration language would be.
That's why none of them are going to become dominant. In the end, you're going to wind up writing that YAML. Because the alternatives are worse.
I don't think this is a problem that can be solved in k8s - it's truly baked in to the fundamental assumptions of the system. The API just.. sucks, because it is this way. There is no path home short of creating an alternate, first class, API.
But even if you did, you would just wind up with the identical YAML driving it. Because the API and the user interface are conflated.
To fix it, I suspect you need a two-way binding between the data that drives the anti-corruption layer, and the k8s API itself. You would have to show the user what you generate, allow them to change it, and have the changes reflected in the upper layers. And vice-versa.
To continue with the idea that the API and the UI are conflated - there are no semantics in the API at all. It's all very thin endpoints, driven by the data you submit. That means any "new" API would be way more complex, most likely, internally than the current API.
It's an example of where the design of k8s makes it easy for the k8s developers (just parse the payload and dispatch! what could be sweeter! so simple!) - but made it way worse for users (no semantics in this API, friends - just type that YAML and pray)
As an example - with any object I put in k8s, pretty much what I can do is get a status for the object. But what's in the status? Just the raw data. No behavior is defined at all, other than you'll get more data. So any higher abstraction is stuck.
And the API designers are stuck too - because if it would make sense semantically for a part of the k8s API to behave in a way that makes sense for its domain (why do service objects and deployments behave the same to the user? they clearly aren't the same), it would break the ui
For the record, it's an audacious and clever API design philosophy. The people who designed it were not dummies. But it's an experiment that we should declare essentially failed, because it's going to wind up very, very hard to abstract, if you ever get there at all.
The user-hostility is in the house, is what I'm saying. It's core to the design.
Fundamentally, the whole thing is one giant Anemic Domain Model. It lacks the application/service layer altogether. martinfowler.com/bliki/AnemicDo…
Here is an example. If the domain model was richer, and if there was a reasonable service layer we could extend, we wouldn't need all that logic inside controllers! We could ask the domain model to take action on our behalf. Only way to do that? Update some YAML and push it.
