Containers vs Virtual Machines
VMs virtualize hardware via a hypervisor; containers virtualize the OS via namespaces. Containers share the host kernel.
VM = separate houses with own foundations (kernel). Container = apartments in one building sharing plumbing (kernel). Cheaper and faster to build apartments, but a fire in the walls spreads to everyone.
VMs: full OS per VM, hardware-level isolation, ~GB images, seconds to start, stronger security boundary. Containers: shared kernel, process-level isolation, ~MB images, milliseconds to start, weaker security boundary. VMs are better for multi-tenancy with untrusted workloads. Containers are better for microservices, CI/CD, and density.
Hypervisors: Type 1 (bare metal: VMware ESXi, KVM, Hyper-V) vs Type 2 (hosted: VirtualBox, VMware Workstation). KVM is Linux kernel built-in and what most cloud providers use. Container escape vulnerabilities exploit kernel bugs — recent examples: runc CVE-2019-5736, containerd CVE-2022-23648. Kata Containers and gVisor run containers inside lightweight VMs or with a user-space kernel to get VM-level isolation with near-container performance. EKS Fargate and GKE Autopilot use this approach.
VMs virtualize hardware — each VM has its own OS, kernel, and a hypervisor managing hardware access. Containers virtualize the OS — they share the host kernel but have isolated namespaces. This makes containers ~10x faster to start, ~10x smaller on disk, and much denser to pack. The trade-off is isolation: a kernel exploit can escape a container but not a VM. For untrusted multi-tenant workloads, VMs win on security. For microservices and CI/CD, containers win on efficiency.
Containers don't provide the same security isolation as VMs. Running untrusted code in a container on a shared host is risky — use dedicated nodes, gVisor, or Kata Containers for that use case.