한눈에 보기
- AKS에서 파드가 CrashLoopBackOff로 계속 재시작될 때, 원인을 좁히는 5단계 순서를 정리합니다.
- 핵심은 describe → 이전 로그 → 종료코드 → 프로브 → 리소스를 차례로 보는 것.
- 대부분 설정·이미지·헬스체크·리소스 부족 중 하나입니다.
CrashLoopBackOff는 ‘컨테이너가 시작 직후 죽고, 쿠버네티스가 점점 간격을 늘려 재시작하는’ 상태입니다. 에러가 아니라 ‘증상’이라, 진짜 원인은 로그와 종료코드에 있습니다. 순서대로 좁혀봅시다.
1단계: 파드 상태와 이벤트 보기
kubectl describe의 하단 이벤트와 재시작 횟수, 마지막 상태(Last State)의 종료 코드를 확인합니다.
kubectl describe pod <POD> -n <NS>
# 하단 Events와 Last State: Terminated의 Exit Code 확인2단계: ‘이전’ 컨테이너 로그 보기
이미 죽었으므로 현재 로그가 아니라 –previous로 직전에 죽은 컨테이너 로그를 봐야 진짜 에러가 나옵니다.
kubectl logs <POD> -n <NS> --previous3단계: 종료 코드로 원인 좁히기
| 종료 코드 | 의미 | 흔한 원인 |
|---|---|---|
| 0 직후 종료 | 정상 종료인데 재시작 | 메인 프로세스가 백그라운드로 빠짐 |
| 1 / 일반 오류 | 앱 자체 예외 | 설정값·환경변수 누락 |
| 137 (OOMKilled) | 메모리 초과 | limits 너무 낮음 |
| 143 | SIGTERM | 헬스체크 실패로 강제 종료 |
4단계: 헬스체크(프로브) 점검
앱은 멀쩡한데 liveness 프로브가 너무 빡세면 부팅 중에 죽습니다. initialDelaySeconds를 늘리거나 프로브 경로·포트가 맞는지 확인하세요.
5단계: 리소스·이미지 확인
- OOMKilled(137)면 메모리 limit을 올리거나 앱 메모리 사용을 줄입니다.
- ImagePullBackOff를 동반하면 이미지 태그·ACR 권한 문제입니다.
- ConfigMap/Secret 누락이면 마운트·키 이름을 확인합니다.
흔한 실수
- –previous 없이 현재 로그만 봄 — 비어 있거나 엉뚱한 로그만 나옵니다.
- limits를 0으로 두거나 과하게 낮춤 — OOM 반복.
- 프로브를 끄고 덮기 — 증상은 사라져도 근본 원인이 남습니다.
자주 묻는 질문(FAQ)
- Q. 로그가 비어 있어요. A. –previous를 쓰거나, 그래도 없으면 describe의 이벤트와 종료코드로 추적하세요.
- Q. 137이 자꾸 떠요. A. OOMKilled입니다. 메모리 limit 상향 또는 앱 최적화가 필요합니다.
- Q. 로컬에선 되는데 AKS에서만 죽어요. A. 환경변수·Secret·프로브 설정 차이를 먼저 의심하세요.
마치며
CrashLoopBackOff는 ‘증상’입니다. describe → –previous 로그 → 종료코드 → 프로브 → 리소스 순서면 대부분 10분 안에 진짜 원인이 드러납니다.