oci images, yaml configs, single signature admin security, poor arbitrary hardware support, poor edge support, non distributed defaults, metering as afterthought. these are not good bases and defaults of k8s.
I don't know if you can say these are not good bases. K8S is wildly successful because it solves the core problem of distributed computing (run this code on these machines) at a level that is high enough to not bog down and low enough for engineers to finagle the hardware.
This has shades of the "worse is better" Unix+C vs Lisp debate - Unix+C won despite doing things "wrong" because it did them simpler, faster, and more debuggably than Lisp.
Kubernetes is like POSIX. It's a simple product at its core: there's a distributed global state exposed over an API and control loops to update that state. The complexity comes from all the networking and auth and storage rules that people shoehorn in on top.
My only complaint with K8s is that it tries to help with some of that instead of declaring it all to be out of scope and delegating it to plugins, because that's how we got the "K8S is too complicated!!!!" discourse.
But you're waiving implementation/design (which is not just particular coding choices) and pointing out how a highly simplified, high level concept is useful. But what makes Kubernetes or Linux useful is that there is a concrete implementation, and that brings all the flaws along too. We are not pressed for time and innovation now, and arguably never were. Do not draw from the vagaries of human nature to establish technical judgements. Most things and people are successful mainly due to luck with timing and reception. Like natural selection, the question is not "is this adaptation good enough to survive?" but rather "is this adaptation not bad enough to die?". First mover advantage, monopoly power, network effect, the curse of backwards compatibility, whatever you call it, technical merit is generally not a primary factor in a project's long-term success. Or rather, making a big relative leap in technical merit against competitors nets success without any indication of it being a big absolute leap as well. Unix had genuine technical merits at the time, and to some extent this still holds true today. But we have also learned and grown. What was good enough back then should not be the standard for now.
> Kubernetes is like POSIX. It's a simple product at its core: there's a distributed global state exposed over an API and control loops to update that state. The complexity comes from all the networking and auth and storage rules that people shoehorn in on top.
We will probably never shave off all accidental complexity. But there are ways of reducing it, and any additional feature will be a burden. So we must make features, but with care for interaction and evolution and, crucially, deployment (if I don't want to use feature X, do I pay for it?). You're right that Kubernetes and Linux aren't unreasonable. They're not far off the mark, and there's only so much low-hanging fruit of improvement. But with the knowledge I have, at least for Linux, I do not accept the current state of affairs as "good enough". I don't agree it is a "good base", but I will say it is instructive. I appreciate that you see the essential complexity of building a Kubernetes or Linux, or a replacement. I posit that we can do better and keep polishing to get a glimpse of that "simple product at its core".
And no, incremental improvements are not the way if you can see glaring room for improvements. There is enough time in the world, but not enough for people to get reasonable progress. And incrementalism limits the scope of changes. It's highly unfortunate that the programming industry/community are too afraid of https://xkcd.com/927/ to make meaningful progress. A fast-moving industry that gets tangled up in its own speed is, in the end, slow-moving.
