Hacker News new | past | comments | ask | show | jobs | submit login

I think they mean run a VM with one container inside. So you do get strong isolation.

This is similar to how managed container IaaS works. They launch a VM and run your container in it.

It is extra complexity but has a few advantages. 1. People already have a convenient workflow for building container images. 2. The base OS can manage hardware, networking and whatever other low-level needs so that the container doesn't need to have these configurations. 3. If you want to trade of isolation for efficiency you can do this. For example running two instances of a container in the same VM. The container doesn't need any changes to support this setup.




The model of a single container within a VM just adds overhead. The ideal case would be to remove the container layer and have the application(s) within the container run directly in the VM (which hopefully only includes the libs and OS modules needed for the app to run, and nothing more).

This is the approach we take at kraft.cloud (based on the LF Unikraft project): use Dockerfiles to specify app/filesystem, and at deploy automatically convert to a lightweight VM (unikernel) without the container runtime/layer.


> So you do get strong isolation.

No, you don’t. There is no benefit the container is providing, because The only feature of the container is isolating you from the zero other containers running on the VM.


The isolation I am referencing is from the VM, not the container. Containers don't provide strong isolation, that is why the VM is required in this model.


The VM is an isolated environment itself. You do not need to be isolated from it.

Using two levels of userland isolation makes about the same sense as using 457 levels of userland isolation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: