3 ms·

> It isn’t deliberately complicated, and once you know why it is designed the way it is, it becomes very capable. I’m sure it isn’t and I changed the emphasis

by mulmen 3y ago

> It isn’t deliberately complicated, and once you know why it is designed the way it is, it becomes very capable. I’m sure it isn’t and I changed the emphasis to make that line more about the slope of the learning curve. Thanks for this explanation. The inability to grok the internals is really hanging me up. I’ll embrace the simpler “distributions” as a way to understand the higher level constructs. Does it also make sense to ignore the fact that this is built on Linux’s containers and namespaces? Based on my very limited understanding Kubernetes is basically a “cloud operating system”. This is why the underlying components like networking and container managers can be swapped out. But I still don’t grok how the subsystems fit together.

hosh 3y ago
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.

by mulmen 3y ago

hosh 3y ago

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.