Vervangen containers VM's? Het juiste isolatiemodel kiezen
Kort antwoord
Niet helemaal. Containers optimaliseren packaging en deployment, VM's bieden standaard een sterkere isolatie en meer OS-flexibiliteit. De meeste praktijkomgevingen gebruiken allebei: VM's voor de grenzen die ertoe doen, containers voor de onderdelen die baat hebben bij snelheid en herhaalbare deploys.
Ze lossen verschillende problemen op
Een VM virtualiseert hardware: hij krijgt een eigen kernel, een volledig eigen OS en een grens die de hypervisor afdwingt tussen hemzelf en al het andere dat op de host draait. Een container virtualiseert in plaats daarvan het besturingssysteem: hij deelt de host-kernel met elke andere container op die host, en de isolatie komt van kernel-namespaces en cgroups in plaats van een hypervisor.
Dat verschil is het hele verhaal. Het is de reden dat containers binnen milliseconden starten en VM's er langer over doen. Het is ook de reden dat een container escape een directere route naar de host is dan een VM escape: er zit namelijk minder tussen de container en de kernel.
Waar containers winnen
Containers zijn de betere standaardkeuze voor stateless, horizontaal schaalbare applicatielagen: web front-ends, API-services, achtergrondprocessen, alles waarbij een instance gestopt en vervangen kan worden zonder dat iemand het merkt. Snelle opstart, eenvoudige replicatie en een packagingformaat (de image) dat zich in development, staging en production hetzelfde gedraagt: dat zijn de echte voordelen, niet alleen mode.
Ze zijn ook de logische keuze zodra je hebt besloten dat je de dingen die container-orchestratie biedt, echt nodig hebt. Zie Heb je Kubernetes nodig? Een beslisgids als je die afweging nog niet hebt gemaakt.
Waar VM's nog steeds winnen
VM's zijn de betere keuze overal waar isolatie belangrijker is dan dichtheid of deploy-snelheid: multi-tenant workloads met wezenlijk verschillende vertrouwensniveaus, omgevingen met zware compliance-eisen, of software die een volledig, eigen OS verwacht dat naar eigen inzicht geconfigureerd kan worden. Omdat containers de host-kernel delen, is vaak extra hardening nodig (rootless containers, seccomp, AppArmor- of SELinux-profielen, image scanning en signing) om hetzelfde niveau te bereiken. Voor de meest gevoelige workloads is het draaien van de container in een VM, voor extra isolatie, een redelijk en veelvoorkomend patroon, geen teken van falen.
VM's zijn ook vaak de eenvoudigere keuze voor veel stateful workloads. Zie Omgaan met stateful services in containers specifiek daarover.
Een praktische verdeling
| Workload | Containers | VM's |
|---|---|---|
| Stateless web/API-services | Meestal de betere keuze | Werkt, maar minder efficiënt op schaal |
| Achtergrondtaken (job workers) | Meestal de betere keuze | Werkt prima op kleinere schaal |
| Databases en andere stateful services | Mogelijk met StatefulSets en de nodige zorg | Vaak de eenvoudigere, voorspelbaardere keuze |
| Compliance-zwaar of multi-tenant met strikte isolatie-eisen | Vraagt om extra hardening om VM-isolatie te evenaren | Sterkere standaard isolatiegrens |
| Software die per fysieke/virtuele machine gelicentieerd is, of die een volledig aangepast OS nodig heeft | Lastige match | Logische match |
Bij Worldstream
Beide isolatiemodellen zijn beschikbaar: Flexible VPS en Dedicated Servers geven je volledige VM's (of, met Dedicated Servers en Bare Metal Compute, fysieke hardware) voor de workloads waar die grens ertoe doet, terwijl Kubernetes, op dit moment in preview, je container-orchestratie geeft voor de workloads waar snelheid en schaal belangrijker zijn. De meeste teams gebruiken uiteindelijk allebei, in plaats van het ene te kiezen en het andere te laten vallen. Zie voor de VM-kant de Compute-categorie.