It doesn’t take much to start a discussion with people about the security implications of containers vs VMs. It often comes down to the discussion that Container, given the shared kernel aspect are less secure than VMs.
The kernel with all its syscalls provides a much larger attack surface compared to VMs. So in the eyes of various people, switching to container is a step backwards from using VMs.
However in the Kubernetes world1, it’s not so cut and dry. Kubernetes has standardised around container runtimes but container runtimes are actually quite flexible. The one everyone knows and uses is runc, the default of containerd and docker. This is what people refer to when they talk about containers.
But Kubernetes has an abstraction layer here. The object called RuntimeClass allows to adjust the underlying implementation used by the Container Runtime Interface. This references which runtime the underlying container engine, such as containerd, uses to create the container in a Pod.
Google developed gVisor as an alternative secure runtime and there is also kata-containers. Both allow to utilise KVM the kernel’s virtualisation layer to turn containers into full blown VMs without any modification besides the runtimeClassName definition in the Pod object.
The beauty: These VMs behave (almost) exactly like the Pods using runc-based containers, including the use of services for inter-pod communication, network policies for firewalling, centralised log management through the kubelet, and isolation of workloads from each other. But this time without a shared kernel underneath.
In other words: All the benefits of VMs, with most of the benefits of containers. The main difference: The operating system (OS) inside the VMs doesn’t need to be maintained individually. If you run 3000 pods with kata-container as the container runtime, you just update the kata-container configuration with a new VM image, and then things are updated by draining nodes and moving a bunch of pods around.
There is no need to run any OS update command on 3000 individual VMs. Container runtimes provide a standardised way of managing VMs without the overheads that traditional VMs can bring.
These days I run almost all internet-facing workloads in kata-container-based VMs, making my container hosts mostly hypervisors.
In other words: Containers vs. VMs? Why not both?
-
Okay, just for everyone who looks into this deep enough, you can also do all this with
containerdand docker or podman. I know, but it doesn’t matter to me, so feel free to write your own article about it. ↩
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.