Aufbau einer privaten Cloud auf Bare Metal mit Kubernetes und Talos Linux

In einem Beitrag im Kubernetes Blog vom April 2024 skizzierte Andrei Kvapil von Ænix eine Methode zum Aufbau einer privaten Cloud-Infrastruktur ausschließlich mit Open-Source-Technologien. Der Leitfaden konzentriert sich darauf, Bare-Metal-Server für die Hostung verwalteter Kubernetes-Cluster vorzubereiten und dabei traditionelle Virtualisierungsschichten wie OpenStack zu umgehen.

Was passiert ist

Kvapil beschrieb den Prozess der Erstellung von Cozystack, einer Plattform, die darauf ausgelegt ist, Mandanten-Kubernetes-Cluster direkt auf physischer Hardware auszuführen. Dieser Ansatz stellt die gängige Praxis infrage, OpenStack zur Verwaltung von Bare-Metal-Servern einzusetzen, bevor Kubernetes darüber installiert wird. Stattdessen nutzt er Kubernetes selbst, um die Komplexität des Infrastrukturmanagements zu bewältigen, mit dem Ziel, die Anzahl komplexer Systeme im Ökosystem zu reduzieren.

Der Artikel dient als erster Teil einer Serie, die diese Architektur detailliert beschreibt. Er behandelt die erforderlichen Grundlagen zur Vorbereitung von Rechenzentren, einschließlich der Ausführung virtueller Maschinen, der Netzwerkisolierung und der Einrichtung fehlertoleranter Speicherlösungen. Das Ziel ist die Bereitstellung voll funktionsfähiger Kubernetes-Cluster, die dynamische Volumenzuweisung, Load Balancer und Autoscaling unterstützen, ohne auf externe Cloud-Anbieter angewiesen zu sein.

Wie es funktioniert

Der wesentliche Unterschied liegt darin, wie Kubernetes in der Cloud im Vergleich zu Bare Metal operiert. In öffentlichen Clouds werden Dienste wie persistente Volumes, Load Balancer und die Knotenbereitstellung extern vom Anbieter verwaltet. Dies ermöglicht es, Knoten als ephemere Ressourcen zu behandeln, die leicht gelöscht und neu erstellt werden können. Auf Bare Metal müssen diese Dienste innerhalb des Clusters laufen, was Updates und Wartung erheblich komplexer macht, da physische Server nicht einfach wie virtuelle Maschinen gelöscht und ersetzt werden können.

Um dies anzugehen, empfiehlt der Leitfaden die Verwendung von Talos Linux, einem spezialisierten Betriebssystem für Kubernetes. Talos ermöglicht es, die gesamte Systemkonfiguration in einer einzigen Datei zu definieren. Dieser deklarative Ansatz erlaubt Updates von Kernel-Modulen und Kubernetes-Komponenten, ohne dass eine vollständige Neukreation des Knotens oder eine Dienstmigration erforderlich ist. Das Team bei Ænix nutzt diese Methode, um notwendige Kernel-Module wie ZFS und DRBD in ein benutzerdefiniertes Systemimage zu bündeln.

Für die Bereitstellung wird das PXE-Bootverfahren genutzt. Temporäre DHCP- und PXE-Server laufen in Containern, um das benutzerdefinierte Talos-Linux-Image an physische Knoten zu liefern. Ein Bootstrap-Skript initialisiert anschließend die Knoten und richtet die anfängliche Kubernetes-Control-Plane ein. Sobald der Basiscluster läuft, werden GitOps-Tools wie FluxCD verwendet, um Systemkomponenten zu installieren und zu verwalten, wodurch sichergestellt wird, dass der Cluster seinen gewünschten Zustand über deklarative Helm-Charts beibehält.

Wichtige Details

• Der Leitfaden plädiert dafür, OpenStack durch einen Kubernetes-nativen Ansatz zu ersetzen, um die Komplexität des Ökosystems zu reduzieren.
• Talos Linux wird als Basis-Betriebssystem aufgrund seines unveränderlichen, deklarativen Konfigurationsmodells verwendet.
• Benutzerdefinierte Systemimages werden mit Docker erstellt, um spezifische Kernel-Module wie ZFS, DRBD und OpenvSwitch einzuschließen.
• Das PXE-Bootverfahren wird eingesetzt, um das OS-Image während der ersten Bereitstellung auf Bare-Metal-Server zu liefern.
• FluxCD wird gegenüber ArgoCD empfohlen, um Systemkomponenten zu verwalten und die Einheitlichkeit des Clusters über GitOps sicherzustellen.
• Der anfängliche Bootstrap-Prozess kann einen funktionalen Kubernetes-Cluster auf Bare Metal in etwa fünf Minuten bereitstellen.

Warum das wichtig ist

Für Engineering-Teams, die ihre eigene Hardware verwalten, bietet dieser Ansatz einen Weg zu cloud-ähnlicher Agilität ohne den Overhead der Wartung separater Virtualisierungsplattformen. Indem die Infrastruktur als Code behandelt und unveränderliche Betriebssysteme verwendet werden, können Teams das Risiko von Konfigurationsdrifts reduzieren und den Update-Prozess vereinfachen. Dies ist besonders relevant für Organisationen, die strenge Kontrolle über ihre Daten und Hardware benötigen, aber dennoch die betrieblichen Vorteile von Kubernetes nutzen möchten.

Allerdings verlagert diese Methode erhebliche Verantwortung auf das Infrastruktur-Team. Im Gegensatz zu verwalteten Cloud-Diensten müssen Ingenieure Netzwerk, Speicher und Sicherheits-Patches selbst handhaben. Die Komplexität verschiebt sich vom Management mehrerer unterschiedlicher Systeme hin zu einem tiefgreifenden Verständnis des Zusammenspiels zwischen Kubernetes, dem zugrunde liegenden Betriebssystem und der physischen Hardware. Dies erfordert ein höheres Maß an Expertise, kann jedoch zu einer schlankeren und kosteneffizienteren Infrastruktur für groß angelegte Bereitstellungen führen.

Was Sie tun können

• Bewerten Sie Talos Linux als Basis-OS für Ihre Bare-Metal-Kubernetes-Cluster, um das Knotenmanagement zu vereinfachen.
• Implementieren Sie GitOps-Praktiken unter Verwendung von FluxCD, um Systemkomponenten und Helm-Charts deklarativ zu verwalten.
• Erstellen Sie benutzerdefinierte OS-Images, die alle notwendigen Kernel-Module und Firmware für Ihre spezifische Hardware enthalten.
• Richten Sie eine PXE-Boot-Umgebung ein, um die erste Installation des Betriebssystems auf physischen Servern zu automatisieren.
• Gestalten Sie Ihre Infrastruktur so, dass physische Knoten so weit wie möglich als unveränderlich behandelt werden, um In-Place-Updates zu minimieren.
• Beginnen Sie mit einem kleinen Pilotcluster, um den Bootstrap-Prozess zu testen und die Netzwerk- und Speicherkonfigurationen zu validieren.