Wenn etwas nicht läuft
Die Handvoll Fehler, die die meisten ausmachen, woran du sie erkennst und was zu tun ist.
Auf dieser Seite
Fang hier an
klickops versucht, in einem Satz am Workload selbst zu sagen, was los ist. Lies also zuerst die Statuszeile. Danach den Tab Logs, denn dort steht der Bericht des Containers über sein eigenes Ende.
Drei Fragen klären das meiste. Ist er je gestartet? Ist er gestartet und dann gestorben? Oder läuft er und ist bloss nicht erreichbar? Das sind verschiedene Probleme, und die Abschnitte unten folgen dieser Reihenfolge.
Er startet gar nicht
Das Image lässt sich nicht ziehen. Der Name stimmt nicht, der Tag existiert nicht, oder die Registry braucht Zugangsdaten, die klickops nicht hat. Prüf die genaue Referenz, und bei einer privaten Registry, ob Pull-Credentials hinterlegt sind. Ein Tippfehler im Tag sieht genauso aus wie ein fehlendes Image.
Die Projekt-Quota blockiert ihn. Der Status sagt das direkt: im Projekt ist nicht genug CPU oder Memory übrig, um ihn zu starten. Entweder du entfernst einen Workload oder du erhöhst die Quota. Eine so abgelehnte Datenbank bleibt für immer in einer Provisioning-Phase stehen, weil der Operator nie einen Pod bekommt, über den er berichten könnte.
Die Tarifgrenze hat abgelehnt. Das scheitert schon beim Anlegen, mit einer Meldung, die die Grenze benennt. Also sofort sichtbar statt als Hänger. Siehe Tarif und Kosten.
Er startet und stirbt
Er beendet sich sauber. klickops startet ihn neu, weil eine App laufen soll. Wenn die Sache wirklich einmal laufen und fertig sein soll, ist sie ein Scheduled Job und keine App.
Er stürzt beim Start ab. Der Grund steht in den Logs des gescheiterten Versuchs, und es ist meistens eines von drei Dingen: eine fehlende Umgebungsvariable, eine Datenbank, die er noch nicht erreicht, oder ein falscher Port. Prüf, ob der konfigurierte Port der ist, auf dem der Prozess tatsächlich lauscht.
Ihm geht der Speicher aus. Der Container wird beendet und neu gestartet, und die Zahl der Neustarts klettert weiter. Memory wird auf den tatsächlichen Verbrauch zugeschnitten, ein Prozess, der wirklich mehr braucht, bekommt also mehr. Ein Leck wird schlicht wiederholt beendet.
Ein gescheiterter Rollout reisst die laufende Version nicht mit. klickops wartet, bis die neuen Kopien ihren Health-Check bestehen, und zieht erst dann die alten ab. Ein kaputtes Image lässt also die vorherige Version weiterlaufen. Die App sieht ungesund aus, während sie es erneut versucht, und deine Nutzer merken nichts.
Er läuft, ist aber nicht erreichbar
Prüf zuerst den Health-Check. Datenverkehr wartet, bis der Port eine Verbindung annimmt. Ein Prozess, der auf einem anderen Port lauscht als dem konfigurierten, ist von innen gesund und von aussen unsichtbar.
Dann DNS. Löst der Hostname nicht auf, wurde nie ein Zertifikat ausgestellt und die Domain-Prüfung nie grün. Siehe Domains.
Dann die Firewall. Eine blockierte Verbindung läuft in einen Timeout statt abgewiesen zu werden, das sieht also nach Langsamkeit aus und nicht nach Ablehnung. Die Ansicht Flows zeigt abgelehnten Verkehr ausdrücklich, und das geht schneller als raten. Siehe Firewall.
Eine Datenbank hängt im Provisioning
Gib ihr zwei Minuten: ein PostgreSQL-Cluster braucht die wirklich zum Hochfahren. Danach ist die übliche Ursache die Projekt-Quota, siehe oben.
Meldet sie sich gesund und deine App kommt trotzdem nicht dran, liegt es fast nie an der Datenbank. Prüf, ob die App die Verknüpfung hat und ob beide im selben Projekt liegen, denn über eine Projektgrenze geht nichts ohne Firewall-Regel.
Wann du fragst
Wenn du den Namen des Workloads hast, den Zeitpunkt, ab dem es schiefging, und die genaue Meldung. Diese drei machen aus einem Gespräch eine Antwort.
Verwandt
- Backups und Wiederherstellung, wenn die Lösung zurück statt vorwärts heisst.
- Apps dazu, was jeder Tab zeigt.