ImagePullBackOff 진단하기
이 문서는 쿠버네티스(Kubernetes)에서 ImagePullBackOff가 발생했을 때 와탭 쿠버네티스 모니터링으로 원인을 진단하는 방법을 안내합니다. ImagePullBackOff가 무엇이고 네 가지 원인을 kubectl describe pod의 이벤트로 구분하는 방법은 ImagePullBackOff 원인 4가지, describe 한 줄로 구분하기에서 먼저 확인할 수 있습니다.
진단이 어려운 이유
ImagePullBackOff의 결정적 단서는 kubectl describe pod의 Events에 남지만, 이 이벤트는 오래 보존되지 않습니다. 기본적으로 한 시간쯤 지나면 오래된 이벤트가 정리되고, 재시도가 잦으면 처음 실패했을 때의 메시지가 새 메시지에 묻힙니다. 노드가 여러 대이고 파드가 이리저리 스케줄되면, 어느 노드에서 무엇이 실패했는지 그 순간을 사람이 일일이 붙잡기도 어렵습니다.
그래서 이미지 풀 실패처럼 단서가 빨리 휘발하는 문제일수록, 이벤트와 상태 변화를 시간 순으로 모아 두는 모니터링이 진단에 도움이 됩니다.
이벤트 타임라인으로 첫 실패 되짚기
와탭 쿠버네티스 모니터링은 파드와 노드의 이벤트를 시간 순으로 수집해 보존합니다. 그래서 kubectl에서 이미 밀려 사라진 뒤에도 다음을 되짚어 볼 수 있습니다.
- 이미지 풀에 처음 실패한 시점
- 실패가 발생한 노드
- 그때 레지스트리가 돌려준 응답 메시지(
manifest unknown,pull access denied,toomanyrequests등)
처음 실패 메시지에 원인이 그대로 담겨 있으므로, 그 한 줄만 되짚으면 이미지 이름·태그 오류인지, 인증 실패인지, 네트워크 도달 불가인지, rate limit인지를 구분할 수 있습니다.
예시: 이미지 풀 실패 이벤트가 시간 순으로 쌓인 화면. 처음 실패 시점과 노드, 레지스트리 응답 메시지를 타임라인으로 되짚을 수 있습니다.
자연어로 원인 묻기
이벤트를 직접 뒤지는 대신, 쌓인 이벤트를 근거로 원인을 정리해 달라고 자연어로 물을 수도 있습니다. 예를 들어 "왜 이 파드가 ImagePullBackOff인가요?"처럼 물으면, 해당 파드의 이미지 풀 실패 이벤트를 모아 원인 후보를 정리해 줍니다. 단서를 한 줄씩 직접 찾아 읽는 수고를 덜고, 처음 보는 운영자도 어느 원인부터 확인해야 하는지 빠르게 좁힐 수 있습니다.