파드 로그를 보려고 하면 컨테이너가 아직 시작되지 않았다는 응답이 온다.
Error from server (BadRequest): container "fluent-bit" in pod "app-5749597cb-4vrfh"
is waiting to start: PodInitializing
kubectl get pod 에서는 Init:0/4 같은 상태로 오래 머문다. 이것은 오류가 아니라 상태다. init 컨테이너가 아직 끝나지 않았다는 뜻이고, 진짜 원인은 그 init 컨테이너 안에 있다.
파드의 init 컨테이너는 선언한 순서대로 하나씩 돌고, 각각이 정상 종료(exit 0)해야 다음으로 넘어간다. 마지막 init 컨테이너가 끝나야 비로소 주 컨테이너가 시작된다. 따라서 init 이 실패해 재시작을 반복하거나 무한 대기에 빠지면 주 컨테이너는 영원히 PodInitializing 이다.
메시지에 나오는 컨테이너 이름(fluent-bit)은 기다리고 있는 쪽이지 문제를 일으킨 쪽이 아니다. 여기서 헤매기 쉽다.
kubectl describe pod <pod> -n <ns>
Init Containers 절에서 각 컨테이너의 State 를 본다. Running 인 것이 지금 걸려 있는 컨테이너이고, Terminated 이면서 Exit Code 가 0 이 아닌 것이 실패한 컨테이너다. 아래 Events 절에 이미지 내려받기나 볼륨 마운트 실패가 함께 찍힌다.
이름만 빠르게 뽑으려면 다음을 쓴다.
kubectl get pod <pod> -n <ns> -o jsonpath='{range .spec.initContainers[*]}{.name}{"\n"}{end}'
kubectl logs <pod> -n <ns> -c <init-container>
kubectl logs <pod> -n <ns> -c <init-container> --previous
재시작을 반복하고 있다면 --previous 쪽에 실제 실패 메시지가 있다.
| 원인 | 신호 | 조치 |
|---|---|---|
| 볼륨을 못 붙임 | Events 에 FailedMount, FailedAttachVolume |
PVC 와 CSI 상태 확인 |
| 이미지를 못 받음 | ImagePullBackOff, ErrImagePull |
레지스트리 시크릿과 태그 확인 |
| 의존 서비스 대기 | init 로그가 같은 줄을 반복 | 대상 서비스와 DNS 확인 |
| ConfigMap · Secret 없음 | Events 에 CreateContainerConfigError |
이름과 네임스페이스 확인 |
| 노드 자원 부족 | 파드가 Pending 에 가깝게 머무름 |
kubectl top node 로 여유 확인 |
| 설정 값이 잘못됨 | init 로그에 INVALID_ARGUMENT 계열 |
주입한 설정 값 확인 |
의존 서비스를 기다리는 init 컨테이너는 아주 흔한 패턴이다. 이 경우 대상 서비스가 준비되지 않은 것이 진짜 문제이므로, 파드가 아니라 그 서비스를 봐야 한다.
kubectl get endpoints <dependency-service> -n <ns>
kubectl run -it --rm netcheck --image=busybox --restart=Never -- nslookup <dependency-service>.<ns>.svc
kubectl get nodes -o wide
kubectl get pvc -n <ns>
kubectl top nodes
init 컨테이너 없이 주 컨테이너만 떠도 되는 상황이라면, 원본 워크로드를 건드리지 말고 디버그용 파드를 따로 만들어 확인한다. 운영 중인 Deployment 의 init 컨테이너를 지우면 다음 배포 때 되돌아오고, 그사이 잘못된 상태로 서비스가 돌 수 있다.
kubectl debug pod/<pod> -n <ns> -it --image=busybox --target=<container>
restartPolicy 가 따로 없다. 파드의 정책을 따르므로 Always 면 실패해도 계속 다시 돈다. 로그가 계속 새로 생기는 이유가 이것이다.