00 Lab Skeleton
Empfohlener Ablauf für eigene Kubernetes-Labs:
kubectl config current-context
kubectl create namespace demo --dry-run=client -o yaml
kubectl apply --dry-run=client -f manifest.yaml
kubectl get events -n demo --sort-by=.lastTimestamp
Regeln:
- nur Testcluster verwenden
- keine echten Secrets in Manifeste schreiben
- alle Ressourcen in einem eigenen Namespace halten
- Manifeste mit Dry Run prüfen, bevor sie angewendet werden
1. Ziel
Dieses Beispiel zeigt einen konkreten, lokal nachvollziehbaren Anwendungsfall für das jeweilige Workshop-Thema.
2. Voraussetzungen
- Ubuntu-basierte Lab-Umgebung.
- Die Workshop-Dateien liegen lokal vor.
- Provisionierung wurde bei Bedarf mit
scripts/provision.sh --dry-rungeprüft. - Keine echten Secrets oder produktiven Daten verwenden.
3. Dateien
Die Dateien in diesem Verzeichnis bilden zusammen ein kleines, reviewbares Lab. Konfigurationen und Skripte sind bewusst klein gehalten, damit sie im Training besprochen werden können.
4. Ausführung
- Lies die README dieses Beispiels.
- Prüfe Skripte oder Konfigurationen vor der Ausführung.
- Führe nur nicht-destruktive Befehle direkt aus.
- Dokumentiere Abweichungen der lokalen Umgebung.
5. Erwartetes Ergebnis
Das Beispiel soll den beschriebenen Zielzustand nachvollziehbar machen und eine klare Validierung über Statusausgabe, Dateiinhalt, Testkommando oder Logeintrag erlauben.
6. Erklärung
Die Umsetzung demonstriert einen typischen Praxisbaustein. Wichtige Entscheidungen sind Reproduzierbarkeit, Lesbarkeit, sichere Dummy-Werte und einfache Rückbaubarkeit.
7. Typische Fehler
- Voraussetzungen oder Tools fehlen.
- Pfade werden aus einem anderen Arbeitsverzeichnis ausgeführt.
- Lokale Ports, Namen oder IP-Bereiche kollidieren.
- Beispielwerte werden versehentlich für produktive Systeme gehalten.
8. Erweiterungsmöglichkeiten
- Beispiel um eine zweite Umgebung erweitern.
- Validierung automatisieren.
- Security- und Troubleshooting-Notizen ergänzen.
- In eine Workshop-Übung oder Assessment-Frage überführen.