Een geïmplementeerde microservice Pod bevindt zich in CrashLoopBackOff. Welke stap voor probleemoplossing geeft de meest directe informatie over waarom de Pod herhaaldelijk niet kan starten?

De CrashLoopBackOff-status geeft aan dat een Pod herhaaldelijk crasht na het opstarten. De meest directe manier om de oorzaak hiervan te achterhalen, is door de logs van de Pod te inspecteren. Het commando kubectl logs PODNAME haalt de logs op, en voor een CrashLoopBackOff-situatie is het cruciaal om ook de logs van eerdere runs te bekijken (vaak met de --previous vlag, hoewel de optie dit niet expliciet vermeldt, is het de impliciete intentie bij het analyseren van crashes). De andere opties zijn minder direct of irrelevant: kubectl exec is nuttig als de Pod draait, maar in CrashLoopBackOff is de Pod niet stabiel genoeg om een shell-sessie te starten. Bovendien bevinden applicatielogs zich zelden in /var/log/messages binnen een container. Het controleren van IAM-rechten voor Artifact Registry is relevant als de Pod de containerimage niet kan pullen, maar dit zou zich manifesteren als een ImagePullBackOff-status, niet CrashLoopBackOff. Het controleren van geweigerd uitgaand verkeer naar Private Google Access is relevant voor netwerkproblemen, maar niet de primaire oorzaak van een applicatie die direct na het opstarten crasht.