I agree with the core of your comment, but I would note that containerization has other advantages over simple static binaries. In particular, sandboxing even at the network layer. Also, containers often bundle mutiple programs together to ensure compatibility, not just libraries, which is a step that is almost never discussed. Applications often depend on system utilities whose API is even more poorly defined/maintained than system libraries, so bundling your own ls or shell may be a safer option.

Even further, k8s really has nothing to do with this, it is a tool for submitting workloads to a group of a computers through a single API, and it critically depends on containerization for network and storage isolation. K8s would have looked more or less identical to how it does today even if shared libraries had never existed (though probably the exact format of OCI container images could have been much simpler).

> it might be worth noting that the LGPL requires shared libs

nope, not at all. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

But it says

> If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Heads up to gnu.org: site won't load via https in FF due to HSTS policy (broken certificate chain?).