Deutsch
Menü

Virtuelle Maschine vs. Container: Virtualisierungsebene, Kernel, Startzeit, Isolation und Einsatz

Beide lassen auf einem Rechner mehrere Anwendungen voneinander isoliert laufen, virtualisieren aber verschiedene Ebenen. Bei einer virtuellen Maschine erzeugt ein Hypervisor virtuelle Hardware wie CPUs, Speicher, Festplatten und Netzwerkgeräte, und jede virtuelle Maschine führt darauf ein vollständiges Betriebssystem samt Kernel aus. Ein Container teilt sich den Kernel des Host-Betriebssystems und trennt mit Kernelfunktionen wie Namespaces und cgroups, was Prozesse sehen und welche Ressourcen sie nutzen dürfen. Container booten kein Betriebssystem, sind daher leichter und starten schneller, während virtuelle Maschinen bei der Stärke der Isolation und der Auswahl lauffähiger Betriebssysteme vorne liegen. In der Cloud werden beide üblicherweise kombiniert, indem Container in virtuellen Maschinen laufen.

MerkmalVirtuelle MaschineContainer
VirtualisierungsebeneHardware: Der Hypervisor erzeugt virtuelle CPUs, Speicher, Festplatten und Netzwerkgeräte und teilt sie zuBetriebssystem: Auf dem Host-Kernel werden getrennt, was Prozesse sehen (Prozess-IDs, Netzwerk, Dateisystem usw.) und welche Ressourcen sie nutzen dürfen
BetriebssystemkernelJede virtuelle Maschine führt ein eigenes Betriebssystem (Gastbetriebssystem) mit eigenem Kernel ausAlle Container teilen sich den Host-Kernel; Container-Images enthalten keinen Kernel
Lauffähige BetriebssystemeAuch eine andere Art von Betriebssystem als der Host (z. B. Windows auf einem Linux-Host)Nur was auf dem Host-Kernel läuft; Linux-Container brauchen einen Linux-Kernel
Image-GrößeEnthält ein ganzes Betriebssystem, daher typischerweise im GigabytebereichNur die Anwendung und die benötigten Bibliotheken, daher typischerweise viel kleiner als eine virtuelle Maschine
StartzeitBeginnt mit dem Booten eines Betriebssystems und dauert daher oft einige zehn Sekunden bis einige MinutenStartet nur Prozesse und ist daher schnell; läuft typischerweise innerhalb weniger Sekunden
Stärke der IsolationStark: Trennung auf Hardwareebene, daher greifen Probleme im Kernel eines Gastes kaum auf andere virtuelle Maschinen überSchwächer als bei einer virtuellen Maschine: Der Kernel wird geteilt, daher kann eine ausgenutzte Kernel-Schwachstelle den Host und andere Container treffen
RessourceneffizienzJedes Gastbetriebssystem belegt eigenen Speicher und eigene CPU, daher passen weniger auf einen RechnerKeine doppelten Betriebssysteme, daher passen mehr in dieselben Ressourcen
Typischer EinsatzVerschiedene Betriebssysteme nebeneinander, Serverkonsolidierung, virtuelle Maschinen bei IaaS, Umgebungen mit starker IsolationMicroservices, Test und Auslieferung in CI/CD, Betrieb im großen Maßstab mit Kubernetes, gleiche Umgebung in Entwicklung und Produktion

Die Zahlenwerte sind typische Größenordnungen und variieren je nach Prozessgeneration und Produkt.

Wann welche Variante?

Virtuelle Maschine
Wenn ein anderes Betriebssystem als auf dem Host laufen soll, Kernelversion und -einstellungen frei wählbar sein sollen oder starke Isolation nötig ist, etwa wenn man sich einen physischen Server mit anderen Nutzern teilt.
Container
Wenn viele Instanzen derselben Anwendung schnell gestartet und gestoppt werden sollen, dasselbe Image von der Entwicklung bis zur Produktion laufen soll oder viele kleine Dienste auf einem Rechner untergebracht werden sollen.

Häufige Fragen

Braucht man noch virtuelle Maschinen, wenn man Container hat?

Das hängt vom Einsatz ab. Um Linux-Anwendungen auszuführen, reichen Container oft aus. Um ein anderes Betriebssystem auszuführen, den Kernel zu ändern oder starke Isolation zu erreichen, braucht man virtuelle Maschinen. In der Cloud laufen Container meist auf virtuellen Maschinen des Anbieters; beide werden also kombiniert, statt dass das eine das andere ersetzt.

Warum laufen Linux-Container auf einem Windows- oder macOS-PC?

Linux-Container brauchen einen Linux-Kernel. Werkzeuge, die Linux-Container unter Windows oder macOS ausführen, starten daher im Hintergrund eine schlanke virtuelle Linux-Maschine und führen die Container darin aus. Die Container teilen sich weiterhin den Host-Kernel; Host ist in diesem Fall das Linux in der virtuellen Maschine.

Wie lässt sich die Isolation von Containern verstärken?

Die Prozesse im Container ohne Root-Rechte ausführen, unnötige Berechtigungen entziehen und die erlaubten Systemaufrufe einschränken: All das verringert die Folgen eines Angriffs. Wird noch stärkere Isolation gebraucht, gibt es Ansätze, die jedem Container eine eigene schlanke virtuelle Maschine geben und ihn darin ausführen.

Was unterscheidet Hypervisoren vom Typ 1 und Typ 2?

Ein Hypervisor vom Typ 1 (Bare-Metal) läuft direkt auf der Hardware und führt darauf virtuelle Maschinen aus. Ohne zusätzliche Schicht bietet er bessere Leistung und Isolation und wird in Servern und der Cloud eingesetzt. Ein Hypervisor vom Typ 2 (gehostet) läuft als Anwendung auf einem gewöhnlichen Betriebssystem; er ist einfach zu nutzen und für Entwicklung und Tests auf PCs verbreitet.

Verständnis prüfen

Welche Aussage zu den Typen von Hypervisoren ist richtig?

  1. AEs gibt einen Typ, der direkt auf der Hardware läuft, und einen, der als Anwendung auf einem gewöhnlichen Betriebssystem läuft
  2. BEr läuft stets als Anwendung auf einem gewöhnlichen Betriebssystem und nie direkt auf der Hardware
  3. CEs gibt keinen Unterschied zwischen Typen, und alle laufen allein als Software ohne Hardware
Antwort und Erläuterung anzeigen

Antwort: A. Es gibt einen Typ, der direkt auf der Hardware läuft, und einen, der als Anwendung auf einem gewöhnlichen Betriebssystem läuft

Es gibt Hypervisoren, die direkt auf der Hardware laufen und Betriebssysteme verwalten (Typ 1, Bare-Metal), und solche, die als Anwendung auf einem gewöhnlichen Betriebssystem wie Windows oder Linux laufen (Typ 2, gehostet). Typ 1 hat keine zusätzliche Schicht und ist bei Leistung und Isolation überlegen, weshalb er auf Servern und in der Cloud verwendet wird; Typ 2 ist einfach zu nutzen und wird häufig für Entwicklung und Tests auf PCs eingesetzt. Beide nutzen Hardware wie die Virtualisierungsunterstützung der CPU.

Welche Aussage zum Unterschied zwischen Containern und virtuellen Maschinen ist richtig?

  1. AContainer haben jeweils einen eigenen Betriebssystemkern, virtuelle Maschinen teilen sich den Kern
  2. BContainer laufen auf einem Hypervisor, virtuelle Maschinen allein mit Betriebssystemfunktionen
  3. CContainer teilen sich den Kern, virtuelle Maschinen betreiben jeweils ein eigenes Betriebssystem
Antwort und Erläuterung anzeigen

Antwort: C. Container teilen sich den Kern, virtuelle Maschinen betreiben jeweils ein eigenes Betriebssystem

Container sind ein Verfahren, das sich den Kern eines Betriebssystems teilt und dabei Dateisicht, Prozesse, Netzwerk und nutzbare Ressourcen gruppenweise isoliert. Da kein ganzes Betriebssystem gestartet wird, sind sie leicht und starten schnell. Virtuelle Maschinen betreiben auf einem Hypervisor jeweils ein Betriebssystem mit eigenem Kern; sie sind schwerer, dafür stärker isoliert und können auch andere Betriebssystemarten ausführen. Den Kern teilen die Container; bei Antworten ist auf umgekehrte Beschreibungen zu achten.

Welche Kombination ordnet den Linux-Kernelfunktionen, auf denen Container beruhen, nämlich den Namespaces und den cgroups (Control Groups), ihre Aufgaben richtig zu?

  1. ANamespaces: trennen, was ein Prozess sieht (Prozess-IDs, Netzwerk, Mounts usw.); cgroups: begrenzen und erfassen den Verbrauch von Ressourcen wie CPU und Arbeitsspeicher
  2. BNamespaces: begrenzen und erfassen den Verbrauch von Ressourcen wie CPU und Arbeitsspeicher; cgroups: trennen, was ein Prozess sieht (Prozess-IDs, Netzwerk, Mounts usw.)
  3. CNamespaces: starten für jeden Container einen eigenen Kernel, um die Container voneinander zu isolieren; cgroups: erzeugen für jeden Container eine virtuelle CPU und emulieren die Hardware
Antwort und Erläuterung anzeigen

Antwort: A. Namespaces: trennen, was ein Prozess sieht (Prozess-IDs, Netzwerk, Mounts usw.); cgroups: begrenzen und erfassen den Verbrauch von Ressourcen wie CPU und Arbeitsspeicher

Ein Container ist ein gewöhnlicher Prozess, der auf dem Kernel des Hosts läuft und durch zwei Mechanismen isoliert wird. Namespaces teilen Prozess-IDs, Netzwerk, Mounts (die Sicht auf das Dateisystem), Hostnamen usw. in Gruppen auf, sodass die Prozesse in einem Container nur ihren eigenen Teil sehen. cgroups begrenzen die CPU-Zeit und die Speichermenge, die eine Gruppe von Prozessen nutzen kann, und erfassen den Verbrauch. Beides sind Kernelfunktionen; ein Container startet also weder einen eigenen Kernel, noch emuliert er Hardware.

  1. Auf einem Linux-Host wird mit Docker ein Container aus einem Image gestartet, das auf einer anderen Distribution als der des Hosts beruht, und darin werden uname -r (zeigt das Release des Kernels) und cat /etc/os-release (zeigt Angaben zur Distribution) ausgeführt. Welche Beschreibung der Ergebnisse ist richtig?
  2. Welche Beschreibung des Verhältnisses zwischen einem Container-Image und einem Container ist richtig?
  3. Welcher Weg, die Software auf Produktionsservern zu aktualisieren, entspricht dem Gedanken der Immutable Infrastructure?

Übungsfragen zu Grundlagen von Cloud und Containern

Wichtige Begriffe erklärt

Container
Ausführungseinheit, die eine Anwendung mit den Bibliotheken und Einstellungen bündelt, die sie benötigt, und sie isoliert von anderen Prozessen ausführt, während sie sich den Kernel des Host-Betriebssystems teilt. Unter Linux wird sie aus Namespaces, die die Sicht auf Prozess-IDs, Netzwerk, Mounts usw. trennen, und cgroups, die den Verbrauch von CPU und Arbeitsspeicher begrenzen, aufgebaut. Ein Container ist leichter und startet schneller als eine virtuelle Maschine, die ein ganzes Betriebssystem bootet; da er sich den Kernel teilt, kann er aber keinen Kernel einer anderen Betriebssystemart als der des Hosts ausführen. Container werden aus Container-Images erzeugt und mit Werkzeugen wie Docker und Kubernetes erstellt und verwaltet.
Container-Image
Schreibgeschützte Vorlage, aus der Container erzeugt werden. Sie legt die Dateien einer Anwendung wie ausführbare Dateien, Bibliotheken und Einstellungen in Schichten übereinander und fügt eine Konfiguration wie den Startbefehl hinzu; einen Betriebssystemkernel enthält sie nicht. Images werden aus einem Dockerfile o. Ä. gebaut und über Registries gespeichert und verteilt. Ein Image wird über Repository-Namen und Tag angegeben (zum Beispiel web:1.4) oder eindeutig über einen aus seinem Inhalt berechneten Digest (sha256:…). Identische Schichten werden von mehreren Images gemeinsam genutzt.
Hypervisor
Software, die mehrere virtuelle Maschinen auf einem Computer betreibt. Sie teilt den Betriebssystemen der VMs CPU, Speicher und Geräte zu und isoliert sie voneinander. Auch Virtual Machine Monitor genannt.
Docker
Weit verbreitete Software-Suite zum Bauen von Container-Images, zum Austausch von Images mit Registries sowie zum Starten und Verwalten von Containern. Sie baut Images aus den Anweisungen eines Dockerfiles und startet Container mit docker run. Mit -p veröffentlicht sie Ports, in Volumes und Bind-Mounts hält sie Daten, und sie konfiguriert Netzwerke. Die Formate von Images und Containern sind als Spezifikationen der OCI (Open Container Initiative) standardisiert, sodass sich dieselben Images auch mit anderen Werkzeugen als Docker nutzen lassen.
Kubernetes
Orchestrierungsplattform, die Container auf einem Cluster aus vielen Maschinen (Nodes) platziert, ihre Anzahl hält, sie aktualisiert und Endpunkte für sie bereitstellt. Die Nutzer deklarieren mit Ressourcen wie Deployments und Services einen Soll-Zustand, und Controller beobachten den Ist-Zustand und nähern ihn der Deklaration an (Abgleich, Reconciliation). Die kleinste Einheit ist der Pod; verlorene Pods werden automatisch neu erzeugt, und Rolling Updates sowie lastabhängiges Autoscaling werden unterstützt. Auch als K8s abgekürzt.
Immutable Infrastructure (unveränderliche Infrastruktur)
Betriebsansatz, bei dem einmal erzeugte Server (virtuelle Maschinen oder Container) nie verändert werden; ist ein Update nötig, werden aus einem Image mit der Änderung neue erzeugt und eingewechselt, und die alten werden verworfen. Da jeder Server aus demselben Image entsteht, driften die Konfigurationen nicht durch angehäufte manuelle Unterschiede auseinander, und die Rückkehr zum vorherigen Image stellt den alten Zustand einfach wieder her. Was erhalten bleiben soll, etwa Logs und Daten, wird in Speicher oder Datenbanken außerhalb der Server abgelegt.

Verwandte Vergleiche