|
I don't know the author, or Denis, but Denis in the comments is right. This is exactly the kind of pseudo-intellectual, inflammatory contrarian opinion that I'm unsurprised to see upvoted. This article completely conflates containers, orchestrators and schedulers in every aspect of discussion. Something will schedule and orchestrate these microVMs. Something with orchestrate secret manifestation inside those VMs. Something with operate on the host to supervise the VMs (which necessarily will have access to the guests). So far, every microVM platform with any adoption uses Kubernetes to orchestrate. I don't know, maybe someone is running Kata on Nomad or something, but I've not heard of it. And so far, most (all?) microVM implementation utilizes namespaces and cgroups either inside/outside the VM or both. This includes Chromium's use of OCI in Crostini (their Linux-VM-on-ChromeOS). Whatever comes along and replaces Kubernetes will push the envelope and will reduce the default blast-radius, will undoubtedly entirely rethink how authorization and namespacing work. The core would be much more minimal. And thousands of lines of generated Go would be replaced with <use your imagination>. And progress will have happened. I get it. Hating k8s is cool. I hate it too, for a whole myriad of reasons. But it's actually frustrating how bombastic and off the mark that article manages to be. And it's too bad, if it had just stuck with "Kubernetes isn't the future, and actually understood the problems with it, it could've been a decent rant. As-is, I think it does a pretty poor job of justifying the title. (And so far, microVM workloads look to be worse for "image" security than Docker, as the tooling (outside of Nix|Guix) is somehow even worse.) |