Author complains system is too complicated then laments it needs to add bunch more features that would make it even more complex (particularly mutable pods).
> A modest expansion of the previous section: make each field of an object owned explicitly by a particular control loop. That loop is the only one allowed to write to that field. If no owner is defined, the field is writable by the cluster operator, and nothing else
He’s proposing changing fundamental design decisions, and then eliminating big chunks of the existing implementation.
Kubernetes is obviously overly-complicated. I’m just using it in a CI/CD environment and, in a month, have hit most (all?) of the issues mentioned in the article.
I don’t think it’s fixable. It’s the interesting to see an expert in this area come to the same conclusion for the same reasons.
There are many parts that are hand waved in and in practice would be difficult such as mutable pods and direct to pod load balancing. Pretty typical in distributed compute to have something that sounds simple turn into madness upon closer look. He maybe an expert but sure as hell didn’t think through all implications
I very much didn't think through it, and opened with exactly that disclaimer :). You're right that the lofty ideas probably won't survive contact with reality. In my defense, I wrote this in a couple of hours to get it out of my head, and then people inexplicably started reading it.
Heh, I actually agree that some of the called out use cases such as PinnedDeployment are needed but imo extensibility of kubernetes api make it non issue since you can just build your own implementations
My counter to that is that people mostly don't roll their own, so the defaults matter. Adding more implementations just increases the total amount of complexity going on.
That probably argues for "Deployment shouldn't have been a core object type", and I think k8s folks generally agree on that now, in hindsight. But the idea of generalizing CRDs to the extreme is relatively recent.
> A modest expansion of the previous section: make each field of an object owned explicitly by a particular control loop. That loop is the only one allowed to write to that field. If no owner is defined, the field is writable by the cluster operator, and nothing else
This is already a thing starting 1.17 i think with server side apply https://kubernetes.io/docs/reference/using-api/server-side-a... (except it’s opt-in)