Fehlersuche

Geh von dem aus, was du siehst, nicht von dem, was deiner Vermutung nach kaputt ist. Jeder Eintrag unten ist ein Symptom, und jede Seite sagt dir, wie du die Ursache bestätigst, bevor du etwas änderst.

Finde dein Symptom

Was du siehst	Wohin
Forbidden bei einem kubectl-Befehl	Die API sagt nein
admission webhook denied the request	Die API sagt nein
Exec/attach is only allowed into gVisor-sandboxed pods	Die API sagt nein
Hostname is not allowed in namespace	Die API sagt nein
Pod hängt in Pending	Ein Pod startet nicht
ImagePullBackOff	Ein Pod startet nicht
CrashLoopBackOff	Ein Pod startet nicht
Dein Hostname löst nicht auf oder liefert nichts	Deine App ist nicht erreichbar
Der Browser warnt wegen des Zertifikats	Deine App ist nicht erreichbar
Die Seite kommt über einfaches HTTP	Deine App ist nicht erreichbar
Eine Verbindung aus dem Cluster hängt oder wird abgelehnt	Ausgehende Verbindungen scheitern
Ein HPA skaliert nicht	Skalierung tut nicht, was du erwartest
Ein schlafender Workload wacht nie auf oder schläft nie ein	Skalierung tut nicht, was du erwartest
Ein PVC bleibt Pending	Überraschungen bei Storage und Kosten
Ein Volume wächst immer weiter	Überraschungen bei Storage und Kosten
Die Rechnung ist höher als erwartet	Überraschungen bei Storage und Kosten

Die drei Befehle, die du zuerst probieren solltest

Die meisten Antworten stehen in einem davon, und sie kosten nichts:

kubectl get pods
kubectl describe pod <name>
kubectl logs deployment/<name>

describe ist der, den die meisten überspringen. Die Events am Ende der Ausgabe nennen den Grund fast immer direkt, und sie sind der Unterschied zwischen Raten und Wissen.

Hat ein Container schon neu gestartet, stammt sein aktuelles Log aus dem neuen Versuch und sagt nichts über den Fehler aus. Frag den vorherigen ab:

kubectl logs deployment/<name> --previous

Wie es weitergeht

• Berechtigungen und Richtlinien, was du überhaupt darfst
• Zugang und kubectl, wenn gar nichts funktioniert