이 글은 제가 기존에 공부하고 정리했던 pod 의 생명주기 관련 문서를
claude 를 통해서 재정리한 글입니다. 그래서 약간 AI 스러운 말투가 있음을
알아주시기 바랍니다.
Kubernetes Pod 생명주기 완벽 이해하기
Kubernetes를 공부하다 보면 Pod의 상태가
Pending, Running, CrashLoopBackOff 등 다양하게 표시되는 것을 볼 수 있습니다.
이 상태들이 정확히 무엇을 의미하는지, 어떤 순서로 전환되는지 정리해보겠습니다.
Pod Phase vs Container State
먼저 혼동하기 쉬운 개념을 구분해봅시다.
Pod Phase (공식 5가지)
PendingRunningSucceededFailedUnknown
Container State / Reason (kubectl에서 보이는 추가 상태)
ContainerCreatingImagePullBackOffCrashLoopBackOffErrImagePull- 등등...
kubectl get pods 명령어의 STATUS 컬럼에는 Pod Phase뿐만 아니라
Container State도 함께 표시됩니다. 그래서 실제로는 5개보다 훨씬 많은
상태를 보게 되는 거죠.
Pod 생명주기 흐름도
kubectl run some-app --image=nginx ...
│
▼
┌─────────┐
│ Pending │ ← 스케줄링 대기 (Node 찾는 중)
└────┬────┘
│
▼
┌─────────────────────┐
│ Pending + │ ← Node 배정 완료
│ ContainerCreating │ 컨테이너 생성 중
└──────┬──────────────┘
│
├─→ ImagePullBackOff (이미지 다운로드 실패)
│
▼
┌──────────┐
│ Running │ ← 컨테이너 실행 중
└─────┬────┘
│
├─→ Succeeded (exit 0, 정상 종료)
│ │
│ └─→ (restartPolicy: Always면 재시작 → CrashLoopBackOff 가능)
│
└─→ Failed (exit != 0, 비정상 종료)
│
└─→ CrashLoopBackOff (주로 여기서 발생!)각 상태 상세 설명
1. Pending
Pod가 생성되었지만 아직 실행되지 않은 상태입니다.
주요 원인:
- 적절한 Node를 찾는 중 (스케줄링 대기)
- 리소스(CPU, Memory) 부족
- PersistentVolumeClaim 대기 중
확인 방법:
kubectl describe pod <pod-name>
# Events 섹션에서 원인 확인 가능2. ContainerCreating
스케줄링은 완료되었고, 컨테이너를 생성하는 중입니다.
이때 실제 Pod Phase는 여전히 Pending일 수 있습니다.
이 단계에서 하는 일:
- 컨테이너 이미지 다운로드 (Image Pull)
- Volume 마운트
- Secret, ConfigMap 로드
3. ImagePullBackOff
컨테이너 이미지를 다운로드하는데 실패한 상태입니다.
주요 원인:
- 이미지 이름 오타
- 존재하지 않는 이미지
- Private Registry 인증 실패
- 네트워크 문제
해결 방법:
# 이미지 이름 확인
kubectl describe pod <pod-name>
# Events에서 에러 메시지 확인
# "Failed to pull image" 메시지 찾기4. Running
컨테이너가 성공적으로 생성되어 실행 중인 상태입니다.
Pod가 Running 상태여도 앱이 정상이 아닐 수 있습니다!
- 컨테이너 프로세스는 실행 중이지만 앱이 에러 로그를 뱉고 있을 수 있음
- Readiness Probe로 실제 준비 상태를 확인해야 함
5. Succeeded
컨테이너가 실행되고 exit code 0으로 정상 종료된 상태입니다.
언제 보나요?
- 주로 Job/CronJob에서 의미있게 사용됨
- 배치 작업, 데이터 처리 등 1회성 작업이 성공적으로 완료
일반 Pod (Deployment 등)에서는?
- 계속 실행되어야 하는 웹 서버가 Succeeded 상태면 오히려 문제!
- nginx Pod가 종료되면 안 되니까요
# Job 예시
apiVersion: batch/v1
kind: Job
metadata:
name: data-backup
spec:
template:
spec:
restartPolicy: Never
containers:
- name: backup
image: backup-tool
command: ["./backup.sh"]
# backup.sh가 성공하면 → Succeeded6. Failed
컨테이너가 exit code != 0으로 비정상 종료된 상태입니다.
모든 종류의 Pod에서 발생 가능합니다!
Deployment의 Pod:
Running → Failed (앱 crash!)
↓
Running (restartPolicy: Always라서 즉시 재시작)
↓
Failed (또 crash)
↓
CrashLoopBackOff (반복...)Job의 Pod:
Running → Failed
↓
- restartPolicy: Never → Failed 상태 유지
- restartPolicy: OnFailure → 재시도일반 Pod (restartPolicy: Never):
Running → Failed
↓
(그대로 Failed 상태 유지)재시작 여부는 restartPolicy에 따라 결정됩니다.
7. CrashLoopBackOff
컨테이너가 시작되자마자 계속 종료되는 상태입니다.
발생 조건:
- 컨테이너가 시작 후 즉시 종료됨
- Kubernetes가 재시작 시도
- 반복적으로 실패하면 재시작 간격이 늘어남 (10초 → 20초 → 40초 → ... 최대 5분)
언제 발생하나요?
주로 Failed (exit != 0) 상황에서 발생 (99%)
- 앱이 에러로 종료
restartPolicy에 따라 재시작- 반복 실패 → CrashLoopBackOff
드물게 Succeeded (exit 0)에서도 발생 가능
apiVersion: v1
kind: Pod
metadata:
name: wrong-design
spec:
restartPolicy: Always # 잘못된 설정!
containers:
- name: batch
image: busybox
command: ["sh", "-c", "echo Done && exit 0"]위 예시는 1회성 작업인데 restartPolicy: Always로 설정한 경우입니다.
- 실행 → 성공 종료 → 재시작 → 성공 종료 → 반복...
- 결국 CrashLoopBackOff
하지만 이건 설계 실수입니다! 1회성 작업은 Job으로 만들거나 restartPolicy: Never를 써야 합니다.
주요 원인 (실무에서):
- 앱 설정 오류 (환경변수, 설정파일 누락)
- 의존성 문제 (DB 연결 실패 등)
- 권한 문제
- 명령어 오류
디버깅 방법:
# 로그 확인
kubectl logs <pod-name>
# 이전 컨테이너 로그 확인 (재시작된 경우)
kubectl logs <pod-name> --previous
# 상세 정보
kubectl describe pod <pod-name>Restart Policy (재시작 정책)
Pod의 spec.restartPolicy로 컨테이너가 종료됐을 때 어떻게 할지 결정합니다.
3가지 옵션:
-
Always (기본값)
- 종료되면 무조건 재시작
- Deployment, DaemonSet 등에서 사용
-
OnFailure
- exit code != 0 일 때만 재시작
- Job에서 주로 사용
-
Never
- 재시작 안 함
- 1회성 작업에 사용
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
restartPolicy: Always # 기본값
containers:
- name: app
image: nginx주의: 재시작 횟수는 지정할 수 없습니다. Kubernetes가 백오프 알고리즘으로 자동 조절합니다.
실전 팁
1. Pod 상태 빠르게 확인하기
# 모든 Pod 상태 확인
kubectl get pods
# 특정 Pod 상세 정보
kubectl describe pod <pod-name>
# 실시간 상태 모니터링
kubectl get pods -w2. 문제 해결 순서
kubectl get pods로 STATUS 확인kubectl describe pod로 Events 확인kubectl logs로 앱 로그 확인- 필요시
kubectl logs --previous로 이전 로그 확인
3. 자주 하는 실수
- 이미지 이름 오타:
nginx:latset(latest 오타) - 플랫폼 미지원: ARM 이미지를 x86 노드에 배포
- Private Registry 인증: imagePullSecrets 누락
- 리소스 부족: CPU/Memory requests가 너무 높음
마무리
Pod의 생명주기를 이해하면 Kubernetes 클러스터에서 발생하는 대부분의
문제를 빠르게 파악하고 해결할 수 있습니다.
특히 Pending, ImagePullBackOff, CrashLoopBackOff 같은 상태들은 각각
다른 원인을 가지고 있으므로, STATUS를 보는 순간 "아, 이건 이미지 문제구나",
"리소스가 부족하구나" 하고 바로 파악할 수 있게 됩니다.
참고 문서:
