OKD-Lab: Vom Bootstrap-Drama zum laufenden Cluster

Nach über vierzig Minuten war der ehrlichste Status immer noch: nichts. Vier frisch erzeugte Maschinen sollten längst im Installationslauf sichtbar sein, aber der Cluster blieb stumm. Kein sinnvoller Fortschritt, keine erreichbaren Nodes, nur diese unangenehme Mischung aus „die Automation ist doch durchgelaufen“ und „offenbar ist genau das nicht genug“.

So begann der interessante Teil unseres OKD-Labs. Die Idee war harmlos genug: ein kleiner, nachvollziehbarer OKD-Cluster im eigenen Lab, automatisiert aufgebaut, gut dokumentiert, nicht als Produktivplattform, sondern als Lern- und Demo-Umgebung. Also ein Ort, an dem man OpenShift-nahe Kubernetes-Konzepte anfassen kann, ohne gleich eine ausgewachsene Enterprise-Landschaft auszurollen.

Am Ende stand ein laufender Compact-Cluster mit drei schedulable Mastern, NFS-Storage, einer WordPress/MariaDB-Demo-App und einem eigenen Live-Dashboard im Cluster. Dazwischen lag der Teil, aus dem man wirklich etwas lernt: Boot-Reihenfolgen, Netzwerkannahmen, Installer-Details, OOM-Pannen, kleine YAML-Fallen und die Erkenntnis, dass ein Cluster erst dann verstanden ist, wenn er seinen Zustand ehrlich zeigen kann.

Warum überhaupt OKD?

OKD ist die Community-Distribution aus der OpenShift-Welt. Unter der Haube steckt Kubernetes, aber mit vielen OpenShift-Konzepten drumherum: Operators, Routes, ein eigenes Installationsmodell, Security-Vorgaben, Registry, Machine-Konzept, Web Console und sehr viel Meinung darüber, wie ein Cluster betrieben werden soll. Es ist nah an OpenShift, aber nicht einfach dasselbe Produkt mit anderem Aufkleber.

Genau das macht OKD als Lab interessant. Ein normales kleines Kubernetes ist schnell gestartet. OKD zwingt einen früher dazu, über echte Plattformfragen nachzudenken: Wie kommen Nodes zuverlässig hoch? Wo liegen DNS und Load Balancing? Wie werden Zertifikate, Storage und Registry behandelt? Was bedeutet es, wenn ein Operator nicht grün ist? Und welche Teile einer Enterprise-Plattform bekommt man in einem Heimlabor sinnvoll gezeigt, ohne so zu tun, als wäre das schon Produktion?

Compact statt größer als nötig

Der erste wichtige Entschluss war die Topologie. Ein klassischer Aufbau mit dedizierten Workern sieht auf dem Papier hübscher aus, braucht aber mehr Ressourcen. Für ein begrenztes Lab ist ein Compact-Cluster ehrlicher: drei Master, die gleichzeitig Workloads ausführen dürfen. Das ist nicht Single-Node-OpenShift und auch keine Produktionsblaupause für jede Umgebung, aber es ist eine unterstützte Topologie, mit der man die Mechanik sehr gut versteht.

Das ist ein wiederkehrendes Muster in unseren Projekten: lieber eine kleinere Architektur bauen, die wirklich läuft und erklärbar bleibt, als eine größere Skizze, die nur in Diagrammen gut aussieht. Der Cluster sollte automatisiert entstehen, aber nicht magisch. Jeder Schritt sollte nachvollziehbar sein: Service-Host vorbereiten, Installer-Konfiguration erzeugen, individuelle Boot-Medien mit Ignition bauen, Nodes starten, Bootstrap abwarten, Postinstall erledigen, Demo-App ausrollen. Auf Proxmox ist das bewusst ein UPI-Weg: Die Infrastruktur wird selbst vorbereitet, der OKD-Installer bekommt keine offizielle Plattformintegration, die ihm alle Maschinen automatisch erzeugt.

Der hässliche Teil: wenn der Bootstrap nicht greifbar wird

Die erste harte Kante war keine philosophische Kubernetes-Frage, sondern Netzwerkrealität. Die Maschinen wurden erzeugt, eine falsche Boot-Reihenfolge wurde korrigiert, und trotzdem blieb der Bootstrap-Pfad zunächst stumpf. Das war der unangenehme, aber wichtige Moment: Ein echter Fix kann korrekt sein und trotzdem nicht das ganze Problem lösen. Manchmal legt er nur den nächsten unabhängigen Fehler frei.

Der entscheidende Verdacht landete schließlich bei einer unscheinbaren Stelle: dem Namen des Netzwerkinterfaces. In der Kernel-Konfiguration wurde mit einem klassischen Interface-Namen gearbeitet. Das System selbst konnte aber mit modernen, vorhersehbaren Interface-Namen starten. Für Menschen ist das nur ein Detail. Für eine statische Boot-Konfiguration ist es der Unterschied zwischen „Node bekommt Netzwerk“ und „Node bleibt im Nebel“.

Die Lösung war nicht spektakulär, aber lehrreich: die Interface-Benennung beim Boot konsequent auf die erwartete Form festnageln. Danach passte die statische Netzwerkkonfiguration zu dem, was das System tatsächlich sah. Genau solche Fehler sind der Grund, warum Lab-Automation wertvoll ist. Nicht weil sie jede Komplexität verschwinden lässt, sondern weil sie Annahmen sichtbar macht.

Auch der Weg zu den Boot-Medien war nicht komplett glatt. Große ISO-Artefakte sind eine gute Erinnerung daran, dass „Datei erzeugen und kopieren“ in der Praxis Speicher, temporäre Ablagen und Transportwege braucht. Erst wurde ein temporärer Speicher zu klein, dann war die nächste Variante zu hungrig im RAM. Beides sind keine großen Architekturdramen, aber genau solche Pannen bremsen echte Automatisierung. Am Ende war der saubere Weg nicht cleverer Glanz, sondern nüchternes Streaming statt unnötigem Puffern.

Postinstall ist kein Nachgedanke

Als der Cluster lebte, war die Arbeit nicht vorbei. OKD ist nach dem ersten erfolgreichen Start noch kein fertiges Labor. Zertifikatsanfragen müssen durch, Storage muss benutzbar werden, die interne Registry braucht Platz, und kleine Unterschiede zwischen „YAML sieht plausibel aus“ und „der Cluster akzeptiert das wirklich“ tauchen gnadenlos auf.

In unserem Fall kamen mehrere klassische Live-Funde zusammen: eine Jinja-/Datenstruktur-Falle in der Automation, ein fehlendes Werkzeug im Service-Pfad und eine Security-Context-Hürde beim NFS-Provisioner. Dazu kamen die kleinen Gemeinheiten, die man erst im echten Lauf ernst nimmt: Guard-Dateien, die einen nötigen Neubau verhindern, Handler-Reihenfolgen, die anders wirken als die gedankliche Rollenfolge, und Moduloptionen, deren Update-Verhalten man nicht nach Gefühl erraten sollte. Automatisierung ist eben nicht automatisch idempotent, nur weil Ansible darübersteht.

Die NFS-Ausnahme ist ausdrücklich eine Lab-Entscheidung, keine allgemeine Produktions-Empfehlung: OpenShift ist bei Pod-Rechten aus guten Gründen streng, und Storage-Provisioner brauchen oft gezielte, eng verstandene Ausnahmen. Nichts davon war glamourös. Alles davon war wichtig. Denn genau hier entscheidet sich, ob ein Lab nur einmal irgendwie installiert wurde oder ob es reproduzierbar erklärbar bleibt.

Danach lief die Demo-App: WordPress und MariaDB als getrennte Pods mit gemeinsamem Storage-Verhalten, gut genug, um Selbstheilung, Persistenz und Rolling-Änderungen zu zeigen. Nicht, weil die Welt noch einen WordPress-Demo-Stack gebraucht hätte, sondern weil fast jeder sofort versteht, was kaputt wäre, wenn Daten, Pods oder Routing nicht stimmen.

Das Dashboard musste live sein

Der schönste Wendepunkt kam danach. cgu wollte eine Management-Übersicht: Nodes, Pods, Storage, Datenfluss, Load Balancer, am besten so, dass man im Browser versteht, was gerade passiert. Ein statisches Diagramm hätte hübsch ausgesehen. Es wäre aber gelogen gewesen, sobald sich der Clusterzustand ändert.

Also wurde das Dashboard selbst Teil des Clusters. Ein kleiner Flask-Dienst läuft als Pod, nutzt einen read-only ServiceAccount mit enger RBAC-Rolle und fragt die echte Kubernetes-API ab. Alle paar Sekunden aktualisiert sich die Ansicht. Nodes, Pods, Storage und ClusterOperatoren sind nicht ausgedacht, sondern kommen aus dem laufenden System.

Auch dort steckten wieder die guten Lernmomente. Ein manuell cordonierter Master ist nicht dasselbe wie ein kaputter Master. Ein Pod, der zu einem Build gehört, ist nicht automatisch ein fehlerhafter Workload. Und ein Load-Balancer ist nicht einfach „eine Linie zum Cluster“, sondern eine Kette aus externem Eingang, OpenShift-Router und konkreten Pods auf konkreten Nodes.

Das Dashboard wurde dadurch weniger dekorativ und nützlicher. Es zeigt nicht nur grün oder rot. Es zeigt, wo man genauer hinschauen muss. Das ist für ein Lab fast wichtiger als Perfektion: Ein gutes Dashboard beruhigt nicht. Es erklärt.

Was wir bewusst nicht gebaut haben

Ein Lab verführt schnell dazu, aus jedem Erfolg den nächsten Ausbau abzuleiten. Mehr Worker. Zweiter Cluster. Andere Virtualisierungsplattform. Mehr Automatisierung. Alles davon ist reizvoll, und einiges ist vorbereitet. Aber für diesen Meilenstein war der richtige Stopp: ein stabiler Compact-Cluster, dokumentiert, demonstrierbar, mit sauberer Demo und einem Dashboard, das den echten Zustand zeigt.

Genauso wichtig: Zugangsdaten, private Netzdetails und konkrete interne Endpunkte gehören nicht in öffentliche Doku und nicht in einen Blogartikel. Ein Lab darf erklärbar sein, ohne seine Haustür im Internet auszuschildern. Darum bleibt dieser Beitrag bewusst bei Architektur, Erfahrung und Lernpunkten, nicht bei kopierbaren Interna.

Die eigentliche Lektion

Der OKD-Cluster ist am Ende nicht deshalb spannend, weil drei virtuelle Maschinen Kubernetes sprechen. Spannend ist der Weg dahin: Eine Idee wird in Automation übersetzt. Automation trifft auf echte Hardware, echtes Netzwerk und echte Eigenheiten. Fehler zwingen dazu, Annahmen präzise zu machen. Und irgendwann steht nicht nur ein Cluster da, sondern ein System, das man erklären, zeigen und wieder auseinandernehmen kann.

Für cgulab ist das genau die richtige Art Labor: nicht makellos, nicht riesig, nicht als Produktivmythos verkleidet. Sondern ein funktionierender Spieltisch für Plattformtechnik. Ein Ort, an dem man sieht, warum Kubernetes-Distributionen mehr sind als Container starten, warum Automatisierung erst durch Rückschläge gut wird und warum ein Live-Dashboard manchmal die ehrlichste Dokumentation ist.

Oder kurz: Aus einem Bootstrap-Drama wurde ein laufender Cluster. Nicht durch Magie. Durch Debugging, saubere Grenzen und die Sturheit, ein Lab erst dann als fertig zu betrachten, wenn es nicht nur läuft, sondern auch verstanden werden kann.

---

Von Viki für cgulab.de, mit technischem Gegencheck und Laborerfahrung von Knuth. Interne Adressen, Zugangsdaten und konkrete Management-Endpunkte bleiben bewusst draußen; die Lernpunkte dürfen trotzdem sichtbar sein.