Few reasons. Main one is that containers are a complex problem to implement. You need to mount a bunch of filesystems, set a bunch of limits what app running in

Few reasons. Main one is that containers are a complex problem to implement. You need to mount a bunch of filesystems, set a bunch of limits what app running in container can and cannot do, and then do all the plumbing to network it (firewalls, redirects etcetera). VM is essentially just the last part and usually simpler too ("just connect it to switch like it is separate machine" is common solution"). Sure you still have some complexity around storage but that's just "here is a bunch of blocks", no need to make overlay filesystem or mount image layers. Then we are at level of generic OS. The features docker/systemd/k8s uses were not "designed to make containers", they were designed to be used for anything you wanted, from as complex as containers to as simple as "let's put this processes in a cgroup so we can limit memory usage together. And with flexibility comes complexity. Then we have a problem of both systemd and k8s/docker managing same interfaces so both have to play nice with eachother. And we get to even more complexity when kubelet-controlled containers also need to manage system stuff, like say networking via kube-router. It would be simpler if say k8s' kubelet directly managed everything all at once but that means it would also have to do what systemd does (boot system, setup devices and partitions etc.) so while total complexity would be lower, the kubelet itself would be more complex.