Kubernetes-Lab für Azubis – eine zweite Karriere für alte Rechner

Kubernetes lernt man nicht allein aus Folien. Man muss Deployments kaputt
konfigurieren, einen Node verlieren, Zertifikate erneuern, Logs lesen und
herausfinden, warum ein Dienst zwar läuft, aber trotzdem nicht erreichbar ist.
Genau dafür bauen wir bei artif ein eigenes Kubernetes-Lab für Azubis und
Mitarbeitende.

Das Besondere daran: Der Cluster entsteht nicht aus einer homogenen
Serverbestellung. Ausgangspunkt war ein Bestand aus gebrauchten Rechnern, die
für ihre bisherigen Aufgaben nicht mehr benötigt wurden. Darunter waren zwei
HP MicroServer N40L, zwei N54L und ein MicroServer Gen8. Später kamen vier HP
EliteDesk, zwei individuell gebaute Desktop-PCs und eine deutlich jüngere Dell
Precision hinzu.

Die erste Frage lautete deshalb nicht: Wie installieren wir Kubernetes?
Zuerst mussten wir herausfinden, welche Rechner den Strom und die Arbeit
überhaupt wert sind.

Ein echtes Lab statt einer perfekten Simulation

Virtuelle Maschinen wären einfacher gewesen. Für das Ausbildungsziel ist
die gebrauchte Hardware aber gerade interessant. Sie bringt Probleme mit, die
in einer aufgeräumten Cloud-Umgebung kaum sichtbar werden:

• BIOS und UEFI verhalten sich je nach Baujahr unterschiedlich;
• Secure Boot kann einen Kernel blockieren;
• Netzwerkkarten brauchen unterschiedliche Treiber;
• alte Platten enthalten Partitionstabellen und RAID-Metadaten;
• ein Installer kann das falsche Laufwerk auswählen;
• langsame Festplatten, knapper RAM und fehlende Netzwerk-Links sind reale
  Betriebsbedingungen.

Das Lab soll gefahrlos beschädigt und wiederhergestellt werden können. Es
trägt keine produktiven Kundendaten. Trotzdem gelten dieselben Grundsätze wie
in einer produktiven Umgebung: reproduzierbare Konfiguration, minimale Rechte,
nachvollziehbare Logs, getrennte Netze und Backups für alles, was erhalten
bleiben soll.

Die Hardware zuerst kennenlernen

Zu Beginn wussten wir über manche Rechner kaum mehr als den Modellnamen. Die
alten HP MicroServer zeigen gut, warum das nicht reicht. Zwei N40L und zwei
N54L sehen fast gleich aus. Technisch liegen zwischen ihnen und dem Gen8 aber
entscheidende Unterschiede.

Die Seriennummern bestätigen den Zeitraum: Die beiden N40L stammen aus 2012,
ein erfasster N54L aus der dritten Kalenderwoche 2013. Der Gen8 wurde in der
21. Kalenderwoche 2015 gefertigt. Alter allein war aber kein
Ausschlusskriterium. Wichtiger waren Leistung pro Watt, RAM, Laufwerke,
Netzwerk und eine sinnvolle Rolle im Gesamtsystem.

Der Gen8 besitzt zwei DIMM-Slots und ECC-Speicher. Ein zweiter passender
8-GB-Riegel soll ihn auf 16 GB bringen. Identifizierende Gehäusedaten wurden
im Bild unkenntlich gemacht.

Statt auf jedem Rechner ein großes Live-System zu starten, entwickelten wir
eine kleine PXE-Inventur, die vollständig im RAM läuft. Sie sammelt
rechnerbezogen unter anderem:

• Hersteller, Modell und stabile Inventar-ID;
• CPU-Modell, Kerne und Takt;
• installierten Arbeitsspeicher;
• Netzwerkschnittstellen und Link-Status;
• Laufwerksmodell, Kapazität, Seriennummer und SMART-Werte;
• vorhandene Partitionen und RAID-Spuren.

Die Daten landen zentral auf dem Gateway und lassen sich anschließend
vergleichen. Eine kurze ID wie LAB-343DF6 verbindet den Datensatz mit einem
Aufkleber am Gehäuse. So bleibt auch bei mehreren optisch identischen Rechnern
klar, welches Gerät bereits untersucht oder installiert wurde.

Die schlanke Inventur startet direkt als Init-Prozess. Dieses Foto entstand
während der Fehlersuche an einem Rechner, dessen Netzwerkschnittstelle im
ersten Initramfs noch nicht korrekt erkannt wurde.

Weshalb vier MicroServer gehen mussten

Die N40L und N54L sind robuste kleine Server mit mehreren
Festplatteneinschüben. Für einen dauerhaft laufenden Kubernetes-Worker sind
zwei alte CPU-Kerne und 4 GB RAM heute jedoch eine ungünstige Kombination.
Ein einzelner modernerer Rechner stellt mehr Rechenleistung und RAM bereit,
ohne dass dafür vier Gehäuse, vier Netzteile und vier Netzwerkanschlüsse
laufen müssen.

Wir haben deshalb alle zwei N40L und beide N54L aus dem Zielbestand genommen.
Ihre Festplatten werden separat geprüft und können weiterverwendet werden.
Der Gen8 bleibt: nicht als schneller Worker, sondern wegen seiner
Serverqualitäten. Er besitzt iLO für die Fernwartung, zwei Gigabit-Ports,
ECC-RAM und vier gut zugängliche Laufwerkseinschübe. Drei vorhandene
1-TB-Enterprise-Platten bilden dort ein dreifach gespiegeltes Software-RAID1.
Damit steht knapp 1 TB nutzbarer, gegen den Ausfall von bis zu zwei Platten
geschützter Speicher zur Verfügung. Ein RAID ersetzt dabei weiterhin kein
Backup.

Die eigentliche Rechenarbeit übernehmen passendere Systeme:

• eine Dell Precision mit Intel Core i7-10700, 16 GB RAM und NVMe-SSD;
• vier HP EliteDesk mit Core i5-4570S, jeweils 8 GB RAM und SSD;
• zwei Desktop-PCs mit AMD A8/A10 und jeweils 16 GB RAM;
• ein eigener Gateway-Rechner mit 16 GB RAM.

Damit bleibt das Lab bei maximal neun Rechnern. Nicht jeder davon muss ständig
eingeschaltet sein. Der Gen8 kann beispielsweise gezielt für Storage- und
Backup-Aufgaben laufen.

Das Gateway ist der Ausgangspunkt

Der zentrale Rechner k3s-gw verbindet das Firmennetz mit einem getrennten
Lab-Netz. Er ist gleichzeitig Router, Firewall, DNS- und DHCP-Server,
PXE-Server sowie erster K3s-Control-Plane-Knoten. Eine Intel-82576-Karte mit
zwei Gigabit-Ports bindet das Lab per Active-Backup an den Switch an.

flowchart LR
    Office[Firmennetz] --> GW[k3s-gw<br/>Router, Firewall, DNS, DHCP, PXE, K3s]
    GW -->|2 x 1 GbE Active-Backup| SW[Lab-Switch]
    SW --> CP[Control Plane und Worker]
    SW --> ST[Gen8 Storage und Backup]
    PXE[RAM-Inventur und Autoinstall] --> GW
    GW --> PXE

Das getrennte Netz begrenzt die Auswirkungen von Experimenten. Gleichzeitig
können Anwendungen über Traefik und MetalLB kontrolliert bereitgestellt
werden. DNS-Namen unter lab.artif.com und automatisch ausgestellte
TLS-Zertifikate sorgen dafür, dass sich das Lab wie eine reale Umgebung
anfühlt.

Die ersten Fehlversuche waren Teil des Designs

Der kürzeste Weg wäre gewesen, Ubuntu auf jedem Rechner von Hand zu
installieren. Das hätte das eigentliche Problem nur vertagt. Spätestens beim
nächsten Neuaufbau wären wieder dieselben Dialoge, Laufwerksentscheidungen
und Fehlerquellen aufgetaucht.

Unser erster PXE-Ansatz lud ein komplettes Ubuntu-Live-System über das Netz.
Das war langsam und scheiterte auf kleinen Rechnern sogar mit No space left on device im RAM-Dateisystem. Danach folgten unter anderem ein nicht passender
Secure-Boot-Shim, Kernel Panics, ein fehlender Netzwerktreiber und alte
RAID-Signaturen, an denen der automatische Installer scheiterte.

Aus jedem Fehler entstand eine konkrete Verbesserung:

• eine sehr kleine Inventur statt eines großen Live-Images;
• hardwarebezogene Boot- und Installationsprofile;
• Auswahl von Laufwerken anhand ihrer Seriennummer statt ihrer wechselnden
  Linux-Gerätenamen;
• Sicherheitsabbrüche, bevor ein nicht freigegebenes Laufwerk gelöscht wird;
• zentrale Live-Logs und Abschluss-Callbacks;
• automatischer Clusterbeitritt nach erfolgreicher Installation.

Das ist bereits ein wichtiger Teil des Ausbildungsprojekts: Automatisierung
bedeutet nicht nur, einen erfolgreichen Ablauf schneller zu machen. Sie muss
Fehler sichtbar machen und bei Unsicherheit sicher anhalten.

Der erste Zwischenstand

Aus einem gemischten Altgerätebestand ist eine nachvollziehbare
Zielarchitektur entstanden. Die geeigneten Rechner wurden inventarisiert,
automatisch installiert und dem K3s-Cluster hinzugefügt. Langsame
MicroServer wurden aussortiert, während der Gen8 eine klar umrissene
Storage-Rolle erhielt.

Auf dem Cluster stehen bereits die grundlegenden Dienste bereit: Traefik als
Ingress-Controller, MetalLB für Adressen im lokalen Netz, cert-manager für
TLS-Zertifikate sowie Headlamp, Prometheus und Grafana für Verwaltung und
Beobachtung. Anwendungen sollen später in getrennten Azubi-Namespaces laufen.

Im zweiten Teil zeigen wir den Weg vom Einschalten eines unbekannten Rechners
bis zum automatisch installierten K3s-Node. Dabei geht es um PXE, den kleinen
RAM-Installer, sichere Laufwerksauswahl und die Frage, wie Installationsfehler
ohne Person vor dem Monitor sichtbar werden.
Im zweiten Teil zeigen wir den Weg vom Einschalten
eines unbekannten Rechners bis zum automatisch installierten K3s-Node. Dabei
geht es um PXE, den kleinen RAM-Installer, sichere Laufwerksauswahl und die
Frage, wie Installationsfehler ohne Person vor dem Monitor sichtbar werden.