Wdrożony Pod mikroserwisu znajduje się w stanie CrashLoopBackOff. Który krok rozwiązywania problemów dostarcza najbardziej bezpośrednich informacji o tym, dlaczego Pod wielokrotnie nie uruchamia się?

Stan CrashLoopBackOff oznacza, że Pod wielokrotnie się uruchamia i natychmiast ulega awarii. Najbardziej bezpośrednim sposobem zdiagnozowania tego problemu jest sprawdzenie logów Poda. Polecenie kubectl logs PODNAME wyświetla logi kontenerów w Podzie. Dodatkowo, aby zobaczyć logi z poprzednich, nieudanych uruchomień, można użyć flagi --previous (np. kubectl logs PODNAME --previous). Logi te często zawierają komunikaty o błędach, które wyjaśniają, dlaczego aplikacja w Podzie nie uruchamia się poprawnie. Pozostałe opcje są mniej skuteczne lub nieadekwatne: Łączenie się z Podem za pomocą kubectl exec jest niemożliwe, gdy Pod jest w stanie CrashLoopBackOff, ponieważ kontener nie działa wystarczająco długo, aby nawiązać sesję. Nawet gdyby było możliwe, szukanie w /var/log/messages nie jest standardową praktyką w Kubernetes; logi aplikacji są zazwyczaj przekierowywane do stdout/stderr. Sprawdzanie uprawnień IAM Artifact Registry jest istotne, jeśli problem dotyczy pobierania obrazu kontenera, ale nie jest to najbardziej bezpośrednia metoda diagnozowania problemów z uruchomieniem samej aplikacji w Podzie, która już się uruchamia, ale ulega awarii. Sprawdzanie ruchu wychodzącego do Private Google Access dotyczy problemów z łącznością sieciową, a nie bezpośrednio z awariami aplikacji wewnątrz Poda.