CrashLoopBackOff 원인 분류

CrashLoopBackOff는 컨테이너가 반복적으로 비정상 종료되고 있다는 결과 상태다.

중요한 것은 왜 났는가에 관한 원인 분류고 나눠보겠다.

애플리케이션 즉시 종료 계열 (가장 흔함) #

프로세스가 바로 exit되는것인데 main이 종료된다거나 데몬으로 떠야하는데 foreground proc이 없다거나 그런경우다

예시로 실행 후 작업만 하고 정상 종료하는 배치 프로그램을 잡이 아닌 파드로 띄웠다거나

ENTRYPOINT/CMD 설정 오류가 났다거나 등이다.

그냥 kubectl logs해서 보면 될듯 이런거 원인은 쉽게 잡을수도있다.

그리고 설정 오류가 있는데 Config Env Secret 등에서 필수 환경변수 누락

ConfigMap Secret 미마운트, 잘못된 프로파일을 줬다거나등이 있다.

이런경우가 보통의 휴먼에러에서 발생하는데

• IllegalArgumentException
• Failed to bind properties
• Cannot find config

ci에서 잘 검증할수있는 flow를 두거나, 뭐 그런 프로세스등을 잘 거쳐서 봐보자.

프로세스는 뜨지만 강제 종료되는 계열 #

OOMKilled로 메모리 부족 gc 불능 request/limits 부적절등이 있겠도 pod가 oomkilled되거나 로그가 중간에 귾기는 경우다.

이건 logs가 아닌 describe로 보면 좋고 나지 않게 하려면 메모리 설계를 잘해야된다.

SIGKLL/SIGTERM 등으로 노드 압박 eviction이나 deployment 업데이트 혹은 hpa/vpa 재조정에서 나게 되는 경우인데

종료 신호 수신 로그가 존재 가능한데 종료면 정상이니 재시작을 반복하면 된다.

네트워크 의존성 실패 계열 #

DB Redis Kakfa 등 외부 api연결과 실패하거나 dns해석 실패, 보안그룹 NACL 차단등이 있다.

전형적인 안티패턴으로 시작시 외부 시스템 필수 연결, 실패하면 exit 같은것들이 있는데 시스템 결합도가 높아지는 행위니까 하지말자.

rediness, liveness probe 오용도 있겠는데 기동전 probe를 실행시키고 timeoutSEconds가 너무 짧거나 initialDelaySeconds가 부족하면 발생할수있다. 컨테이너가 뜰때까지 시간이 걸릴수있고 애플리케이션이 실행할때까지 어느정도 시간이 있을수있기때문에 잘 조정해주자.

파일 시스템 / 권한 계열 #

read-only fs, 볼륨 마운트 실패, 디렉토리 권한 문제등이 있다.

• /tmp /logs /data등 디렉터리에 쓰기 권한이 없거나
• non root 컨테이너 권한 미스

바이너리 실행 불가도 있는데 Exec format erorr 아키텍처 mismatch (amd64, arm64)등이 있다. ㅋㅋ 말해뭐해 이런거 잘 세팅해두자

이미지 런타임 문제 뭐 cmd 없거나 이미지 풀이 안되거나 이건 말해뭐해도 마찬가지다.

결과적으로 당연한것들인데 CrashLoopBackOff는 증상이지 원인이 아니다. 원인은 대부분 시작시 exit, 강제종료 것들이니 잘 보고 세팅해두자.