CrashLoopBackOff 진단하기
이 문서는 쿠버네티스(Kubernetes)에서 CrashLoopBackOff가 발생했을 때 와탭 쿠버네티스 모니터링으로 원인을 진단하는 방법을 안내합니다. CrashLoopBackOff가 무엇이고 네 가지 원인을 kubectl describe pod의 Exit Code와 이벤트로 구분하는 방법은 CrashLoopBackOff 원인 4가지 구분법에서 먼저 확인할 수 있습니다.
진단이 어려운 이유
CrashLoopBackOff의 결정적 단서는 컨테이너가 처음 죽었을 때의 로그와 이벤트에 남습니다. 그런데 파드가 이미 여러 번 재시작된 뒤라면, 그 첫 순간의 로그는 새 컨테이너에 덮여 사라지고 이벤트도 오래되면 정리됩니다. 메모리가 한순간에 치솟아 죽었는지 서서히 차오르다 죽었는지는 그때의 추이를 봐야 알 수 있는데, 지나간 시점은 되돌려 보기 어렵습니다.
그래서 재시작이 잦은 문제일수록, 재시작 이력과 리소스 추이, 종료된 컨테이너의 로그를 시간 순으로 모아 두는 모니터링이 진단에 도움이 됩니다.
재시작 이력과 메모리 추이로 첫 죽음 되짚기
와탭 쿠버네티스 모니터링은 컨테이너의 재시작 이력과 리소스 추이를 시간 순으로 수집해 보존합니다. 그래서 이미 여러 번 재시작된 뒤에도 다음을 되짚어 볼 수 있습니다.
- 컨테이너가 처음 죽은 시점과 그동안의 재시작 횟수
- 죽기 직전의 메모리 추이(한순간에 치솟았는지, 서서히 증가했는지)
- 종료 시점의 Exit Code와 종료된 컨테이너의 로그
이 셋을 함께 보면 원인이 좁혀집니다. 메모리가 한계까지 차오르다 Exit Code 137로 죽었다면 메모리 부족(OOMKilled), 시작 직후 즉시 종료가 반복되면 설정 오 류, 외부 연결 오류가 반복되면 의존성 문제, 한참 정상이다가 주기적으로 죽으면 헬스체크 실패를 의심할 수 있습니다.
예시: 컨테이너 재시작 이력과 메모리 추이가 시간 순으로 쌓인 화면. 처음 죽은 시점과 메모리 변화, 종료된 컨테이너 로그를 되짚을 수 있습니다.
자연어로 원인 묻기
기록을 직접 뒤지는 대신, 쌓인 데이터를 근거로 원인을 정리해 달라고 자연어로 물을 수도 있습니다. 예를 들어 "왜 이 파드가 CrashLoopBackOff인가요?"처럼 물으면, 해당 파드의 재시작 이력과 메모리 추이, 종료 로그를 모아 원인 후보를 정리해 줍니다. 단서를 직접 찾아 읽는 수고를 덜고, 처음 보는 운영자도 어느 원인부터 확인해야 하는지 빠르게 좁힐 수 있습니다.