Einführung
Bereitstellungen verlaufen nicht immer wie geplant. Wenn etwas schiefgeht, benötigen Sie eine zuverlässige Methode zur Fehlerbehebung.
In diesem Lab lösen Sie „Der Fall des fehlenden Images“.
Bei der Fehlerbehebung in Kubernetes beginnt man häufig mit dem Objektstatus, untersucht anschließend die Events und führt danach eine detailliertere Prüfung durch. Dieses Lab konzentriert sich auf diesen evidenzbasierten Ablauf.
Sie werden:
- Einen Tatort schaffen: Einen absichtlich fehlerhaften Pod bereitstellen.
- Ermitteln: Mit dem „Fernglas“ (
get) feststellen, dass etwas nicht stimmt. - Beweise sammeln: Mit der „Lupe“ (
describe) die Ursache finden. - Den Fall lösen: Die Konfiguration korrigieren und beobachten, wie sich die Anwendung wieder erholt.
Einen fehlerhaften Pod erstellen
Beginnen Sie, indem Sie einen Pod mit einem absichtlichen Tippfehler bereitstellen. Damit simulieren Sie einen häufigen Fehler: die Angabe eines Images, das nicht existiert.
Das zeigt auch, dass Kubernetes viele Manifeste akzeptiert, deren Probleme erst später erkannt werden. Eine YAML-Datei kann syntaktisch korrekt und trotzdem im Betrieb fehlerhaft sein. Bei der Fehlerbehebung müssen Sie daher unterscheiden: „Wurde das Objekt akzeptiert?“ und „Ist der Workload tatsächlich korrekt gestartet?“
Erstellen Sie eine Datei mit dem Namen broken-pod.yaml:
nano broken-pod.yaml
Fügen Sie den folgenden Inhalt ein. Beachten Sie den verdächtigen Image-Tag wrongtag123.
apiVersion: v1
kind: Pod
metadata:
name: broken-pod
spec:
containers:
- name: nginx
image: nginx:wrongtag123
Speichern Sie die Datei und beenden Sie den Editor (Ctrl+X, Y, Enter).
Stellen Sie den Pod bereit:
kubectl apply -f broken-pod.yaml
Kubernetes akzeptiert die Datei, weil das YAML-Format korrekt ist. Der „Fall“ wurde jedoch noch nicht erkannt.
Den Fehler beobachten
Sehen Sie sich nun den Status des bereitgestellten Pods an. Das entspricht dem Einsatz eines Fernglases, um die Situation zu überblicken.
Statuswerte wie ErrImagePull und ImagePullBackOff sind Symptome und noch keine abschließenden Erklärungen. Sie zeigen Ihnen, wo Sie als Nächstes suchen sollten. Eine gute Fehleranalyse betrachtet die Statusausgabe als ersten Hinweis und nicht als vollständige Diagnose.
Prüfen Sie die Pods im Namespace default:
kubectl get pods
Zunächst sehen Sie möglicherweise ContainerCreating. Nach einigen Sekunden ändert sich der Status jedoch wahrscheinlich in ImagePullBackOff oder ErrImagePull.
ImagePullBackOff bedeutet in der Kubernetes-Sprache: „Ich habe versucht, dieses Image abzurufen, bin aber gescheitert. Ich warte jetzt eine Weile und versuche es später erneut.“
Damit ist bestätigt, dass das „Opfer“, also der Pod, nicht fehlerfrei ist.
Events untersuchen
Wir wissen, dass der Start fehlgeschlagen ist, aber noch nicht, warum. Um das herauszufinden, müssen wir die Situation genauer untersuchen.
Der Befehl kubectl describe ist Ihre Lupe. Er zeigt interne Events und Protokolle einer bestimmten Ressource an.
Der Abschnitt Events ist besonders wertvoll, weil er eine kurze Abfolge der Vorgänge durch Kubernetes-Komponenten wie den Scheduler und den Kubelet enthält. Wenn Anfänger ohne Prüfung der Events direkt zufällige Änderungen vornehmen, verschwenden sie oft Zeit damit, das falsche Problem zu lösen.
Untersuchen Sie den fehlerhaften Pod:
kubectl describe pod broken-pod
Dieser Befehl gibt viele Informationen aus. Scrollen Sie ganz nach unten, um den Abschnitt Events zu finden.
Sie sollten ungefähr Folgendes sehen:
Type Reason Message
---- ------ -------
Normal Pulling Pulling image "nginx:wrongtag123"
Warning Failed Failed to pull image "nginx:wrongtag123": manifest unknown
Warning Failed Error: ErrImagePull
Die Meldung manifest unknown ist der entscheidende Hinweis. Sie bedeutet, dass die Docker-Registry, in der die Images gespeichert sind, keinen Eintrag für nginx:wrongtag123 besitzt.
Der Fall ist gelöst: Der Image-Tag ist ungültig.
Den Pod korrigieren
Da wir nun die Ursache kennen, können wir den Fehler beheben.
Dieser letzte Schritt zeigt außerdem ein allgemeineres Vorgehen: Beobachten Sie das Problem, formulieren Sie auf Grundlage der Beweise eine Hypothese, nehmen Sie eine gezielte Änderung vor und überprüfen Sie anschließend die Wiederherstellung. Dieser disziplinierte Ablauf ist zuverlässiger, als mehrere vermutete Änderungen gleichzeitig vorzunehmen.
Öffnen Sie die Datei broken-pod.yaml erneut:
nano broken-pod.yaml
Korrigieren Sie den „Tippfehler“. Ändern Sie nginx:wrongtag123 einfach in nginx. Dadurch wird standardmäßig nginx:latest verwendet, ein gültiges Image.
apiVersion: v1
kind: Pod
metadata:
name: broken-pod
spec:
containers:
- name: nginx
image: nginx
Speichern Sie die Datei und beenden Sie den Editor.
Wenden Sie die Korrektur an. Kubernetes kann den vorhandenen Pod mit den neuen Informationen aktualisieren.
kubectl apply -f broken-pod.yaml
Beobachten Sie nun die Wiederherstellung:
kubectl get pods -w
Der Status sollte sich von ImagePullBackOff zu Running ändern.
Drücken Sie Ctrl+C, um die Überwachung zu beenden.
Gute Arbeit, Detektiv! Sie haben den Fehler gefunden und den Dienst erfolgreich wiederhergestellt.
Zusammenfassung
In diesem Lab haben Sie den grundlegenden Ablauf zur Fehlerbehebung in Kubernetes kennengelernt:
- Beobachten: Prüfen Sie mit
kubectl get pods, welche Workloads fehlschlagen. - Untersuchen: Verwenden Sie
kubectl describe pod, um das Event-Protokoll anzuzeigen und Fehlermeldungen zu finden. - Beheben: Aktualisieren Sie das YAML-Manifest und wenden Sie die Korrektur an.
Dieser Ablauf – Get, Describe, Fix – behebt 90 % der Bereitstellungsprobleme, mit denen Sie im Laufe Ihrer Kubernetes-Karriere konfrontiert werden.
