The pod is the basic abstraction. The underlying container technology can be swapped out. People have made Kubernetes schedulers for Microsoft technologies and

The pod is the basic abstraction. The underlying container technology can be swapped out. People have made Kubernetes schedulers for Microsoft technologies and WASM runtimes as well. If you wanted to use microvms, you can. Most people stick with Linux containers. The Linux container/namespace is useful in the sense that operational characteristics matter, and many troubleshooting can end up going deeper and deeper in the stack. But as far as understanding how to _design_ things, knowing how the pure abstractions are composed together lets you be able to apply it to many systems, whether it is Kubernetes or something else. I suggest reading through the first few chapters of Roy Fielding’s PhD dissertation. He is known better for REST, but his dissertation was actually about architectural elements, properties, and constraints, and then applying to hypermedia as an engine of state. Once you know how to reason through computing architecture, you can pick apart any architecture, framework, or paradigm, and know how to work with it, and when you fight against it. You don’t grok a system by finding out how specific parts fit with each other, but rather, how things are consequences of the architectural elements, properties, and constraints. Then, the specific way things work (and don’t work!) together pops out. And don’t be afraid to dive into the messiness behind an abstraction. Knowing and being willing to do that can set you apart in your career.