Container vs. Virtuellen Maschinen: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „{{#drawio:container-vs-vms}}“)
 
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 +
=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=
 +
{| class="wikitable"
 +
|-
 +
! 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=
 
{{#drawio:container-vs-vms}}
 
{{#drawio:container-vs-vms}}
 +
 +
=Realität=
 +
*In der Praxis kombiniert man beides: Container laufen sehr oft in VMs, und die laufen auf einem Hypervisor.
 +
[[Datei:Vm-container.png]]
 +
 +
=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.
 +
 +
=Präsentation=
 +
*https://hedgedoc.xinux.net/p/Ti9s55SOP#/
 +
[[Kategorie:Virtualisierung]]

Aktuelle Version vom 11. Oktober 2026, 12:05 Uhr

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.

Vm-container.png

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.

Präsentation