They haven't. As an example of where this lack of efficiency comes from, recently I've fixed an issue during which I've discovered that the Etcd component of k8s uses periodic (10 sec) liveness checking, where for every check (launching of the etcdctl client), the `runc` binary (from container.d) is executed 3 (three) times. You can imagine this probably just scratches the surface.

Ugh! Was the fix committed upstream?

Yes, this one was a systemd detection in runc, which was causing big log flooding and runtime overhead due to runc being executed so frequently. I initially cached the checks, but later the devs removed them altogether. Still, this is not solving the inefficiencies in k8s. https://github.com/kubernetes/kubernetes/issues/76531

Yes, it's a real issue. Kubernetes burns too much RAM and CPU even with no workload.

Docker on macOS also suffers from that issue though.

It will use more on MacOS and Windows than on Linux, as it needs to use a sidecar Linux "Moby" VM to run containers. In practice on Windows, this hasn't been an issue for me (64GB RAM in my dev laptop).

This will actually finally change soon'ish with Windows at least, I think as part of WSL2. Not sure if anything is going to change on MacOS.

Not for me, except for the RAM blocking - I wish that Hyperkit could dynamically allocate and release RAM for the guest machine instead of blocking 2GB (in my case) by default all the time.

I haven't noticed that.

--vm-driver=none helps a lot with the CPU and especially RAM usage, using k3s instead of minikube helps more.