Container oder virtuelle Maschine: der Unterschied in einem Satz und seine vier Folgen

Du willst auf Proxmox etwas Neues laufen lassen, und es gibt zwei Möglichkeiten. Beide betreiben ein Linux, beide stehen im Panel nebeneinander, beide sehen aus, als täten sie dasselbe.

Die Wahl fällt meist aus Ressourcengewohnheit: "ein Container ist leichter". Stimmt, doch das sollte nicht entscheiden.

Der Unterschied steckt in einem Satz: eine virtuelle Maschine bringt ihren eigenen Kern mit, ein Container nutzt den des Servers. Alles Wissenswerte folgt aus diesem Satz.

Erste Folge: wo die Grenze verläuft

Die Grenze der virtuellen Maschine zieht die Hardware. Die Grenze des Containers zieht der Kern des Servers.

Das heißt nicht, ein Container sei "schwach"; es heißt, wo die Grenze verläuft. Will ein Fehler in Software innerhalb eines Containers den Server erreichen, muss er am eigenen Kern des Servers vorbei. In einer virtuellen Maschine muss er an einer Mauer auf Hardwareebene vorbei.

Die praktische Frage lautet: wie sehr vertraust du dem, was du laufen lässt? Für einen Dienst, den du selbst geschrieben oder seit Jahren im Einsatz hast, ist ein Container völlig geeignet. Für etwas Heruntergeladenes, das du nicht ganz durchschaust, ist eine virtuelle Maschine der bessere Ort.

Zweite Folge: nicht alles läuft im Container

Nichts, was seinen eigenen Kern braucht, läuft in einem Container. Software, die eine andere Kernversion will, ein Werkzeug, das Kernmodule lädt, ein Betriebssystem, das kein Linux ist: alle verlangen eine virtuelle Maschine.

Das ist keine Vorliebe, sondern eine unmittelbare Folge des obigen Satzes. Nutzt ein Container den Kern des Servers, kannst du von ihm nicht verlangen, diesen Kern zu ändern.

Dritte Folge: Wartung berührt beide unterschiedlich

Das ist die am wenigsten bekannte Folge und die, die am ehesten wehtut.

Aktualisierst du die Maschinen-Engine, sind laufende Maschinen nicht betroffen. Die neue Engine gilt für Maschinen, die nach dieser Aktualisierung gestartet werden. Eine Wartungsnacht kann also still über deine laufenden Maschinen hinweggehen.

Aktualisierst du die Container-Laufzeitschicht, können laufende Container betroffen sein, denn sie alle teilen sich diese Schicht. Während der Aktualisierung kann die geteilte Dateischicht neu eingehängt werden, und in den Containern können kurzzeitige Zugriffsfehler auftreten.

Das ist keine Produktmeinung, sondern die unmittelbare Folge desselben einen Satzes: aktualisierst du etwas Geteiltes, spüren es alle, die es teilen.

Vierte Folge: Bewegungsfreiheit

Eine virtuelle Maschine lässt sich im Betrieb auf einen anderen Knoten verschieben. Ein Container nicht: er wird heruntergefahren, verschoben und neu gestartet.

Steht also Arbeit, die keine Unterbrechung verträgt, in einem Container, wird sie in Wartungsnächten stillstehen. Das gehört bei der Entscheidung über die Platzierung mit auf die Waage.

Die praktische Regel

Wähle einen Container, wenn das, was du betreibst, ein gewöhnlicher Linux-Dienst ist, den du auch auf dem Server laufen lassen könntest, wenn du ihm vertraust und wenn er eine kurze Unterbrechung verträgt.

Wähle eine virtuelle Maschine, wenn ein eigener Kern nötig ist, wenn sie während der Wartung nicht unterbrochen werden darf, oder wenn du dem, was du betreibst, nicht ganz traust.

Der Ressourcenunterschied kommt nach diesen drei Prüfungen. Dass ein Container weniger Speicher braucht, stimmt, doch die Kosten eines am falschen Ort stehenden Containers übersteigen diese Ersparnis um ein Vielfaches.

Was Atlas tut

Atlas trägt diese Unterscheidung nicht als Slogan, sondern als Verhalten.

In der Bewertung von Aktualisierungen werden die Maschinen-Engine und die Container-Laufzeitschicht getrennt behandelt. Wird die Maschinen-Engine aktualisiert, liegt die Antwort für laufende Maschinen auf der Informationsebene: sie sind nicht betroffen, die neue Engine gilt für später gestartete. Wird die Containerschicht aktualisiert, steigt die Stufe zur Warnung, und der Grund wird ausgeschrieben: die geteilte Schicht kann neu eingehängt werden, erwäge, kritische Container kurz anzuhalten.

Dieselbe Unterscheidung erscheint in der Verschiebeplanung: für Container wird das Verschieben im Betrieb nicht als Möglichkeit angeboten, stattdessen wird die Kette herunterfahren, verschieben, starten genannt.

Das Produkt stellt die beiden also nicht als "zwei Ausprägungen derselben Sache" dar. Sie verhalten sich verschieden, also werden sie verschieden beschrieben.