4 ms·

Thanks for the detailed answer > extensibility This is something that irks me right now, but at my current knowledge level (~0) it didn't feel right to even m

• llarsson 2y ago
  That's right, and it's also why you see Kubernetes distributions popping up. That way, someone has already done all the configuration of various plugins and components for you. For instance, the major clouds that all let you easily start with their Kubernetes services and that they integrate well with the logging and monitoring systems, IAM, server/node provisioning, etc. Or ones that are not tied to any particular cloud provider, and perhaps focused on security (full disclosure: I work for Elastisys, who makes exactly that) or ease of use. I'm sure we will see more and more such efforts in this space, exactly because cobbling together something yourself from scratch (basically just a control loop runner, as you said) is neither very appealing when you think about ongoing maintenance, nor very cost-effective for businesses to spend engineering time on.
• hosh 2y ago
  That is correct. Every cluster is unique. What we have instead are a set of standard design patterns that are broadly (but not universally) applicable. Even the core components can be swapped out so that Kubernetes can be adapted. For example, there are several teams that wrote kubelet replacements. The built-in scheduler for kubernetes is only responsible for pod placement by contacting the kubelet on a node and changing its desired state. The kubelet is responsible for actual placement. That meant people have created kubelets that could run wasm workloads as pods. This was how native Windows workloads were implemented. I remember correctly, there are also kublets that could run unikernels, microvms, etc. The design pattern of label selectors remains the same, so that same concept can be used to place those specialized workloads. I also learned something from an interview I once had ... their platform team came to the conclusion that every site is unique because every company will have its own specific needs and unique combination of technology. They (deliberately) don't use Kubernetes. They even crafted their interview process for that. It's a timed session to attempt to do something deceptively simple, that turned out to be an ops nightmare. There are no internet resources describing how to do that. No one is expected to finish it within the time. Instead, they are looking at how someone work through the problem as well as their emotional regulation while under time pressure. Finally, I'd like to draw attention to a fallacy that has plauged modernity, and it is very applicable to computing design. This is from the field of political science, from a book written by James C. Scott called "Seeing Like a State". There is a blog post about the key concept -- legibility -- https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/ https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-call... The pursuit of legibility has lead us to imposing a overly simplistic view onto something complex instead of really understanding the complexity. In the case of governments, this imposition uses authoritarian powers, and results of fragile solutions. In the case of computing infrastructure, we create abstractions and are surprised when it leaks.