kubectl get pods를 쳤을 때 STATUS에 Init:0/1이나 Init:1/2가 떠 있고 한참 동안 그대로라면, Pod의 init container가 끝나지 않아 메인 컨테이너가 시작조차 못 하고 있다는 뜻입니다. init container는 메인 컨테이너보다 먼저, 순서대로, 끝까지 성공해야 다음 단계로 넘어갑니다. 하나라도 멈추거나 실패하면 전체 Pod가 그 자리에서 대기합니다.
init container를 언제 쓰나
메인 앱이 뜨기 전에 반드시 끝나야 하는 준비 작업을 분리할 때 씁니다.
YAML
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
initContainers:
- name: wait-db
image: busybox:1.36
command: ['sh', '-c', 'until nc -z db 5432; do sleep 2; done']
containers:
- name: web
image: myapp:1.0
위 예시는 DB 포트가 열릴 때까지 기다린 뒤에야 메인 컨테이너를 시작합니다. 설정 파일 생성, 마이그레이션, 의존 서비스 대기 같은 "선행 조건"에 적합합니다.
멈췄을 때 진단
Init: 상태가 길어지면 추측하지 말고 두 곳을 봅니다.
Kubernetes
# Pod 단계·이벤트·각 init 컨테이너 상태
kubectl describe pod <pod>
# 특정 init 컨테이너 로그 (-c 로 이름 지정)
kubectl logs <pod> -c wait-db
describe의 Init Containers 섹션에서 State와 이벤트를, logs -c <이름>에서 실제 동작을 확인합니다.
원인별 해결
| 증상 | 원인 | 해결 |
|---|---|---|
Init:0/1에서 멈춤 | init이 무한 대기(의존 서비스 미기동) | 대기 대상 Service·DNS 확인, nc -z 대상 점검 |
Init:Error / Init:CrashLoopBackOff | init 명령이 0이 아닌 코드로 종료 | logs -c <init>의 에러, command/args 오타 |
ImagePullBackOff (init) | init 이미지 태그·레지스트리 오류 | 이미지 태그·imagePullSecrets 확인 |
계속 Init:0/1 | init 컨테이너에 리소스 부족으로 스케줄 안 됨 | describe의 이벤트에서 FailedScheduling 확인 |
가장 흔한 건 첫 줄입니다. 대기 대상 서비스 이름이 틀렸거나(db vs db.default), 해당 Service가 아예 없으면 init은 영원히 sleep 루프를 돕니다. kubectl get svc로 대상이 실재하는지부터 봅니다.
30초 체크리스트
Kubernetes
kubectl get pods # Init:N/M 상태 확인
kubectl describe pod <pod> # Init Containers 섹션·이벤트
kubectl logs <pod> -c <init-name> # init 컨테이너 실제 로그
kubectl get svc,endpoints # 대기 대상이 실재하는지
-c 옵션을 빠뜨려서 "로그가 안 나온다"고 헤매는 경우가 많으니, init 단계에서는 반드시 컨테이너 이름을 지정합니다.
init container가 멈추는 상황을 직접 만들어 보고 logs -c로 원인을 좁히는 실습은 쿠버네티스 트랙에서 해볼 수 있습니다 — 회원가입 없이 무료로.