5 ms·
I understand where most of the complexity in K8S comes from, but it still horrifies and offends me and I hate it. But I don't think it's Kubernetes' fault direc
by api 3y ago
I understand where most of the complexity in K8S comes from, but it still horrifies and offends me and I hate it. But I don't think it's Kubernetes' fault directly. I think the problem is deeper in the foundation. It comes from the fact that we are trying to build modern, distributed, high availability, incrementally upgradeable, self-regulating systems on a foundation of brittle clunky 1970s operating systems that are not designed for any of that.
The whole thing is a bolt-on that has to spend a ton of time working around the limitations of the foundation, and it shows.
Unfortunately there seems to be zero interest in fixing that and so much sunk cost in existing Unix/Posix designs that it seems like we are completely stuck with a basic foundation of outdated brittleness.
What I think we need:
* An OS that runs hardware-independent code (WASM?) natively and permits things like hot updates, state saving and restoration, etc. Abstract away the hardware.
* Native built-in support for clustering, hot backups, live process migration between nodes, and generally treating hardware as a pure commodity in a RAIN (redundant array of inexpensive nodes) configuration.
* A modern I/O API. Posix I/O APIs are awful. They could be supported for backward compatibility via a compatibility library.
* Native built-in support for distributed clustered storage with high availability. Basically a low or zero config equivalent of Ceph or similar built into the OS as a first class citizen.
* Immutable OS that installs almost instantly on hardware, can be provisioned entirely with code, and where apps/services can be added and removed with no "OS rot." The concept of installing software "on" the OS needs to be killed with fire.
* Shared distributed network stack where multiple machines can have the same virtual network interfaces, IPs, and open TCP connections can migrate. Built-in load balancing.
I'm sure people around here can think of more ideas that belong in this list. These are not fringe things that are impossible to build.
Basically you should have an immutable image OS that turns many boxes into one box and you don't have to think about it. Storage is automatically clustered. Processes automatically restart or, if a hardware fault is detected in time, automatically migrate.
There were efforts to build such things (Mosix, Plan 9, etc.) but they were bulldozed by the viral spread of free Unix-like OSes that were "good enough."
Edit:
That being said, I'm not saying Kubernetes is good software either. The core engine is actually decent and as the OP said has a lot of complexity that's needed to support what it does. The ugly nasty disgusting parts are the config interface, clunky shit like YAML, and how generally arcane and unapproachable and ugly the thing is to actually use.
I just loathe software like this. I feel the same way about Postgres and Systemd. "Algorithmically" they are fine, but the interface and the way you use them is arcane and makes me feel like I'm using a 70s mainframe on a green VT220 monitor.
Either these things are designed by the sorts of "hackers" who like complexity and arcane-ness, or they're hacks that went viral and matured into global infrastructure without planning. I think it's a mix of both... though in the case of Postgres it's also that the project is legitimately old. It feels like old-school Unix clunkware because it is.
- tayo42 3y agoWhat would you fix if you could?
- deleted 3y ago[deleted]
- happymellon 3y agoI'm not entirely convinced that there isn't a better way. With AWS Lambda and alternatives able to run containers on demand, and OpenFaas, they all point to "a better way". [Edit] Parent comment is almost entirety completely different after that edit to what I responded to. But I think my point still stands. One day, hopefully in my lifetime, we shall see it.
- api 3y agoYeah I do think lambda-style coding where you move away from the idea of processes toward functions and data are another possibly superior way. The problem is that right now this gets you lock-in to a proprietary cloud. There are some loose standards but the devil's in the details and once you are deployed somewhere it's damn hard to impossible to move without serious downtime and fixing.
- Too 3y agoHow about Erlang? I can’t say I know it myself. It always looks good on paper. Strangely nobody uses it. There must be a catch that detracts from it?