"나는 분명
kubectl apply했을 뿐인데…"
쿠버네티스 쓰다 보면 가장 많이 보는 에러 상태 1위:
Pod가 뜨긴 뜨는데, 몇 초 지나면 죽고, 다시 뜨고, 또 죽고…
결국 kubectl get pods 찍으면 무한 루프처럼 CrashLoopBackOff 🌀
이 순간 개발자 멘탈 상태:

즉, “얘가 죽었으니 다시 켜볼까? … 또 죽었네? 그럼 쉬었다 다시 켜보자”
쿠버네티스가 부모님 모드로 계속 살려보는 상태.

resources.limits.memory 넘으면 → 컨테이너 강제 종료dmesg | grep -i kill 하면 OOM 로그 볼 수 있음 npm start에서 문법 에러, DB 연결 실패)
kubectl logs는 CrashLoopBackOff의 친구다./health API가 10초 걸리는데, 타임아웃을 1초로 줌 🤦👉 해결: Probe 설정은 꼭 서비스 특성에 맞춰 튜닝
👉 해결: kubectl describe pod 찍으면 이벤트 로그에서 원인 나옴
command나 args 오타 → 컨테이너 들어가자마자 “command not found”
👉 해결: Dockerfile ENTRYPOINT와 Deployment yaml 확인
CrashLoopBackOff 디버깅할 때 자주 보는 코드들:
| Exit Code | 의미 | 흔한 원인 | 내 멘탈 상태 |
|---|---|---|---|
| 137 | OOMKilled | 메모리 부족 | “램 좀 더 달라…” 🥲 |
| 1 | 일반 에러 | 애플리케이션 종료, 스크립트 실패 | “로그 열심히 까야겠네” |
| 139 | Segmentation Fault | 네이티브 라이브러리 크래시, 잘못된 메모리 접근 | “C/C++ 냄새 난다…” |
| 143 | SIGTERM | 정상 종료 신호 (종종 스케일 다운/재시작) | “아, 그냥 재시작이었네” 😅 |
| 0 | 정상 종료 | 컨테이너가 할 일 다 하고 종료 | “에러 아님. 설마 배치 잡인데 서비스처럼 띄운 건 아니겠지?” |
kubectl logs -f pod-name → 애플리케이션 로그 확인 kubectl describe pod pod-name → 이벤트/exit code 확인 kubectl get events --sort-by=.metadata.creationTimestamp → 최근 이벤트 순으로 보기 kubectl logs --previous로 이전 실행 로그 확인 가능결국 CrashLoopBackOff는 라면 끓이다 중간중간 실패하는 상황과 비슷합니다.
(라면도 K8s도 타이밍이 중요하다)
CrashLoopBackOff는 무섭지 않습니다.
👉 로그 보고, 이벤트 확인하고, Exit Code 뜯어보면 답이 있음.
다음부터는 Pod가 CrashLoopBackOff 뜰 때 이렇게 외치세요:
“괜찮아, 로그 보면 다 나와 있어.” 😎