Containers also have a massive attack surface in comparison with VMs. Modern KVM has a comparable density to containers (except for memory).
I agree on the advantages on LXC though. Many hosting companies use it. Why fix it if it ain't broken?
I agree on the advantages on LXC though. Many hosting companies use it. Why fix it if it ain't broken?
> Modern KVM has a comparable density to containers (except for memory)
It does, but the memory can make a big difference if you're running microservices. If I'm guesstimating I'm thinking there's probably about a 200MB difference in memory usage between a good container image and a VM. With microservices that can grow quite a bit. Let's say 4 microservices, needing at least 2 of each for redundancy, you're already looking at a difference of 1.6GB of memory. If you need to massively scale those that's .8GB of memory for every host you add, not including any efficiency gains from applications running on containers rather than VMs (which is going to be largely negligible unless we're talking a massive scale).
Yes, and it increases the attack surface even more in some scenarios. Now, an unprivileged user can create new namespaces and do all sorts of things which were previously limited to root.
With "clear containers" (very minimal KVM VMs), you get the overhead down to <20MB:
https://lwn.net/Articles/644675/
Also, RAM is cheap.
Here's Stephane Graber's blog on it: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-con...
Also, note that with LXD/LXC the "default" container is now unprivileged. Also with LXD/LXC the LXC command syntax is now simplified even more than it was with traditional LXC but with the added power of being able to orchestrate and manage LXC containers either remotely or locally.
LXC also supports Nested LXC.
The scheduled release of LXC 2.0 and LXD 1.0 sometime around mid to late January.
This will also include support for live migration/CRIU.