Vom Incident-Rauschen
zu operativer Klarheit.
Erleben Sie einen simulierten Kubernetes-Incident. Entdecken Sie, wie Belege, Kontext und KI-gestützte Empfehlungen bei Entscheidungen helfen können – ohne einen echten Cluster zu verändern.
Untersuchen Sie einen CrashLoopBackOff.
Folgen Sie den Belegen durch einen fünfstufigen Incident-Ablauf mit menschlicher Kontrolle.
Ein Workload startet immer wieder neu.
Der Pod payment-api scheitert wiederholt beim Start. Kubernetes meldet CrashLoopBackOff, doch dieser Status erklärt nicht die eigentliche Ursache.
Den Neustart als Symptom betrachten. Exit-Grund des Containers, aktuelle Events und Anwendungslogs prüfen, bevor eine Hypothese aufgestellt wird.
Keine Live-Cluster-Verbindung. Alle Ereignisse sind synthetisch.
$ kubectl get pods -n demo-app
payment-api-7d9f 0/1 CrashLoopBackOff 6 8m
$ kubectl describe pod payment-api-7d9f -n demo-app
Warning BackOff Back-off restarting failed containerAls Nächstes: eine Read-only-Vorschau.
Diese Demo zeigt ein statisches, synthetisches Szenario. Die separat geplante registrierte Console-Vorschau soll einen begrenzten Read-only-Zugriff auf einen gemeinsamen Demo-Cluster nutzen. Hier sind weder Anmeldung noch Cluster-Anbindung oder die Ausführung von Remediation möglich.