© Aleksandr Prokopenko / 123RF.com

Wer sich mit Kubernetes befasst, stößt auf monströse Setups, die als eierlegende Wollmilchsau agieren, Einsteiger aber völlig überfordern. Mit weniger Aufwand gelangen Sie schneller ans Ziel.

Ganz gleich, wegen welcher technischen Probleme man bei Red Hat anfragt, fast immer empfiehlt der Distributor eine Lösung aus der OpenShift-Familie: Container machen alles einfacher, besser und schneller – zumindest lautet so das rosige Versprechen der Hochglanzprospekte.

Doch gerade OpenShift liefert ein hervorragendes Beispiel für ein Werkzeug, das nach dem Ausrollen immer mehr Komponenten nachzieht, um verschiedene Teilaspekte des Container-Betriebs abzudecken. Persistenter Speicher? Kein Problem mit OpenShift Data Foundation (ODF). Sicherheit? Red Hat Advanced Cluster Security for Kubernetes (RHCSfK) ist zur Stelle und liefert.

Jede dieser Komponenten, egal, ob OpenShift selbst oder ein Zusatz-Tool, kommt mit eigenen Systemanforderungen daher und hat wieder andere Komponenten im Schlepptau, die es ebenfalls erst einmal auszurollen gilt (Abbildung 1). Bevor der Admin auf diesem Weg zu einem produktionsreifen Kubernetes gelangt, hat er Red Hat sowie dem Hardwareverkäufer der Wahl eine Menge Geld überwiesen, sich durch unzählige Seiten Dokumentation gekämpft und vermutlich wochenlang darauf hingearbeitet, alle OpenShift-Zusätze und OpenShift selbst in einen produktionsreifen Zustand zu versetzen. Da lässt sich gut nachvollziehen, dass vielen Admins die Lust aufs Containern vergeht, bevor sie überhaupt richtig eingesetzt hat.

Abbildung 1: OpenShift liefert alle nötigen Komponenten für den Kubernetes-Betrieb, überfordert mit seiner hohen Komplexität durch Komponenten wie OADP Anfänger aber schnell. Quelle: Red Hat

Aus Red Hats Perspektive ist das ausufernde Prozedere gerechtfertigt: Die vielen Lösungen im Portfolio des Anbieters existieren ja nicht von ungefähr, sondern gehören zu einer sorgsam ausgearbeiteten Produktstrategie. Die soll den Administrator nichts missen lassen, was er möglicherweise woanders zukaufen wollen würde. Selbstredend zielt die Vertriebsstrategie des Konzerns stets auf das Maximum des Erreichbaren ab.

Wenn Red Hat OpenShift verkauft, braucht das ohne Frage skalierbaren, redundanten Speicher, ein vielseitiges Software Defined Networking und umfassende Sicherheitsfunktionen. Gerade Red Hats Klientel in den USA erwartet genau das: eine eierlegende Wollmilchsau. Für Kubernetes-Einsteiger oder Admins, die nur kleinere Projekte mit Kubernetes realisieren möchten, ist das aber eben nicht attraktiv, sondern frustrierend.

Da liegt die Frage auf der Hand, wie der Administrator zu K8s kommt, ohne gleich das ganz große Rad zu drehen? Welche Möglichkeiten existieren fernab der großen Distributionen, um ein lauffähiges Kubernetes zu bauen, das sich für den produktiven Einsatz eignet? Wie kommt man zu einer kleinen, aber feinen Bastelumgebung für die ersten Gehversuche?

Fertige Lösungen gibt es für all diese Herausforderungen en masse, schließlich ist das Geschäft mit K8s seit Jahren Umsatzzugpferd bei zahllosen Technologiekonzernen. Hier den Überblick zu behalten und eine passende Strategie zu entwickeln, kann allerdings eine Herausforderung sein. Dieser Artikel zeigt, was Sie tun müssen, um ein möglichst komplettes, aber zugleich möglichst minimales Kubernetes-Setup zu bauen.

Test oder Produktion?

Um das Beantworten einer zentralen Frage kommt man selbst dann nicht herum, wenn man nur ein kleines Kubernetes für den eigenen Bedarf bauen möchte: Soll sich das Setup für den produktiven Einsatz eignen? Davon hängt einiges ab.

Intuitiv dürften die allermeisten Administratoren zunächst an das Thema Redundanz denken, und um die geht es bei Kubernetes ja gleich auf mehreren Ebenen. Da wäre zunächst die Redundanz, die Kubernetes selbst benötigt: Zentrale Komponenten wie der Scheduler, die Kubernetes-API oder der Cluster Manager betreibt man in produktiven Setups tunlichst redundant, denn sonst reißt der Ausfall einzelner Systeme die gesamte Plattform in den Abgrund.

Gerade das Prinzip einer verteilten und skalierbaren Plattform steht einem Konzept ohne jede Redundanz diametral entgegen. Das Thema Redundanz betrifft aber auch andere Teile der Installation. Ein redundantes Kubernetes nützt nichts, wenn man nicht zumindest auch den Speicher für die laufenden Container-Instanzen redundant einrichtet, denn sonst legt dessen Ausfall die gesamte Plattform lahm.

Ob redundant oder nicht: Kubernetes lässt sich mittels beinahe identischer Methoden entweder in Form eines Ein-Knoten-Setups für Entwicklungszwecke oder als hoch redundante Installation ausrollen. Dabei liegt auf der Hand, dass ein redundantes Setup mehr Hardware benötigt als eine einfache Entwicklungsumgebung – in beiden Fällen kann die Installation aber immerhin virtuell sein.

Mehr Aufwand verursacht die Infrastruktur um eine Kubernetes-Installation herum. Im Rahmen einer Entwicklungsumgebung ist ja erst einmal wichtig, dass überhaupt eine Möglichkeit zur Verfügung steht, Volumes in Kubernetes standardkonform anzulegen (Persistent Volumes und Persistent Volume Claims). Ob die im Hintergrund dann auf ein lokales LVM zeigen, spielt normalerweise keine Rolle.

Ganz anders liegen die Dinge, wenn das Setup produktiv zum Einsatz kommen soll. Redundanter Speicher lässt sich heute auf diverse Weisen realisieren. Hier können neben klassischen NAS- oder SAN-Speichern auch modernere Ansätze zum Einsatz kommen, etwa Ceph oder Longhorn. Sie müssen die nötige Hardware aber besorgen, einbauen und einrichten, bevor Sie mit Kubernetes selbst loslegen können.

Wir legen den Fokus im Folgenden auf Kubernetes selbst und die Wahl der Mittel für das kleinstmögliche K8s-Setup im produktiven oder Entwicklungsumfeld. Dabei setzen wir voraus, dass für das produktive Szenario zumindest fünf Server zur Verfügung stehen: drei Systeme für die Kubernetes-Control-Plane und ein verteilter Speicher auf Basis von Ceph sowie zwei weitere Systeme für den (redundanten) Betrieb von Containern.

Vorsicht vor Vanilla

An dieser Stelle ist eine Warnung angebracht: Gerade Administratoren, die bis dato noch gar keine Gehversuche in der K8s-Welt hinter sich gebracht haben, tappen anfangs gern in eine Falle: Sie rollen Kubernetes in Form der Vanilla-Distribution aus, also jener Software, die sich auf Kubernetes.io in Form von Containern [1] findet. Nach derzeitigem Stand ist davon jedoch dringend abzuraten, worüber in der Kubernetes-Community übrigens auch kaum ein Zweifel besteht.

K8s fußt seit Beginn seiner Existenz auf dem Prinzip, dass es eine offizielle Kubernetes-Version gibt, deren zentrale Rolle darin besteht, die Kubernetes-API festzulegen und die Spielregeln dafür zu definieren. In der Praxis lässt das Vanilla-Kubernetes von Upstream sich tatsächlich auch ausrollen. An einem solchen Setup werden Sie allerdings nicht sonderlich lange Freude. Damit erhalten Sie explizit nur das absolute Minimum an Diensten, um ein Kubernetes mit etwas Redundanz zu betreiben. Jegliche Managementwerkzeuge fehlen ebenso wie Tools, um das installierte Basis-Kubernetes mit externen Diensten wie Software Defined Storage (SDS) oder Software Defined Networking (SDN) zu koppeln.

All das ist technisch zwar durchaus möglich. Es erfordert jedoch viel Aufwand, um auf diesem Weg tatsächlich zu einer produktions- oder auch nur entwicklungsreifen Umgebung zu kommen. Langjährige Kubernetes-Jockeys gehen so weit, den Betrieb eines lokalen Vanilla-Kubernetes als eine Form des administrativen Selbstboykotts zu beschreiben. Wenn schon Profis gehörigen Respekt vor einer solchen Aufgabe haben, sollten gerade K8s-Einsteiger den Kampf besser nicht aufnehmen. Dazu besteht ohnehin keine Notwendigkeit: Fernab der riesigen Kubernetes-Umgebungen gibt es ranke und flinke Lösungen, die trotzdem den Betrieb eines standardkompatiblen K8s-Clusters ermöglichen.

Reichlich Möglichkeiten

Den Auftakt im Mini-K8s-Universum machen Entwicklungs-Setups. Hier will der Administrator üblicherweise eine lokale Kubernetes-Instanz schaffen, um eigene Workloads zu testen und zu prüfen, ob seine Konfiguration wie gewünscht funktioniert.

Schon hier präsentiert der Kubernetes-Markt sich unübersichtlich, diverse Lösungen buhlen um die Gunst des Anwenders. Die meisten davon beanspruchen für sich, sich ebenso für kleine Entwicklungsumgebungen wie für redundante Produktiv-Setups im Rechenzentrum zu eignen. Das eigentliche Problem dabei ist die Unübersichtlichkeit: Wer mit Kubernetes bislang noch nicht viel am Hut hatte und das Prinzip nur einmal kennenlernen möchte, kommt schnell durcheinander, wenn von K3s [2], K0s [3], Minikube [4], Microkube [5] und etlichen anderen Variationen die Rede ist.

Hinter all diesen Bezeichnungen verbergen sich K8s-Distributionen, die alle die Vanilla-Variante von Kubernetes mit eigenen Komponenten und einer eigenen Setup-Logik anreichern und das Ganze so einrichten, dass es sich auf der Kommandozeile mittels weniger Befehle ausführen lässt. Sie unterscheiden sich – wenn überhaupt – vor allem durch die Komponenten, um die sie angereichert sind. So aberwitzig es auch klingt: “Not invented here” spielt in der bunten Kubernetes-Welt eine bedeutende Rolle. Oft entscheiden Unternehmen sich nur deshalb dafür, eine eigene K8s-Distribution auf den Markt zu werfen, weil sie ein Alleinstellungsmerkmal gegenüber anderen Herstellern generieren wollen. Aus Sicht des K8s-Neulings macht das die Sache freilich nicht leichter.

Wer nun also praktisch mit einem lokalen Kennenlern-Setup starten möchte, sollte sich zunächst irgendwo eine klassische virtuelle Maschine beschaffen. In ihr läuft im Idealfall ein Debian GNU/Linux 12 oder ein Ubuntu 24.04. Ebenso empfiehlt es sich, im System eine Laufzeitumgebung für den Betrieb von Containern unter Linux zu installieren. Das wird in beiden Fällen meist Docker CE sein, die Community-Ausgabe von Docker. Moderneren Distributionen wie Ubuntu 24.04 liegt in Form von Podman eine passende Laufzeitumgebung bei, die sich unmittelbar nutzen lässt.

Praktisch alle Mini-K8s-Distributionen haben gemein, dass ihre Autoren größten Wert darauf legen, ein komplettes Kubernetes möglichst schnell an den Start zu bringen. Da verwundert es nicht, dass sich in einer existierenden virtuellen Instanz beispielsweise K3s im Nu aufsetzen lässt (Abbildung 2). Dabei handelt es sich um eine deutlich reduzierte, aber dennoch vollständig mit der Kubernetes-API kompatible Distribution, die ursprünglich der Feder der Rancher-Entwickler entsprang. Inzwischen hat sie sich auf Edge Computing, IoT und CI/CD-Anwendungen spezialisiert.

Abbildung 2: Mit K3s, der Kubernetes-Distribution des Rancher-Projekts, lässt sich Kubernetes für Entwicklungs- oder Produktionszwecke in kleinen Umgebungen ausrollen. Quelle: K3s

Die Installation von K3s verläuft denkbar leicht: Ein kurzer Curl-Aufruf genügt, um sämtliche Komponenten in einer 1-Knoten-Installation auszurollen (Listing 1, erste Zeile). Nach ungefähr 30 Sekunden sollten Sie dann bereits eine Liste der verfügbaren K3s-Knoten auf den Schirm holen können (zweite Zeile). Die umfasst in der Standardinstallation allerdings nur die Kubernetes-Control-Plane selbst.

$ curl -sfL https://get.k3s.io | sh --
$ sudo k3s kubectl get node
$ NODE_TOKEN=$(cat /var/lib/rancher/k3s/server/token)
$ sudo k3s agent --server https://<I>Server-IP<I>:6443 --token ${NODE_TOKEN}

Nun fehlt noch ein K3s-Agent, der dann auch tatsächlich Container betreiben kann. Dafür eruieren Sie zunächst das Token für die Authentifizierung von Agents (dritte Zeile) und starten im Anschluss die virtuelle Instanz damit (letzte Zeile), wobei Sie deren Adresse angeben. Danach läuft unter der angegebenen IP ein komplettes Kubernetes, das Volumes erstellen und Container verwalten kann. Haben Sie Ihre VM mit etwas Wumms ausgestattet, können Sie hier schon recht produktionsnah experimentieren.

Im ersten Augenblick fällt gar nicht auf, wie viele Komponenten K3s ab Werk integriert. SDS und SDN haben wir eingangs ja schon angesprochen; K3s liefert funktionierende Komponenten für beides: Volumes lassen sich über einen LVM-Provider zumindest lokal anlegen, und für SDN liegt K3s die Software Flannel bei. Sie gilt zwar als eine der einfacheren SDN-Lösungen für Kubernetes, genügt aber für Test-Setups und die allermeisten produktiven Umgebungen. Obendrein lässt sich Flannel mit diversen Netzwerkkomponenten innerhalb von Kubernetes kombinieren, zum Beispiel mit der Mesh-Lösung Istio.

K3s lässt sich übrigens nicht nur im Ein-Knoten-Modus ausrollen. Möchten Sie ein K3s-Setup aus der Entwicklung später in der Produktion nachbauen, rufen Sie das Setup-Skript mit diversen Parametern auf, die die Control Plane von Kubernetes redundant ausrollen. Hier merkt man K3s an, dass es ursprünglich die Mini-K8s-Distribution im Hintergrund von Rancher war und entsprechend umfassend ausgelegt wurde. Auf Rancher kommen wir später noch zurück.

Auch K0s überzeugt

Ganz ähnlich wie mit K3s verhält es sich mit K0s (Abbildung 3). Die Kubernetes-Distribution von Mirantis steht ebenfalls als freie Software zur Verfügung und lässt sich mit wenigen Handgriffen installieren. Auch hier empfiehlt es sich, für Entwicklungs- und Testzwecke eine einzelne virtuelle Instanz zu starten und die anstehenden Arbeiten darin auszuführen. Dabei ist Ubuntu 22.04 wieder ein gutes Mittel der Wahl. Der Rest geht ganz flott: Via Curl laden Sie das K0s-Binary herunter, mittels dessen Sie anschließend den Kubernetes-Cluster ausrollen (Listing 2, erste Zeile).

Abbildung 3: K0s bietet ähnliche Dienste wie K3s und ermöglicht den Betrieb eines Kubernetes mit allen benötigten Diensten auf engem Raum. Für produktive Umgebungen stehen aber auch HA-Möglichkeiten zur Verfügung. Quelle: Mirantis

$ curl -sSLf https://get.k0s.sh | sudo sh
$ sudo k0s install controller --single
$ sudo k0s start
$ sudo k0s status

Liegt K0s lokal vor, installieren Sie eine Ein-Knoten-Control-Plane für Kubernetes (Zeile 2), starten dann die gewünschten Dienste (Zeile 3) und prüfen deren Status (Zeile 4). Das Kommandozeilenwerkzeug Kubectl lässt sich danach bereits benutzen.

Wie K3s nimmt auch K0s für sich in Anspruch, sich für produktive Umgebungen zu eignen. Dazu führen Sie nach der Installation den Befehl aus der ersten Zeile von Listing 3 aus. Dann legt K0s in der angegebenen Datei »k0sctl.yaml« eine Grundkonfiguration für einen Cluster an, der aus zwei Knoten besteht. Um die Control Plane hochverfügbar auszubauen, sodass sie für den produktiven Einsatz taugt, editieren sie diese Datei entsprechend und setzen die hinterlegte Konfiguration anschließend um (Zeile 3). Dann lassen Sie sich eine mit Kubectl kompatible Konfigurationsdatei ausgeben (Zeile 4). Im Anschluss zeigt dann das Kommando aus der letzten Zeile von Listing 3 die laufenden Pods an.

$ k0s init > k0sctl.yaml
[... k0sctl.yaml editieren ...]
$ k0sctl apply --config k0sctl.yaml
$ k0sctl kubeconfig > kubeconfig
$ kubectl get pods --kubeconfig kubeconfig -A

Wie K3s kommt auch K0s mit fertigen Integrationen für SDN und SDS. Es setzt allerdings zumindest in Sachen Netz auf einen anderen Ansatz und liefert Calico mit aus, das deutlich umfassender und komplexer als Flannel ist. In Sachen Storage muss der Administrator sogar selbst Hand anlegen. Die K0s-Entwickler empfehlen, das Tool mit OpenEBS zu kombinieren. Das gehört seit einer Weile aber nicht mehr zum K0s-Lieferumfang und muss laut Autoren stattdessen über den Paketmanager Helm installiert werden. Die Doku von K0s enthält entsprechende Anweisungen [6].

Dass dieser Artikel K3s und K0s herauspickt, hat nichts mit Voreingenommenheit zu tun. Tatsächlich nehmen sich die diversen Kubernetes-Distributionen derselben Liga inhaltlich und technisch nicht allzu viel. Greifen Sie statt zu K3s oder K0s zu Minikube oder MicroK8s, stellen Sie schnell fest, dass nicht nur deren Installation ähnlich ist: Danach steht jeweils ein vergleichbares Feature-Set zur Verfügung, die Handhabung läuft in denselben Bahnen.

Produktion, aber flott

Wer von vornehrein eine flexible und nicht allzu komplexe Lösung sucht, um Kubernetes produktiv für das eigene Unternehmen auszurollen, beschäftigt sich zunächst mit den eingangs erwähnten Bedingungen, die für ein produktives Kubernetes gegeben sein müssen. Es sollte also klar sein, welche SDS-Lösung zum Einsatz kommen soll und welche SDN-Lösung man anstrebt.

Der Einfachheit halber geht dieser Artikel davon aus, dass der Allrounder Flannel das Software Defined Networking stemmt und dass Software Defined Storage auf den Schultern von Ceph ruht. Das lässt sich mittels Rook [7] als Dienst in Kubernetes selbst ausrollen und dann auch administrieren. Bei der Konfiguration von Kubernetes selbst spielt der SDS-Teil des Setups damit erst einmal nur eine untergeordnete Rolle.

Im Kontext von K3s war Rancher hier schon ein Thema. Tatsächlich eignet Rancher sich auch ganz hervorragend, um produktive Kubernetes-Setups auszurollen (Abbildung 4). Das versteht man schnell, wenn man sich mit der Frage beschäftigt, was Rancher eigentlich genau ist.

Abbildung 4: Mit Rancher lassen sich voll funktionale und trotzdem handliche K8s-Instanzen ausrollen. Das Dashboard leistet dabei gute Dienste. Quelle: Magnolia

Rancher fußt selbst auf Kubernetes und integriert eine Kubernetes-Control-Plane. Zudem lassen sich damit viele verschiedene Kubernetes-Instanzen parallel ausrollen und steuern. Haben Sie die Rancher-Control-Plane also erst einmal eingerichtet, lassen sich der Software weitere Hosts hinzufügen, auf denen Sie im Anschluss per CLI oder GUI eigene kleine Kubernetes-Cluster ausrollen. Wahlweise lassen sich diese dann auch ebenso flott wieder löschen oder rekonfigurieren.

Der Clou: Rancher setzen Sie in etwa ebenso schnell auf wie K3s oder K0s selbst. Praktisch starten Sie dazu nämlich nur einen Docker-Container (Listing 4), auf dessen Port 443 im Anschluss das Web-UI von Rancher zur Verfügung steht. Hier lassen sich nun zusätzliche Hosts als Bare Metal anlegen. Verbindungen dorthin kann Rancher per SSH aufbauen, um notwendige Konfigurationsänderungen auszuführen. Es empfiehlt sich also, ganz am Anfang alle beteiligten Systeme so zu präparieren, dass die Verbindung vom Rancher-Control-Host aus mittels Secure Shell klappt.

$ sudo docker run --privileged -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher

Auch die Installation des Betriebssystems lässt sich per Lifecycle-Management auf Wunsch gut automatisieren. Haben Sie per Rancher den ersten hochverfügbaren Kubernetes-Cluster auf den Zielsystemen installiert, lässt sich direkt im Anschluss noch Rook (Abbildung 5) für hochverfügbaren Speicher ausrollen.

Abbildung 5: Für alle K8s-Setups empfiehlt sich Rook als Speicherlösung, das selbst in K8s laufen kann und sich zudem in kürzester Zeit aufsetzen lässt. Quelle: Rook

Achtung: Das beschriebene Mini-Setup geht wie eingangs erwähnt davon aus, dass die Controller- und Storage-Dienste hyperkonvergent auf denselben Systemen laufen. Die Systeme mit den Kubernetes-Diensten eines per Ranchers ausgerollten K8s-Clusters brauchen also ebenfalls Speichergeräte (Festplatten oder Flash-Laufwerke), damit Rook im Anschluss redundant Speicher anbieten kann.

Selbstredend lässt sich solch ein Setup in virtuellen Instanzen betreiben oder zumindest testen, falls der produktive Einsatz später auf echtem Blech erfolgen soll. So oder so kommen Sie über den Umweg mit Rancher und Rook sehr zügig zu einem produktionsreifen Setup auf Basis von Kubernetes, ohne sich mit zahllosen Addons und Produktvarianten zu beschäftigen.

Fazit

Sowohl für den Entwicklungseinsatz als auch für den produktiven Betrieb lassen sich mit Kubernetes flugs Cluster aus dem Boden stampfen, die allen technischen Standards entsprechen und gut funktionieren.

An dieser Stelle ist allerdings ein Wort der Warnung angebracht: Zu den im K8s-Universum notwendigen Arbeiten zählt das Überwachen der Workloads, sowohl derer von K8s selbst als auch der darin laufenden Dienste. Das Thema Observability spielt also eine enorme Rolle. Anbieter wie Red Hat wissen das, und OpenShift installiert aus eben diesem Grund zusätzlich zu Kubernetes selbst eine Vielzahl zusätzlicher Werkzeuge wie Prometheus oder OpenTelemetry. Auch das Security-Addon für OpenShift spielt durchaus eine Rolle, weil es für Überblick in Sachen Sicherheit sorgt.

Sie brauchen diese Funktionalität auch dann, wenn Sie sich für eine der hier vorgestellten weniger aufwendigen Lösungen entscheiden, bekommen sie aber nicht unmittelbar aus der Dose geliefert. Hier fällt also Nacharbeit an, zumindest für produktive Umgebungen. Angesichts eines Kubernetes mit implizit sehr hoher Komplexität möchten Sie sicher nicht in eine Situation geraten, in der Sie in der eigenen Umgebung im Blindflug unterwegs sind.

Unabhängig davon gilt aber: Möchten Sie K8s ausprobieren oder produktiv betreiben, haben Sie dazu auch fernab der umfangreichen Standardpakete der etablierten Hersteller einige Möglichkeiten. (jcb/jlu)