38 Debugging

https://kubernetes.io/docs/tasks/debug/

38.1 Kubernetes Debugging im CKAD-Kontext

Debugging in Kubernetes, besonders im Zusammenhang mit der Certified Kubernetes Application Developer (CKAD) Prüfung, erfordert ein tief gehendes Verständnis der verschiedenen Ressourcen und deren Zusammenspiel. Ziel ist es, Probleme schnell zu identifizieren und zu beheben.

38.2 Debugging-Prozess

38.2.1 Pods überprüfen

Über kubectl get pods den Status der Pods überprüfen. Nicht laufende Pods mit kubectl describe pod [POD_NAME] untersuchen.

38.2.2 Logs einsehen

Mit kubectl logs [POD_NAME] die Ausgabe der Container ansehen, um Fehlermeldungen oder andere Hinweise zu identifizieren.

38.2.3 Konfiguration prüfen

Falsche Konfigurationen können zu Fehlern führen. Konfigurationen mit kubectl get und kubectl describe überprüfen.

38.2.4 Netzwerkprobleme analysieren

kubectl exec nutzen, um in einen Container einzusteigen und Netzwerk-Tools wie ping oder curl zu verwenden.

38.2.5 Ressourcenengpässe ermitteln

kubectl top verwenden, um CPU- und Speicherauslastung zu überwachen.

38.3 Hilfreiche Befehle

• kubectl get - Ressourcen auflisten
• kubectl describe - Detaillierte Informationen zu Ressourcen
• kubectl logs - Logs von Container anzeigen
• kubectl exec - Kommandos in einem Container ausführen
• kubectl top - Ressourcennutzung anzeigen

38.4 Tipps für die CKAD-Prüfung

• Vertrautheit mit der kubectl-Befehlsreferenz
• Übung im Lesen und Verstehen von Pod-Logs
• Wissen, wie man Liveness- und Readiness-Probes konfiguriert
• Netzwerkdiagnosefähigkeiten entwickeln

38.5 tl:dr

Effektives Debugging in Kubernetes setzt voraus, dass man mit kubectl effizient arbeitet, ein gutes Verständnis für Pod-Status und -Lebenszyklen hat, und weiß, wie man Logs und Metriken zur Fehlersuche heranzieht.

38.6 Debug_Pods

Application troubleshooting

Dieser Leitfaden hilft Benutzern, Anwendungen zu debuggen, die in Kubernetes bereitgestellt wurden und sich nicht korrekt verhalten. Dies ist kein Leitfaden für Personen, die ihren Cluster debuggen möchten. Für diesen Zweck sollten Sie diesen Leitfaden anschauen.

38.6.1 Diagnose des Problems

Der erste Schritt bei der Fehlersuche ist die Triage. Was ist das Problem? Liegt es an Ihren Pods, Ihrem Replication Controller oder Ihrem Service?

• Debugging Pods
• Debugging Replication Controllers
• Debugging Services

Der erste Schritt beim Debuggen eines Pods besteht darin, ihn sich anzusehen. Überprüfen Sie den aktuellen Zustand des Pods und kürzliche Ereignisse mit dem folgenden Befehl:

kubectl describe pods ${POD_NAME}

Schauen Sie sich den Zustand der Container im Pod an. Laufen sie alle? Gab es kürzlich Neustarts? Fahren Sie mit dem Debugging fort, abhängig vom Zustand der Pods.

38.6.2 Mein Pod bleibt im Status “pending”

Wenn ein Pod im Status “Pending” stecken bleibt, bedeutet dies, dass er nicht auf einem Knoten eingeplant werden kann. In der Regel liegt dies daran, dass nicht genügend Ressourcen eines Typs vorhanden sind, die die Planung verhindern. Schauen Sie sich die Ausgabe des Befehls kubectl describe ... oben an. Dort sollten Nachrichten vom Scheduler stehen, warum Ihr Pod nicht eingeplant werden kann. Gründe können sein:

• Sie haben nicht genügend Ressourcen: Möglicherweise haben Sie die Versorgung mit CPU oder Speicher in Ihrem Cluster erschöpft. In diesem Fall müssen Sie Pods löschen, Ressourcenanforderungen anpassen oder neue Knoten zu Ihrem Cluster hinzufügen. Weitere Informationen finden Sie im Dokument zu Rechenressourcen.
• Sie verwenden hostPort: Wenn Sie einen Pod an einen hostPort binden, gibt es eine begrenzte Anzahl von Orten, an denen der Pod eingeplant werden kann. In den meisten Fällen ist hostPort unnötig. Versuchen Sie, ein Service-Objekt zu verwenden, um Ihren Pod freizugeben. Wenn Sie hostPort benötigen, können Sie nur so viele Pods einplanen, wie es Knoten in Ihrem Kubernetes-Cluster gibt.

38.6.3 Mein Pod bleibt im Status “waiting”

Wenn ein Pod im Status “Waiting” feststeckt, wurde er einem Worker-Knoten zugewiesen, kann aber auf dieser Maschine nicht ausgeführt werden. Auch hier sollte die Information aus kubectl describe ... aufschlussreich sein. Der häufigste Grund für im Status “Waiting” feststeckende Pods ist ein Fehler beim Herunterladen des Images.

Es gibt drei Dinge zu überprüfen:

1. Stellen Sie sicher, dass Sie den Namen des Images korrekt haben.
2. Haben Sie das Image in das Registry hochgeladen?
3. Versuchen Sie, das Image manuell herunterzuladen, um zu sehen, ob das Image heruntergeladen werden kann. Zum Beispiel, wenn Sie Docker auf Ihrem PC verwenden, führen Sie docker pull <image> aus.

38.6.4 Mein Pod stürzt ab oder ist anderweitig ungesund

Sobald Ihr Pod eingeplant wurde, stehen die in Debug Running Pods beschriebenen Methoden zum Debuggen zur Verfügung.

38.6.5 Mein Pod läuft, aber macht nicht, was ich ihm gesagt habe

Wenn sich Ihr Pod nicht so verhält, wie Sie es erwarten, könnte es sein, dass es einen Fehler in Ihrer Pod-Beschreibung gab (z.B. die mypod.yaml-Datei auf Ihrem lokalen Rechner), und dass der Fehler stillschweigend ignoriert wurde, als Sie den Pod erstellt haben. Oft ist ein Abschnitt der Pod-Beschreibung falsch verschachtelt oder ein Schlüsselname ist falsch getippt, und so wird der Schlüssel ignoriert.

Das Erste, was Sie tun sollten, ist, Ihren Pod zu löschen und ihn erneut mit der Option --validate zu erstellen.

Zum Beispiel:

kubectl apply --validate -f mypod.yaml

Wenn Sie command als commnd falsch geschrieben haben, gibt kubectl einen Fehler wie diesen aus:

I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842 pods/mypod

Das Nächste, was zu überprüfen ist, ob der Pod auf dem apiserver mit dem Pod übereinstimmt, den Sie erstellen wollten (z.B. in einer yaml-Datei auf Ihrem lokalen Rechner). Zum Beispiel:

kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml

und dann manuell die ursprüngliche Pod-Beschreibung mit der, die Sie vom apiserver zurückbekommen haben, vergleichen, mypod-on-apiserver.yaml. Es wird typischerweise einige Zeilen in der “apiserver”-Version geben, die nicht in der Originalversion sind. Dies ist zu erwarten. Wenn es jedoch Zeilen im Original gibt, die nicht in der apiserver-Version sind, könnte dies auf ein Problem mit Ihrer Pod-Spezifikation hinweisen.

Replication Controller sind ziemlich unkompliziert. Sie können entweder Pods erstellen oder nicht. Wenn sie keine Pods erstellen können, beziehen Sie sich bitte auf die oben genannten Anweisungen, um Ihre Pods zu debuggen.

Sie können auch

kubectl describe rc ${CONTROLLER_NAME}

verwenden, um Ereignisse im Zusammenhang mit dem Replication Controller zu inspizieren.

Services bieten Lastausgleich über eine Reihe von Pods. Es gibt mehrere häufige Probleme, die dazu führen können, dass Services nicht richtig funktionieren. Die folgenden Anweisungen sollten helfen, Probleme mit Services zu debuggen.

Zuerst überprüfen Sie, ob es Endpunkte für den Service gibt. Für jedes Service-Objekt stellt der apiserver eine endpoints-Ressource zur Verfügung. Sie können diese Ressource mit folgendem Befehl anzeigen:

kubectl get endpoints ${SERVICE_NAME}

Stellen Sie sicher, dass die Endpunkte mit der Anzahl der Pods übereinstimmen, von denen Sie erwarten, dass sie Mitglieder Ihres Services sind. Zum Beispiel, wenn Ihr Service für einen nginx-Container mit 3 Replikaten ist, würden Sie erwarten, drei verschiedene IP-Adressen in den Endpunkten des Services zu sehen.

Und Sie können im Container des PODs eine Shell starten:

kubectl exec webserver -- /bin/bash

38.6.6 Mein Service hat keine Endpunkte

Wenn Ihnen Endpunkte fehlen, versuchen Sie, Pods mit den Labels aufzulisten, die der Service verwendet. Stellen Sie sich vor, Sie haben einen Service, bei dem die Labels sind:

.
.
.
    spec:   
        selector:     
            name: nginx     
            type: frontend

Sie können kubectl get pods --selector=name=nginx,type=frontend verwenden, um Pods aufzulisten, die zu diesem Selector passen. Überprüfen Sie, ob die Liste mit den Pods übereinstimmt, von denen Sie erwarten, dass sie Ihren Service bereitstellen.

Überprüfen Sie, ob der containerPort des Pods mit dem targetPort des Services übereinstimmt.