In der heutigen Zeit des Cloud-Computing sind Ihnen sicher schon einmal die Begriffe virtuelle Maschinen (VMs) und Container begegnet. Beide spielen beim Cloud-Computing sowie bei herkömmlichen (einschließlich lokalen) Rechenzentren eine wichtige Rolle. Dieser Artikel erläutert die Unterschiede zwischen den beiden Konzepten und ihre jeweiligen Vor- und Nachteile. Zudem gehen wir auf einige Anwendungsszenarien ein, für die sich die beiden Konzepte jeweils eignen.

Die wichtigsten technischen Unterschiede

Schauen wir uns zu Beginn die technischen Unterschiede an. Dazu müssen wir zunächst wissen, welche Aufgaben der Kernel eines Betriebssystems leistet. Der Kernel ist für alle grundlegenden Software-Funktionen verantwortlich, zum Beispiel:

• Faire Zuweisung von CPU-Zeit zur Verarbeitung
• Verwaltung des Arbeitsspeichers
• Gewährung von Zugriff auf Hardware-Geräte wie Festplatten (magnetisch oder SSD), Tastaturen, Mäuse, Monitore, Netzwerkschnittstellen usw.
• Bereitstellung einer Abstraktionsschicht für den Zugriff auf Festplatten, allgemein bekannt als „Dateisystem“
• Verwaltung prozessübergreifender Kommunikation
• Implementierung der verschiedenen Netzwerkschichten im gesamten Netzwerk (IP, TCP, UDP usw.)
• Und viele andere Aspekte, deren Aufzählung diesen Rahmen sprengen würde

Es sind also ziemlich viele Funktionen, weshalb Kernel (z. B. der Linux-Kernel) sehr umfangreich sind und Millionen Zeilen Code umfassen.

Was ist nun der wichtigste technische Unterschied zwischen einer VM und einem Container? Eine VM läuft auf ihrem eigenen Kernel, während ein Container den Kernel des Hosts verwendet. Eine kleine Darstellung veranschaulicht dies:

Abbildung 1. Container und VMs im Vergleich

Container werden zum Teil als „schlanke VMs“ bezeichnet, was nicht ganz korrekt ist, denn in ihnen laufen sehr viel weniger Prozesse – meist nur ein einziger. Ein vollständiges Betriebssystem in einem Container auszuführen, ist sehr schwierig und häufig schlicht unmöglich.

Eine VM dagegen „glaubt“, ein eigenständiges Betriebssystem zu sein, das auf echter Hardware läuft. Sie weiß nicht, dass die Hardware nur durch den sogenannten Hypervisor – eine Software, die im Kernel läuft – simuliert wird.

Über VMs

Eine VM ist im Prinzip ein Betriebssystem (das Gast-Betriebssystem), das auf einem anderen Betriebssystem (dem Host-Betriebssystem) läuft, das wiederum auf der eigentlichen Hardware läuft. Um VMs ausführen zu können, benötigt das Host-Betriebssystem einen Hypervisor. Dieser stellt eine Virtualisierungsebene inklusive simulierter Hardware bereit, sodass das Gast-Betriebssystem glaubt, es laufe auf echter Hardware. Das Gast-Betriebssystem verhält sich ansonsten wie ein ganz normales Betriebssystem.

Wichtiger Hinweis: Wenn Sie eine Instanz bei einem Cloud-Anbieter ausführen, erzeugt der Cloud-Anbieter in Wirklichkeit eine VM.

VMs bieten folgende Vorteile:

• Das Gast-Betriebssystem verhält sich genauso wie ein normales Betriebssystem und weiß nicht, dass es nur auf einem Hypervisor und nicht auf echter Hardware läuft.
• Eine VM kann als einzelne Datei abgespeichert und einfach an einen beliebigen Ort verschoben oder kopiert werden.

Dies sind die Nachteile:

• VMs benötigen viel Speicherplatz, Rechenleistung und Arbeitsspeicher, da sie eigenständige Betriebssysteme sind.
• Zudem haben sie aus dem gleichen Grund einen hohen Wartungsaufwand. Dies lässt sich jedoch durch die Einrichtung einer unveränderlichen Infrastruktur vermeiden.
• VMs sind aufgrund der Hypervisor-Ebene etwas langsamer als das Gast-Betriebssystem, was sich heutzutage jedoch nur noch minimal auswirkt.
• Prinzipiell dauert der Start bei VMs etwas länger, da sie viele Prozesse und Services umfassen.

Über Container

Kommen wir nun zu Containern. Um Container besser zu verstehen, hilft es, sie sich als einen oder mehrere Prozesse vorzustellen, die auf dem Host-Kernel laufen. Allerdings laufen sie dort in einer isolierten Umgebung, sodass die Prozesse nicht sehen können, was sonst auf dem Kernel läuft. Die Prozesse innerhalb eines Containers sehen sich gegenseitig, können jedoch nicht die Prozesse in anderen Containern oder auf dem Host-Kernel sehen.

Um Container ausführen zu können, benötigt der Host-Kernel eine bestimmte Software-Technologie, mit der die Prozesse wie oben beschrieben voneinander isoliert werden können. Der Linux-Kernel bietet diese Technologie unter der Bezeichnung „Namespaces“.

Wie Sie nun erkennen können, ist es unmöglich, ein komplettes Betriebssystem in einem Container auszuführen, denn es gibt nur einen laufenden Kernel: den des Host-Betriebssystems. Folglich sollten Container nicht als „schlanke VMs“, sondern eher als eine Art abgeschlossene Behälter betrachtet werden, in denen Prozesse ausgeführt werden. Die Prozesse laufen innerhalb des Behälters, können den Behälter jedoch nicht verlassen.

Ohne zu sehr ins Detail zu gehen: Der Host-Kernel kann so eingestellt werden, dass die Prozesse in einem Container die Ressourcen außerhalb „sehen“ und darauf zugreifen können. Dies stellt jedoch ein großes Sicherheitsrisiko dar und sollte möglichst vermieden werden.

Welche Vorteile bieten Container?

• Container sind schlank, da sie nur die Prozesse ausführen, die für die jeweilige Workload notwendig sind, d. h. Sie sparen im Vergleich zu VMs Rechenleistung, Arbeitsspeicher und Speicherplatz.
• In der Regel haben Container eine kurze Anlaufzeit, doch dies hängt davon ab, mit welcher Software sie laufen. Die Anlaufzeit ist jedoch immer kürzer als wenn dieselbe Software in einer VM ausgeführt würde.
• Es gibt öffentliche Bibliotheken wie Docker Hub, die eine Vielzahl an Container-Images für zahlreiche Anwendungen bereitstellen.
• Container haben im Vergleich zu VMs eine kleinere Angriffsfläche.

Sie haben jedoch auch einige Nachteile:

• In Containern können keine vollständigen Betriebssysteme ausgeführt werden.
• Theoretisch kann ein Exploit in einem Container zu Exploits in anderen Containern führen. Allerdings kommt dies heutzutage selten vor, da die Namespace-Technologie von Linux (die zur Ausführung von Containern genutzt wird) mittlerweile äußerst ausgereift und sicher ist.
• Container lassen sich nicht in eine einzelne Dateien abspeichern und verschieben.
• Das Root-Dateisystem ist kurzlebig, d. h. alles, was in diesem Dateisystem geschrieben wird, wird mit dem Beenden des Containers zerstört.

Unterschiede zwischen VMs und Containern

Kommen wir nun zu den praktischen Unterschieden zwischen VMs und Containern. Der erste offensichtliche Unterschied ist, dass Container in VMs laufen können, aber nicht umgekehrt.

VMs und Container erfüllen unterschiedliche Zwecke. Eine VM führt ein vollständiges Betriebssystem aus und ist auf eine langfristige Nutzung ausgelegt. Ein Container hingegen führt eine bestimmte Workload aus und ist kurzlebig und unveränderlich. Aus diesem Grund muss ein Container, wenn er langfristig gespeichert werden soll (gemeint ist eine persistente Speicherung, die bspw. auch den Neustart des Containers übersteht), Volumes einbinden, die getrennt deklariert und verwaltet werden müssen.

Allgemein können Container flexibler als VMs eingesetzt werden, da sie nur für eine einzelne Aufgabe bestimmt sind. Wenn Ihr Use Case VMs erfordert, wäre es also schwierig, stattdessen Container zu verwenden. Sollte Ihr Use Case jedoch Container erlauben, haben Sie in der Regel die Wahl zwischen den beiden Technologien (obwohl sich die Architekturen jeweils erheblich unterscheiden würden).

Sie haben sicher von Tools zur Container-Orchestrierung (z. B. Kubernetes) gehört. Wenn Sie Container nutzen, werden Sie möglicherweise ein solches Tool benötigen, das etwas Einarbeitung erfordert und Sicherheitsrisiken mit sich bringt. Bei VMs von Ihrem Cloud-Anbieter benötigen Sie in der Regel nur die vom Anbieter bereitgestellten Verwaltungstools, z. B. automatisch skalierende Gruppen und Load Balancer. Beim Einsatz von VMs in einem herkömmlichen Rechenzentrum werden Sie wahrscheinlich ein VM-orientiertes Orchestrierungstool wie VMware vSphere nutzen müssen, das ebenfalls etwas Einarbeitungszeit erfordert (die im Vergleich zu Tools zur Container-Orchestrierung möglicherweise länger ist).

Und nicht zuletzt sind Container besser zur Einrichtung eines Service-Mesh geeignet. Dabei handelt es sich um eine Architektur, die alternativ zu internen Load Balancern eingesetzt wird.

Abbildung 2. Service-Mesh und Load Balancer im Vergleich

Aus den Darstellungen oben lässt sich leicht erkennen, dass die zweite Architektur ressourcenintensiver als die erste ist. Ein Service-Mesh lässt sich beispielsweise mithilfe von HashiCorp Consul erstellen. Die Konfiguration ist jedoch umständlicher als zum Beispiel mit Istio auf einem Kubernetes-Cluster.

Sicherheitsaspekte

Obwohl sie sich auf den ersten Blick ähneln, haben VMs und Container sehr unterschiedliche Sicherheitsanforderungen. Zunächst sind die Software-Schichten, auf denen die beiden Technologien basieren (Hypervisoren und Kernel-Namespaces), heute sehr ausgereift und sehr sicher. Sie sollten in puncto Sicherheit daher keine Probleme bereiten.

In VMs läuft im Prinzip ein vollständiges Betriebssystem, sodass alle Maßnahmen zur Absicherung eines Gesamtsystems auch für VMs erforderlich sind. Dazu zählen zum Beispiel folgende:

• Härtung des Betriebssystems
• Implementierung von Virenschutz-Software
• Regelmäßiges und zeitnahes Patchen (kann durch Nutzung einer unveränderlichen Infrastruktur vermieden werden)
• Ausführen von Prozessen als normale Benutzer anstatt Root-Benutzer
• Härtung des SSH-Servers
• Konfiguration der Firewall
• Verringerung der Angriffsfläche (durch Entfernen unnötiger Software)
• Einsatz von Scannern, um Schwachstellen bei der Erstellung des Images zu identifizieren
• Einsatz von Tools zur Identifizierung von Schwachstellen zur Laufzeit

Wie Sie anhand dieser Liste sehen können, ist die Absicherung einer VM sehr aufwändig. Vieles davon wird bei der Erstellung des Images erledigt, das die VM ausführt. Doch ein Großteil der Arbeit geschieht während der Laufzeit, um Schwachstellen und Kompromittierungen zu erkennen.

Im Vergleich dazu ist die Absicherung von Containern recht einfach:

• Der Container sollte niemals im privilegierten Modus laufen.
• Die Prozesse sollten als normale Benutzer ohne Root-Rechte laufen.
• Die Dateisystemberechtigungen müssen so restriktiv wie möglich sein.
• Nutzen Sie Scanner, um bei der Erstellung des Images vorhandene Schwachstellen zu identifizieren.

Es gibt weitere Sicherheitsaspekte in Bezug auf die Laufzeit von Containern, die sich im Vergleich zu VMs meist jedoch einfacher bewältigen lassen.

In beiden Fällen gelten alle genannten Maßnahmen zur Absicherung des Host-Betriebssystems für den oben beschriebenen Fall mit VMs auch für das Host-Betriebssystem, auf dem die VMs bzw. Container laufen werden.

CrowdStrike bietet Ihnen verschiedene Lösungen, mit denen Sie Ihre Workloads vor Viren und anderer schädlicher Software sowie Netzwerkangriffen schützen können.

Auf technischer Ebene sind die Unterschiede zwischen VMs und Containern leicht nachzuvollziehen. Die jeweiligen Vor- und Nachteile werden deutlicher, wenn wir uns die relevanten Anwendungsszenarien für die Technologien anschauen.

Seit der Veröffentlichung von Docker hat die Nutzung von Containern stetig zugenommen. Sie lassen sich flexibel einsetzen und sind unveränderlich. Zudem bieten sie in Kombination mit einem leistungsfähigen Orchestrierungstool wie Kubernetes deutliche Vorteile gegenüber VMs. Aus diesem Grund setzen sich Container langsam durch, auch wenn einige Unternehmen noch lange Zeit mit herkömmlichen VMs arbeiten werden.