Note that the graphic showing containers running "on top" of the container engine is not 100% correct. Unlike VMs with their own kernel, containers are just regular processes that use abstraction mechanisms to separate themselves from the host OS. The container engine, in that way, is also just a process that runs BESIDE the containers, not under them, as nothing is strictly speaking running on a container engine. The containers themselves are still controlled by the kernel or the OS itself! The graphic is not wrong as the engine of course dose a lot for the container and kernel but if this was to be a technical graphic it would be wrong!
Why is a security vulnerability in the kernel a con for containers but not VMs? If there's a kernel vulnerability on the host machine then it still can affect the VMs since the hypervisor runs on the host with the vulnerable kernel.
Note that the graphic showing containers running "on top" of the container engine is not 100% correct. Unlike VMs with their own kernel, containers are just regular processes that use abstraction mechanisms to separate themselves from the host OS. The container engine, in that way, is also just a process that runs BESIDE the containers, not under them, as nothing is strictly speaking running on a container engine. The containers themselves are still controlled by the kernel or the OS itself! The graphic is not wrong as the engine of course dose a lot for the container and kernel but if this was to be a technical graphic it would be wrong!
Why is a security vulnerability in the kernel a con for containers but not VMs? If there's a kernel vulnerability on the host machine then it still can affect the VMs since the hypervisor runs on the host with the vulnerable kernel.