Das Labor
Diese Seite zeigt meinen Aufbau — kleinteilig, damit man ihn nachvollziehen kann. Für den Kurs ist er nicht nötig: Alles in den Folgen funktioniert genauso in virtuellen Maschinen. Wenn du mitbaust, ist hier eher die Frage interessant, welche Größenordnung du brauchst.
Was du mindestens brauchst
| Control Plane | Worker | |
|---|---|---|
| CPU-Kerne | 2 | 2 |
| RAM | 4 GB (8 sind angenehmer) | 4 GB |
| Platte | SSD/NVMe — nicht verhandelbar | egal, SSD ist netter |
| Anzahl | 1 (oder 3 für Hochverfügbarkeit) | 2–3 |
Die SSD in der Control Plane ist der einzige harte Punkt: etcd schreibt bei jeder Zustandsänderung synchron auf die Platte. Auf einer alten Festplatte läuft das Cluster zwar, hakt aber sichtbar bei jedem Befehl.
Alternativ: vier virtuelle Maschinen auf einem Rechner mit 16 GB RAM. Dann fehlt dir nur der Stromstecker-Versuch — den kannst du durch das Anhalten einer VM ersetzen.
Mein Aufbau
| Rolle | Gerät | Ausstattung |
|---|---|---|
| Control Plane | Mini-PC (N100, NVMe) | 16 GB RAM — läuft durch, deshalb sparsam und mit schneller Platte |
| worker-1 | Dell OptiPlex, ~2010 | Pentium E6300 (2 Kerne), 4 GB RAM, 160-GB-Platte |
| worker-2 | Dell OptiPlex, ~2010 | baugleich |
| worker-3 | Dell OptiPlex, ~2010 | baugleich |
Das ist absichtlich schwache Hardware: zwei Kerne und vier Gigabyte sind genau die Untergrenze, die kubeadm verlangt. Was hier läuft, läuft überall. Und der knappe Speicher macht die Folgen über Requests, Limits und Eviction ehrlicher als jedes ausgedachte Beispiel.
Die Control Plane ist bewusst das einzige neue Teil. etcd schreibt bei jeder Änderung synchron auf die Platte — auf einer 15 Jahre alten Festplatte hakt dann jeder einzelne Befehl.
Dazu ein Switch und ein eigenes Netz, getrennt vom Webserver, auf dem diese Seite läuft. Die Rechner sind alt und langsam — das ist Absicht. Es geht nicht um Leistung, sondern darum, etwas zu haben, das man kaputtmachen darf.
Die Software
- Debian 13 auf allen Knoten
- containerd als Container-Laufzeit
- Kubernetes mit kubeadm, Version festgehalten per
apt-mark hold - Cilium als Netzwerk-Plugin
- später: MetalLB, ingress-nginx, cert-manager, Prometheus/Grafana, Helm, Argo CD
Warum kein k3s?
k3s wäre für ein Heimlabor die vernünftigere Wahl: kleiner, schneller, weniger Teile. Genau diese Teile will ich aber sehen — etcd, die einzelnen Control-Plane-Dienste, die Zertifikate, den Beitritt eines Knotens. Wer den harten Weg einmal gegangen ist, versteht hinterher auch die einfache Variante.
Netzplan
(wird eingetragen, sobald die Control-Plane-Hardware feststeht — mit Hostnamen, festen IP-Adressen und den gewählten CIDR-Bereichen für Pods und Services)