Kubernetes-Lab: ein k3s-Cluster mit einem Knoten für jede lernende Person auf einer privaten Ubuntu-VM

Dieses Lab gibt jeder lernenden Person einen eigenen Kubernetes-Cluster. k3s, ein kleines Kubernetes, läuft als einziger Knoten auf der einen Ubuntu-VM, und sie arbeitet mit dem echten Befehl kubectl: Sie lässt Webserver mit einem Deployment laufen, sieht zu, wie Kubernetes einen gelöschten Pod zurückbringt, gibt den Pods mit einem Service einen gemeinsamen Namen, versorgt sie mit einem ConfigMap und findet heraus, warum ein Pod nicht läuft.

Auf dem Rechner der lernenden Person wird nichts installiert und nichts mit anderen geteilt: Ein Fehler kostet einen Cluster, und das Lab lässt sich neu starten.

Was die Lernenden lernen

Was Kubernetes tut: Sie sagen, was laufen soll, und es hält es am Laufen. In fünf Teilen. Zuerst ein Rundgang durch den Cluster, seinen Knoten, seine Namespaces und die Pods, die Kubernetes selbst startet. Dann ein Deployment aus drei Webservern, hoch- und heruntergeskaliert, mit einem gelöschten Pod, der zurückkommt. Dann ein Service, der den Pods einen gemeinsamen Namen gibt, den ein anderer Pod über das clustereigene DNS findet. Dann ein ConfigMap, dessen Wörter in jeder Seite landen, und die Tatsache, dass ein laufender Pod eine Änderung erst sieht, wenn er ersetzt wird. Zuletzt drei kaputte Deployments, jedes auf seine Art, die durch Lesen von kubectl describe und kubectl logs zu reparieren sind.

Was in der Maschine steckt

Ein Knoten, k3s in Version 1.35, vom Einrichtungsskript des Labs aus den öffentlichen Releases des k3s-Projekts auf GitHub installiert. Die Dateien sind durch ihre Prüfsummen festgelegt, die das Release selbst veröffentlicht, und jede andere Datei wird abgelehnt. Traefik, der Service-Load-Balancer und der Metrics-Server sind abgeschaltet, damit alles in den Speicher passt, es gibt also kein Ingress und kein kubectl top. kubectl, crictl und ctr sind da.

Die VM der lernenden Person erreicht das Paketarchiv von Ubuntu, PyPI, npm und GitHub, aber keine Image-Registry. Deshalb läuft in diesem Lab jeder Pod mit dem einen Image, das k3s mitbringt, busybox in Version 1.37.0, das sh, httpd, wget und nslookup hat, und das ist alles, was die Lektionen brauchen. Ein Pod, der ein Image wie nginx verlangt, bleibt in ImagePullBackOff, was die README gleich in den ersten Zeilen sagt.

Im Browser ausführen

VM-Labs werden als Lab-Aufgabe in einem Modul angelegt, und das Beispiel steht auf der Seite des Labs. Die Maschine verlangt 2 CPUs, 2 GB Arbeitsspeicher und 10 GB Festplatte. k3s braucht etwa ein halbes Gigabyte, wenn nichts darauf läuft, der Rest gehört den Pods und Ubuntu.

  1. Das Lab hinzufügen. Legen Sie in einem Modul, das Sie unterrichten, eine Aufgabe an und wählen Sie die Karte Ubuntu-VM-Lab. Die Seite zeigt statt einer Compose-Datei eine kurze Beschreibung der Maschine.
  2. Mit dem Beispiel beginnen. Die Seite bietet fertige Labs an. Wählen Sie Kubernetes mit k3s. Ein Beispiel zu verwenden ersetzt den Text, und Rückgängig bringt Ihren eigenen zurück.
  3. Veröffentlichen und die eigene Kopie starten. Veröffentlichen Sie und drücken Sie dann Start. Das Einrichtungsskript des Labs lädt beim ersten Start der VM k3s aus seinen öffentlichen Releases auf GitHub herunter, etwa 270 MB, und schreibt den Befehl k3slab, die zwei Arbeitsdateien und die README. Der Cluster ist nach einigen Minuten bereit.
  4. Das Terminal öffnen. Öffnen Sie das Terminal, führen Sie k3slab status aus, bis es meldet, dass der Cluster bereit ist, und lesen Sie README.md im Home-Ordner: Sie sagt in fünf Teilen, was zu tun ist, und gibt keine Lösungen preis.

Wer es ausführen kann

Das Lab braucht die 2 GB, also die Maschine eines Hochschul- oder Schulkontos. Bei einem kostenlosen Konto hat die Maschine 1 GB: Das Lab startet k3s dort nicht von selbst und sagt es, und sudo k3slab install --anyway ist für Lernende, die es versuchen wollen, ohne Zusage, dass es hält. Wer ohne Konto kommt, hat 1 GB und erreicht nur das Archiv von Ubuntu, k3s lässt sich also gar nicht herunterladen. Setzen Sie das Lab für eine Klasse in einer Einrichtung ein.

Eine Basics-Lektion zu diesem Lab

Kubernetes Basics ist eine kleine Lektion, die in diesem Lab gehalten wird, einer Ubuntu-VM. Sie hat einen Einstieg, ein Ich-kann-Ziel, Schlüsselwörter, eine Aufwärmfrage, nach jeder Idee eine Kontrolle, einen häufigen Fehler und eine Abschlusskontrolle, und jeder Schritt hat eine Ausführen-Schaltfläche, die den Befehl ins Terminal der Maschine tippt. Die lernende Person liest den Knoten und die System-Pods, legt ein Deployment aus drei Pods an, löscht die Pods und sieht drei neue erscheinen und skaliert auf fünf.

Die Lektion arbeitet in einem eigenen Namespace und löscht ihn wieder und überlässt die eigentliche Aufgabe des Labs, den Service, das ConfigMap und die kaputten Deployments, den Lernenden. Sie verrät also keine Lösungen.

Wie bewertet wird

Das Lab hat eine Prüfung. Sie läuft auf einer Kopie der gespeicherten Maschine nach einem frischen Start, wartet, bis k3s mit der Arbeit der lernenden Person darin hochgefahren ist, und fragt den Cluster ab, nicht die Dateien. Das Deployment web muss drei bereite Pods haben, und der Service web muss Port 80 an Port 8080 aller drei weiterleiten. Dann ruft ein Pod im Cluster zwölfmal http://web ab: Der Name muss funktionieren, die Antworten müssen von mehr als einem Pod kommen, und jede Seite muss die Wörter des ConfigMaps zeigen. Danach ändert die Prüfung das ConfigMap auf ein Wort, das niemand gesehen hat, und löscht einen Pod: Das Deployment muss einen zurückbringen, dessen Seite das neue Wort zeigt, was eine ins Deployment getippte Seite nie tut. Zuletzt müssen die drei kaputten Deployments laufen, und das dritte muss in seinem Log melden, dass es bereit ist. Die erste Zeile der Ausgabe sagt, warum die Prüfung nicht bestanden wurde.

Die Prüfung hat drei Minuten, die lernende Person sollte das Lab also bei laufendem Cluster beenden und ihn hochfahren lassen.

  1. Das Lab austeilen. Weisen Sie das Lab wie jede Aufgabe zu, auf Wunsch mit Abgabetermin. Jede lernende Person bekommt eine eigene VM, die zwischen den Sitzungen erhalten bleibt, und der Cluster liegt auf ihrer Festplatte.
  2. Die Prüfung ausführen. Drücken Sie in der Klassenliste in der Zeile einer lernenden Person auf Prüfung ausführen. Sie startet eine Kopie der gespeicherten Maschine, die nicht zurückgespeichert wird, wartet, bis der Cluster hochgefahren ist, fragt ihn ab und zeigt, ob sie bestanden wurde, was sie ausgegeben hat und wann. Die lernende Person erfährt das Ergebnis nicht.
  3. Bewerten. Lesen Sie die erste Zeile der Ausgabe der Prüfung: Sie sagt, was nicht stimmt, etwa kein Service namens web, eine Seite, die das ConfigMap nicht zeigt, oder ein kaputtes Deployment, das immer noch nicht läuft. Geben Sie die Arbeit mit einer Begründung zurück, wenn mehr nötig ist.

Die Definition auf GitHub

Die Datei ist die ganze Lab-Definition, derselbe Text, den die Plattform ausführt: Größe, Einrichtungsskript, der Befehl k3slab, die zwei Arbeitsdateien, README und Prüfung. Kopieren Sie sie und ändern Sie die Deployments oder die Fehler in broken.yaml, um ein längeres Lab zu bauen.

Dieses Lab ausprobieren, und was es kostet

Mit einem kostenlosen persönlichen Konto können Sie die Grundlagenlektionen in diesem Lab durcharbeiten, mit genug kostenlosem Guthaben pro Monat für die meisten Lektionen und ohne Karte. Für eine Klasse sind die ersten 365 Tage für eine Schule kostenlos, für bis zu 50 Lernende; danach zahlt sie je lernender Person und Jahr, alle Labs inklusive und Lehrkräfte kostenlos.

Häufige Fragen

Braucht das Kubernetes-Lab eine Lizenz?
Nein. k3s ist freie Software unter der Apache-2.0-Lizenz und wird beim Start der VM aus den Releases des k3s-Projekts selbst heruntergeladen; wir verteilen nichts davon. Die Images in seinem Paket sind die des Projekts und unverändert.
Warum nutzen die Pods busybox und nicht nginx?
Die VM erreicht keine Image-Registry, ein Pod kann also nur ein Image ausführen, das die Maschine schon hat. k3s bringt einige mit, und busybox ist das, das etwas Nützliches kann: Es liefert eine Webseite aus, ruft eine ab und löst Namen auf. Alles über Deployments, Services und ConfigMaps ist unabhängig vom Image gleich.
Können Lernende etwas beschädigen?
Nur ihre eigene Kopie. Der Cluster ist ein Knoten in der VM, die das Ubuntu-Archiv, PyPI, npm und GitHub erreicht und sonst nichts. Wenn jemand den Cluster kaputt macht, stellt k3slab files die beiden Dateien wieder her, und kubectl delete namespace lab beginnt die Übungen neu.
Kann es jemand mit kostenlosem Konto nutzen?
Nicht verlässlich. Die Maschine eines kostenlosen Kontos hat 1 GB, und k3s braucht mit ein paar Pods etwa 2 GB, das Lab startet es dort also nicht von selbst. Die Maschine eines Einrichtungskontos hat 2 GB, so viel verlangt das Lab.
Wurde das Lab in einer echten VM von Lernenden getestet?
Die Einrichtung mit ihren echten Downloads, die Befehle der Lektion und die Prüfung samt allen Täuschungsversuchen liefen in einem echten Ubuntu 26.04 mit laufendem k3s, in einem Container als Ersatz für die VM. Eine wirklich gebootete VM, die k3s aus einer systemd-Unit startet, mit 2 GB und dem Netzwerk-Proxy der Plattform, sollte vor einer Stunde einmal ausprobiert werden.