Debugging

Ziel

In diesem Hands-On lernen Sie, wie Sie Probleme in einem Kubernetes-Cluster debuggen können. Sie werden:

die Logs von Pods und Systemkomponenten analysieren
den Status von Nodes und Pods überprüfen
häufige Fehlerursachen identifizieren und beheben

Hilfsmittel

Versuchen Sie, die unten stehenden Aufgaben mit Hilfe der Schulungsunterlagen und Ihres bisherigen Wissens aus den vorherigen Labs eigenständig zu lösen.
Sollten Sie dabei Probleme haben, finden Sie bei jeder Aufgabe einen ausklappbaren Block, in dem der Lösungsweg beschrieben wird.

Szenario 1

1.1: Initialisieren

Führen Sie das Script destructor-1.sh aus.

1.2: Umgebung aufsetzen

Sie haben festgestellt, dass der worker-1 eine hohe Auslastung hat, während worker-0 kaum ausgelastet ist. Es scheinen auch einige Services instabil zu sein. Sie möchten die Ursache für die hohe Auslastung und die Instabilität der Services herausfinden.

Starten Sie ein Testdeployment mit 10 Replikas:

kubectl create deployment nginx-test --image=nginx --replicas=10

Beobachten Sie ob sich die Pods auf den beiden Workern unterschiedlich verhalten.
Lösen Sie die Ursache für die hohe Auslastung auf worker-1 und die Instabilität der Services.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

Mit kubectl get pods -o wide können Sie sehen, auf welchen Nodes die Pods laufen.
Die Pods werden nur auf worker-1 geplant
Mit kubectl get nodes sehen Sie, dass worker-0 als NotReady markiert ist.
Mit kubectl describe node worker-0 sehen Sie, dass es auf dem Worker einen Fehler mit containerd gibt.
Loggen Sie sich auf worker-0 ein und lassen Sie sich den Status von containerd anzeigen:
```
systemctl status containerd
```
Starten Sie containerd:
```
systemctl start containerd
```
Die Node sollte jetzt wieder Ready sein.

Skalieren Sie das Deployment auf 20 Replikas:

kubectl scale deployment nginx-test --replicas=20

Beobachten Sie, dass die Pods jetzt auf beide Worker verteilt werden.

Skallieren Sie das Deployment anschließend wieder auf 0 Replikas, damit es keine Ressourcen im Cluster verbraucht:

kubectl scale deployment nginx-test --replicas=0

Szenario 2

2.1: Initialisieren

Führen Sie das Script destructor-2.sh aus.

2.2: Umgebung aufsetzen

Skalieren Sie das Deployment nginx-deployment auf 5 Replikas:

kubectl scale deployment nginx-deployment --replicas=5

Beobachten Sie was passiert.
Finden Sie heraus warum die Pods nicht starten und lösen Sie das Problem.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

Mit kubectl get pods sehen Sie, dass die Pods im Pending Status sind.
Mit kubectl describe pod <pod-name> sehen Sie, dass es keine Events gibt, die auf einen Fehler bei der Planung hinweisen.
Mit kubectl get pods -n kube-system sehen Sie, dass der kube-scheduler Probleme hat.
Mit kubectl logs -n kube-system <kube-scheduler-pod-name> sehen Sie keine Logs, da der Scheduler gar nicht startet.
Mit kubectl describe pod <kube-scheduler-pod-name> -n kube-system sehen Sie, dass das Binary des Schedulers nicht gefunden wird.
Loggen Sie sich auf der Controlplane Node ein und prüfen Sie den Inhalt des /etc/kubernetes/manifests Verzeichnisses.
Das Manifest des Schedulers verweist auf ein nicht existierendes Binary.
Korrigieren Sie den Pfad zum Binary zu kube-scheduler und speichern Sie die Datei.
Der Scheduler sollte jetzt starten und die Pods sollten geplant werden.

Szenario 3

3.1: Initialisieren

Führen Sie das Script destructor-3.sh aus.

3.2: Umgebung aufsetzen

Skalieren Sie das Deployment nginx-deployment auf 5 Replikas:

kubectl scale deployment nginx-deployment --replicas=5

Erstellen Sie einen Service für das Deployment:

kubectl expose deployment nginx-deployment --port=80 --target-port=80

Testen Sie den Service mit einem temporären Pod:

kubectl run test -it --image=alpine --rm -- sh

wget -O- nginx

Der Service ist nicht erreichbar. Finden Sie heraus warum und lösen Sie das Problem.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

Mit kubectl get pods sehen Sie, dass die Pods im Running Status sind.
Mit kubectl get svc sehen Sie, dass der Service eine ClusterIP hat.
Machen Sie ein wget auf die ClusterIP des Services, z.B. wget -O- <cluster-ip>.
Der Service ist erreichbar, aber nur über die IP-Adresse, nicht über den DNS-Namen nginx.
Mit kubectl get pods -n kube-system sehen Sie, dass der coredns Pod Probleme hat.
Mit kubectl logs -n kube-system <coredns-pod-name> sehen Sie, dass es ein Problem mit der Konfiguration von CoreDNS gibt.
Mit kubectl get configmap -n kube-system coredns -o yaml sehen Sie, dass die Konfiguration von CoreDNS fehlerhaft ist.
Mit kubectl edit configmap -n kube-system coredns können Sie die Konfiguration von CoreDNS korrigieren.
- Ersetzen Sie readyyyy durch ready und speichern Sie die Datei.
Sobald die Konfiguration korrigiert ist, sollte der DNS-Name nginx auflösbar sein und der Service sollte erreichbar sein.

Szenario 4

4.1: Initialisieren

Führen Sie das Script destructor-4.sh aus.

4.2: Debuggen

Versuchen Sie eine der folgenden Aktionen durchzuführen und beobachten Sie die Fehlermeldungen:
- kubectl get nodes
- kubectl get pods
Beheben Sie den Fehler und erlangen Sie wieder Zugriff auf den Cluster.

Lösung (Klicken Sie auf den Pfeil, falls Sie nicht weiterkommen)

Mit kubectl get nodes sehen Sie, dass Kubernetes keine Verbindung zum API-Server herstellen kann.
Mit crictl ps sehen Sie, dass der kube-apiserver nicht läuft.
Nutzen Sie crictl ps -a um auch die gestoppten Container zu sehen und identifizieren Sie den Container des kube-apiservers.
Mit crictl logs <kube-apiserver-container-id> sehen Sie, dass der kube-apiserver wegen eines Fehlers in seinem Command-Argument nicht startet.
Öffnen Sie die Manifest-Datei des kube-apiservers unter /etc/kubernetes/manifests/kube-apiserver.yaml und korrigieren Sie den Fehler im Command-Argument.
- Ersetzen Sie allow-privileged=trueeee durch allow-privileged=true und speichern Sie die Datei.
Der kube-apiserver sollte jetzt starten und der Cluster sollte wieder erreichbar sein.