Einführung
In diesem Lab lernen Sie die wichtigsten Techniken für die Interaktion mit laufenden Pods. Diese grundlegenden Debugging-Fähigkeiten sind in Kubernetes besonders wichtig, weil Workloads oft verteilt sind und nicht so direkt sichtbar werden wie lokale Prozesse.
Wir behandeln drei wichtige Debugging-Techniken:
- Logs: Lesen Sie das „Tagebuch“ Ihrer Anwendung, um zu sehen, was sie ausgibt.
- Exec: Wechseln Sie in den Container, um sich dort umzusehen und Befehle auszuführen.
- Port Forwarding: Erstellen Sie einen temporären Tunnel, um von Ihrem lokalen Computer auf Ihre Anwendung zuzugreifen.
Diese Fähigkeiten sind für DevOps Engineers und Entwickler grundlegend. Am Ende dieses Labs können Sie laufende Pods sicher untersuchen.
Logs anzeigen
In diesem Schritt lernen Sie, wie Sie die Logs eines laufenden Pods untersuchen. Stellen Sie sich Logs als die „Stimme“ Ihrer Anwendung vor. Wenn etwas schiefläuft, sind die Logs meist der erste Ort, an dem Sie nach Hinweisen suchen.
Intern liest kubectl logs normalerweise das, was der Hauptprozess des Containers in die Standardausgabe und die Standardfehlerausgabe geschrieben hat. Deshalb sind viele containerisierte Anwendungen so konzipiert, dass sie in das Terminal loggen, statt in lokale Dateien zu schreiben. In Kubernetes kann die Plattform die Terminalausgabe leichter und einheitlicher sammeln und bereitstellen.
Die Umgebung startet im Hintergrund einen Pod namens my-nginx für Sie. Warten Sie zunächst, bis der Pod erstellt wurde:
until kubectl get pod my-nginx > /dev/null 2>&1; do sleep 2; done
Warten Sie anschließend, bis der Container bereit ist:
kubectl wait --for=condition=ready pod/my-nginx --timeout=300s
Überprüfen Sie nun, ob der Pod läuft:
kubectl get pods
my-nginx sollte mit dem Status Running angezeigt werden. Falls der Pod noch nicht bereit ist, warten Sie einen Moment und versuchen Sie es erneut.
Sobald der Pod läuft, lesen Sie mit dem Befehl kubectl logs, was der Container in die Standardausgabe geschrieben hat:
kubectl logs my-nginx
Da Nginx ein stabiler Webserver ist, kann die Ausgabe anfangs kurz ausfallen oder nur eine Meldung enthalten, dass der Server für Verbindungen bereit ist.
Um die Logs in Echtzeit zu verfolgen, fügen Sie die Option -f (follow) hinzu:
kubectl logs -f my-nginx
Der Cursor bleibt sichtbar und wartet auf neue Meldungen. Das eignet sich gut, um eingehenden Datenverkehr live zu beobachten. Drücken Sie Ctrl+C, um das Verfolgen der Logs zu beenden und zur Shell-Eingabeaufforderung zurückzukehren.
Mit Exec in den Container wechseln
In diesem Schritt gehen Sie über das Lesen von Logs hinaus und führen Befehle im Pod aus. Möglicherweise müssen Sie prüfen, ob eine Konfigurationsdatei vorhanden ist, ob ein bestimmtes Tool installiert ist oder ob die Netzwerkverbindung innerhalb des Pods funktioniert.
Dafür verwenden Sie den Befehl kubectl exec. Damit können Sie einen Befehl in einem laufenden Container ausführen. Häufig öffnen wir damit eine interaktive Shell und wechseln so gewissermaßen in den Container.
Dabei ist ein wichtiger Unterschied zu beachten: kubectl exec „bewegt“ Sie nicht auf eine andere Maschine wie SSH. Stattdessen weist es den kubelet auf dem Node an, einen neuen Prozess in einem bereits laufenden Container zu starten. Deshalb sehen Sie das Dateisystem und die Umgebung des Containers und nicht die Umgebung Ihres lokalen Terminals.
Führen Sie den folgenden Befehl aus, um im Pod my-nginx eine bash-Shell zu öffnen:
kubectl exec -it my-nginx -- /bin/bash
Sehen wir uns die Optionen an:
-i(Interactive): Hält die Eingabe offen, damit Sie Befehle eingeben können.-t(TTY): Weist ein Pseudo-Terminal zu, sodass die Shell wie eine normale Eingabeaufforderung aussieht.--: Teilt kubectl mit, dass alles danach ein Befehl für den Container und nicht für kubectl ist.
Ihre Eingabeaufforderung sollte sich in etwas wie root@my-nginx:/# ändern. Sie befinden sich jetzt im konkreten Container im Kubernetes-Cluster.
Listen Sie die Dateien im aktuellen Verzeichnis auf, um zu bestätigen, dass Sie sich in einer neuen Umgebung befinden:
ls -F
Sie sehen die Dateien im Nginx-Container. Diese sind vollständig von den Dateien in Ihrem LabEx-Arbeitsbereich getrennt.
Die Umgebung untersuchen
In diesem Schritt untersuchen Sie die Umgebung im Container. Eine typische Debugging-Aufgabe besteht darin, zu prüfen, welches Betriebssystem (OS) im Container ausgeführt wird. So erkennen Sie, welche Befehle wie apt oder apk verfügbar sind.
Dabei lernen Sie außerdem eine wichtige Eigenschaft von Containern kennen: Das Container-Image bestimmt, welche Tools und Dateien im User Space verfügbar sind. Zwei Pods können beide Linux verwenden und sich trotzdem stark unterscheiden, weil das eine Image auf Debian basiert, das andere auf Alpine und ein weiteres möglicherweise fast keine Shell-Tools enthält.
Führen Sie den folgenden Befehl aus, solange Ihre Eingabeaufforderung noch root@my-nginx:/# lautet. Damit lesen Sie die Datei mit den Informationen zum Betriebssystem:
cat /etc/os-release
Die Ausgabe enthält den Namen der Linux-Distribution, wahrscheinlich „Debian GNU/Linux“. Das liegt daran, dass das offizielle Nginx-Image auf Debian basiert.
Wenn Sie mit der Untersuchung fertig sind, verlassen Sie den Container und kehren Sie zu Ihrem Hauptterminal zurück. Geben Sie Folgendes ein:
exit
Ihre Eingabeaufforderung wird wieder zu labex:~/project.
Um zu bestätigen, dass Sie diese Untersuchung abgeschlossen haben, erstellen Sie die Datei os_version.txt und schreiben Sie den Namen des ermittelten Betriebssystems, zum Beispiel „Debian“, hinein.
echo "Debian" > ~/project/os_version.txt
Port Forwarding
In diesem Schritt greifen Sie mithilfe von Port Forwarding auf den Nginx-Pod zu. Pods sind standardmäßig isoliert. Sie ähneln Häusern in einer abgeschlossenen Wohnanlage: Sie können miteinander kommunizieren, aber Außenstehende wie Sie an Ihrem lokalen Terminal können sie nicht einfach erreichen.
Um von Ihrem lokalen Computer aus auf den Webserver in my-nginx zuzugreifen, erstellen Sie einen temporären Tunnel mit Port Forwarding.
Port Forwarding ist eine praktische Debugging-Möglichkeit, aber nicht die übliche Methode, Anwendungen in einer Produktionsumgebung zu veröffentlichen. Es erstellt einen temporären Tunnel von Ihrer aktuellen Workstation zu einem einzelnen Pod. Das eignet sich ideal für Untersuchungen und schnelle Tests, weil Sie dafür keinen vollständigen Service erstellen und keine externen Netzwerkrichtlinien ändern müssen.
Führen Sie den folgenden Befehl aus, um den lokalen Port 8080 an Port 80 des Pods weiterzuleiten:
kubectl port-forward my-nginx 8080:80 &
Achten Sie auf das & am Ende! Dadurch wird Linux angewiesen, den Prozess im Hintergrund auszuführen. Ohne dieses Zeichen würde der Befehl Ihr Terminal blockieren, sodass Sie bis zum Beenden des Prozesses nichts anderes eingeben könnten.
Sie sollten eine Meldung wie Forwarding from 127.0.0.1:8080 -> 80 sehen.
Nun können Sie die Nginx-Webseite über diesen Tunnel mit curl aufrufen:
curl localhost:8080
Sie sollten den HTML-Code der Seite „Welcome to nginx!“ sehen. Das war erfolgreich: Sie haben den Cluster über den Tunnel erreicht und Daten daraus abgerufen.
Zusammenfassung
In diesem Lab haben Sie drei wichtige Fähigkeiten zum Debuggen von Kubernetes-Anwendungen geübt:
- Logs: Mit
kubectl logsdie Ausgabe Ihrer Anwendung prüfen. - Exec: Mit
kubectl execin die Containerumgebung wechseln, um Dateien zu untersuchen und Befehle auszuführen. - Port Forwarding: Mit
kubectl port-forwardlokal auf interne Services zugreifen.
Diese Tools sind Ihr Stethoskop und Ihr Röntgengerät. Wenn in Kubernetes ein Problem auftritt, greifen Sie zuerst zu diesen Werkzeugen, um die Ursache zu untersuchen.


