Container vs. Virtuellen Maschinen
Zur Navigation springen
Zur Suche springen
Grundsätzliches
- Container und virtuelle Maschinen (VMs) sind die zwei gängigen Wege, Anwendungen isoliert auf gemeinsamer Hardware zu betreiben.
- Beide trennen Anwendungen voneinander, nutzen Ressourcen besser aus und erleichtern die Skalierung.
- Der entscheidende Unterschied: Eine VM bringt einen eigenen Kernel mit, ein Container nutzt den Kernel des Hosts.
Virtuelle Maschinen (VMs)
- Eine VM ist ein vollständiger virtueller Rechner mit eigenem Betriebssystem und eigenem Kernel.
- Der Hypervisor stellt ihr emulierte Hardware bereit (Festplatte, Netzwerkkarte, Grafik). Die CPU wird per VT-x/AMD-V durchgereicht.
- Auf einem Host laufen so mehrere, auch unterschiedliche Betriebssysteme nebeneinander.
- Starke Isolation
- Jede VM hat ihren eigenen Kernel. Ein Absturz oder Angriff in einer VM betrifft die anderen in der Regel nicht.
- Höherer Ressourcenbedarf
- Jede VM braucht ein komplettes Betriebssystem mit eigenem RAM- und Plattenbedarf.
- Langsamerer Start
- Eine VM bootet ein vollständiges Betriebssystem, das dauert Sekunden bis Minuten.
- Hohe Flexibilität
- Beliebige Betriebssysteme auf demselben Host, z. B. Windows und Linux nebeneinander.
Container
- Ein Container ist eine isolierte Umgebung für Prozesse auf dem Host. Es gibt keinen eigenen Kernel.
- Die Isolation kommt vom Linux-Kernel selbst:
- Namespaces trennen, was ein Prozess sieht (Prozesse, Netzwerk, Dateisystem, Benutzer).
- cgroups begrenzen, was ein Prozess verbraucht (CPU, RAM, I/O).
- Ein Container bringt nur die Anwendung und ihre Bibliotheken mit, z. B. als Image.
- Geringer Ressourcenbedarf
- Kein zweites Betriebssystem, kein zweiter Kernel. Ein Container ist im Kern ein normaler Prozess.
- Schneller Start
- Ein Container startet in Sekundenbruchteilen bis Sekunden, weil nichts gebootet werden muss.
- Geringere Isolation
- Alle Container teilen sich den Host-Kernel.
- Eine Kernel-Lücke oder ein Kernel-Absturz betrifft alle Container auf dem Host.
- Hohe Portabilität, mit Einschränkung
- Ein Image läuft auf jedem Host mit Container-Runtime (Docker, Podman, containerd).
- Voraussetzung: passender Kernel und gleiche CPU-Architektur. Linux-Container brauchen einen Linux-Kernel. Unter Windows und macOS läuft dafür im Hintergrund eine VM.
- Unterschiedliche Distributionen sind möglich (z. B. ein Debian-Container auf einem Rocky-Host), aber immer mit dem Kernel des Hosts.
Anwendungs- und System-Container
- Anwendungs-Container (Docker, Podman): ein Dienst pro Container, z. B. ein Webserver.
- System-Container (LXC, in Proxmox „CT“): ein komplettes Linux-Userland mit init-System, verhält sich fast wie eine VM, nutzt aber den Kernel des Hosts.
Vergleich
| Merkmal | Virtuelle Maschinen (VMs) | Container |
|---|---|---|
| Kernel | Eigener Kernel pro VM | Kernel des Hosts |
| Isolation | Stark (Hypervisor, CPU-Unterstützung) | Geringer (Namespaces, cgroups) |
| Ressourcenbedarf | Höher | Geringer |
| Start | Sekunden bis Minuten | Sekundenbruchteile bis Sekunden |
| Betriebssysteme | Beliebig (Windows, Linux, BSD …) | Nur passend zum Host-Kernel |
| Portabilität | Weniger portabel (große Images) | Sehr portabel (kleine Images) |
| Beispiele | KVM/QEMU, VirtualBox, VMware, Proxmox VM | Docker, Podman, LXC, Proxmox CT |
Schaubild
Realität
- In der Praxis kombiniert man beides: Container laufen sehr oft in VMs, und die laufen auf einem Hypervisor.
Fazit
- VMs bieten starke Isolation und freie Wahl des Betriebssystems, brauchen aber mehr Ressourcen und starten langsamer.
- Container sind leicht, schnell und portabel, teilen sich aber den Kernel des Hosts und sind dadurch schwächer isoliert.
- Die Wahl hängt ab von Sicherheitsanforderungen, benötigtem Betriebssystem, Ressourcen und Skalierung.

