Bare Metal versus virtuelle Maschinen als Kubernetes-Host

Overhead und Leistung

Bei der Bereitstellung von Cloud-nativen Anwendungen mit Kubernetes auf physischen Servern – auch als Bare-Metal-Server bekannt – entfällt der mit einem Hypervisor verbundene Overhead. Bei einer Bare-Metal-Bereitstellung stehen alle Hardwareressourcen ausschließlich für die containerisierten Workloads zur Verfügung. Jeder CPU-Zyklus geht an die Geschäftsanwendungen. Darüber hinaus werden Netzwerkpakete sowie Lese- und Schreibvorgänge auf dem Speicher direkt und ohne Eingriff des Hypervisors verarbeitet.

Bei der Sparsamkeit holen die virtuellen Maschinen allerdings zunehmend auf. Die Fortschritte bei der VM-Optimierung in den letzten 20 Jahren haben den für die heutigen Hypervisoren erforderlichen Overhead erheblich reduziert. Es könnte somit sein, dass die Flexibilität, die Sie durch Virtualisierung bekommen, den Overhead mehr als wett macht.

VMware behauptet beispielsweise, dass seine Servervirtualisierungssoftware vSphere 7 bei der nativen Ausführung von Kubernetes-Workloads auf einem ESXi-Hypervisor eine 8 Prozent bessere Leistung als ein Bare-Metal-Server bietet. Der ESXi-CPU-Scheduler stellt sicher, dass die Speicherzugriffe der Pods innerhalb ihrer nicht einheitlichen Speicherzugriffsdomänen stattfinden, was laut VMware die Lokalisierung im Vergleich zum Prozess-Scheduler von Linux verbessert.

Mit Kubernetes in VMs haben IT-Teams außerdem die Wahl zwischen mehreren Knotengrößen für verschiedene Bereitstellungsarten. Mit Bare-Metal hat der gesamte Server Zugriff auf Ressourcengruppen, die den laufenden Pods zur Verfügung stehen. Bei virtuellen Maschinen ist es einfacher, die Ressourcen innerhalb der einzelnen VMs einzugrenzen, und Hypervisoren verwalten die Ressourcen in der Regel gut über die gesamte Umgebung hinweg. Wenn hingegen alle Workloads in Kubernetes auf Bare-Metal-Knoten laufen und keine anderen VM-gehosteten Workloads zu berücksichtigen sind, bietet Kubernetes eine detailliertere Steuerung bis auf Pod-Ebene.

Bereitstellung und Verwaltbarkeit

Ein klarer Pluspunkt für VMs ist ihre einfache Bedienung. Obwohl VM-Plattformen zusätzliche Arbeit erfordern, um sowohl einen Hypervisor als auch VMs zu installieren, ist die Bereitstellung von Hypervisoren in der Regel schnell erledigt, und Aktualisierungen sind seltener nötig als bei vielen anderen Betriebssystemen.

Sobald Hypervisoren installiert sind, sind Sie bei den virtuellen Maschinen komplett unabhängig vom Betriebssystem. Fügen Sie Hardware hinzu, bleiben alle VMs intakt und lassen sich problemlos zwischen Hypervisoren austauschen. Das vereinfacht das Plattformmanagement und verhindert Ausfallzeiten während der Hardwarewartung.

Sie können virtuelle Maschinen als Kubernetes-Knoten anhand vorgefertigter Linux-Vorlagen erstellen. Wer in die Benutzerfreundlichkeit investieren möchte, kann eine Lizenz für vSphere mit VMware Tanzu erwerben, mit sich Pods direkt auf ESXi ausführen lassen. Das ist besonders eine gute Idee, wenn Sie sowieso bereits vSphere mit VMs betreiben und ihrer Umgebung Kubernetes-Workloads hinzufügen möchten.

Damit schaffen Sie jedoch kein vollständig konformes Kubernetes-Cluster, da Sie bestimmte Funktionen – wie benutzerdefinierte Ressourcen und Plugins von Drittanbietern – auf der Plattform nicht realisieren können. Sie stellen jedoch mit VMware Tanzu vollständig kompatible Kubernetes-Cluster in VMs auf ESXi als Linux-Maschinen bereit, wodurch Sie Kubernetes-Cluster leichter skalierbar machen.

Abbildung 1 zeigt eine Kubernetes-Bereitstellung mit drei Master-Knoten und 12 Worker-Knoten, die über den vSphere-Client gesteuert werden.

Wenn Sie gerade erst mit Kubernetes anfangen, erscheint es logisch, Cloud-native Anwendungen in VMs neben bestehenden Workloads auszuführen: Sie brauchen keine dedizierten Hardwareressourcen, und neue Hardware, die Sie hinzufügen, ist für alle Workload-Typen verfügbar. Bei Bare-Metal-Servern wird nur Kubernetes mit Containern auf diesen Hosts ausgeführt.

Ein weiterer Vorteil von Kubernetes in VMs ist, dass die Administratoren, die den Hypervisor verwalten, sich im Laufe der Zeit mit der neuen Plattform vertraut machen können, statt mit Bare-Metal einfach ins kalte Wasser geworfen zu werden.

Hohe Verfügbarkeit

Hypervisors schützen die virtuellen Maschinen und starten im Falle eines Ausfalls schnell und automatisch auf einem anderen Host neu. IT-Teams sollten jedoch vorsichtig sein, wenn sie mehrere VMs auf demselben Hypervisor platzieren: Wenn eine Maschine ausfällt, sind die Folgen viel schwerwiegender als beim Verlust eines einzelnen Bare-Metal-Hosts, da mehr Workloads verloren gehen. Diese Einschränkung kann in der Regel mit Anti-Affinitätsregeln überwunden werden, die VMs auf verschiedenen Hosts trennen.

Um eine hohe Verfügbarkeit zu gewährleisten, sollten Sie die Umgebung so konfigurieren, dass Sie Ausfälle sowohl auf der Kubernetes- als auch auf der VM-Ebene vermeiden. Im Falle eines Ausfalls sollte jeweils nur eine Plattform versuchen, die Workloads wieder zum Laufen zu bringen.

Groß angelegte Implementierungen profitieren von Bare-Metal-Servern

Kubernetes hat seinen Ursprung bei Google, das Rechenzentren in großem Umfang betreibt. Die meisten Unternehmen bewältigen zwar keine Implementierungen dieser Größenordnung, doch wenn Kubernetes das Herzstück einer gesamten Infrastruktur auf Hunderten oder gar Tausenden von Hosts bildet, sind Bare-Metal-Server wahrscheinlich die beste Wahl.

Mit Bare-Metal-Servern entfallen die Ausgaben für Hypervisor-Lizenzen. Unternehmen mit groß angelegten Implementierungen haben in der Regel ohnehin erfahrene Administratoren an Bord, die sich auf die Arbeit mit einer einzigen Plattform spezialisiert haben.

Sobald eine große Anzahl von Bare-Metal-Servern vorhanden ist, kann Kubernetes die Workloads auf diesen Hosts ausgleichen und Ausfälle bewältigen. Diese homogene Umgebung ist in der Regel einfacher zu verwalten. In einer heterogeneren Umgebung ist es sinnvoller, Kubernetes in VMs auszuführen, als es in die bestehende Umgebung zu integrieren.