배포 후 K8s 대시보드가 빨갛습니다. "Pod가 CrashLoopBackOff예요. 다른 건 ImagePullBackOff, 하나는 OOMKilled로 죽었고, Readiness가 안 떠서 트래픽이 안 가요." PM·인프라인 당신은 이 상태 이름들이 각각 무엇을 뜻하고 어디부터 봐야 할지 알아야 합니다. 이 사전은 컨테이너·K8s 용어와 '상태(state)' 신호를 빠르게 해독합니다. 깊은 실습은 Docker·Kubernetes 트랙으로 연결합니다.
- 1이미지·컨테이너·레지스트리·볼륨 용어로 컨테이너 기본을 읽을 수 있다
- 2Pod·Deployment·Service·Ingress 등 K8s 오브젝트의 역할을 구분할 수 있다
- 3Probe·HPA·리소스 request/limit으로 운영 동작을 이해할 수 있다
- 4CrashLoopBackOff·ImagePullBackOff·OOMKilled 등 상태로 장애 방향을 잡을 수 있다
컨테이너 기본
이미지·컨테이너·레지스트리·볼륨
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Docker / Dockerfile | 컨테이너 플랫폼 / 이미지 빌드 정의 | → [[dockerfile]] | ★★ |
| Docker Image / Container | 불변 템플릿 / 실행 인스턴스 | 1 이미지 → N 컨테이너 | ★★★ |
| Image Tag / Registry / DockerHub / ECR | 버전 태그 / 저장소 | 불변 태그 → [[semantic-versioning]] | ★★ |
| Volume / Bind Mount | 데이터 영속 / 호스트 연결 | 상태 외부화 → [[volumes]] | ★★ |
| Network Bridge / Docker Compose | 컨테이너 네트워크 / 다중 컨테이너 정의 | → [[docker-compose]] | ★★ |
핵심: 이미지는 불변, 태그는 고정(latest 금지)이어야 [[release-strategy]]의 롤백이 가능합니다. 상태(DB·파일)는 볼륨으로 컨테이너 밖에 둡니다([[twelve-factor-app]]).
쿠버네티스 오브젝트
Pod부터 Ingress까지
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Cluster / Node / Pod | 클러스터 / 노드(서버) / 최소 배포 단위 | Pod=컨테이너 묶음 → [[cluster-architecture]] | ★★ |
| Deployment / ReplicaSet | 배포·버전 관리 / 복제본 유지 | 롤링·롤백 → [[deployment-basics]] | ★★ |
| StatefulSet / DaemonSet | 상태유지 워크로드 / 노드마다 1개 | DB·에이전트 | ★ |
| Job / CronJob | 일회성 / 예약 작업 | 배치 → [[glossary-batch-async]] | ★ |
| Service / Ingress / Ingress Controller | 내부 LB / 외부 진입 / 그 구현 | 트래픽 경로 → [[service-types]]·[[ingress-controller]] | ★★ |
| ConfigMap / Secret / Namespace | 설정 / 비밀 / 격리 단위 | → [[configmap-secret]] | ★★ |
| PVC / PV / StorageClass | 볼륨 요청 / 볼륨 / 스토리지 종류 | 영속 스토리지 → [[persistent-volumes]] | ★ |
운영 동작 — Probe·오토스케일·리소스
K8s가 앱을 살리고 늘리는 메커니즘
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Liveness / Readiness / Startup Probe | 생존 / 준비 / 기동 점검 | Liveness 실패=재시작, Readiness 실패=트래픽 제외 | ★★★ |
| Resource Request / Limit | 예약량 / 상한 | limit 초과: CPU=throttle, 메모리=OOMKill → [[resource-limits]] | ★★★ |
| HPA / VPA | 수평/수직 오토스케일 | 부하 따라 Pod 수 조절 → [[hpa-autoscaling]] | ★★ |
| Rolling Update / Rollback | 점진 교체 / 되돌리기 | → [[release-strategy]] | ★★ |
| Blue-Green / Canary Deployment | 무중단/점진 배포 | → [[release-strategy]] | ★★ |
| Helm / Helm Chart / Values.yaml / Manifest | 패키지 매니저 / 차트 / 값 / 정의 | → [[helm-basics]] | ★★ |
핵심: Readiness 실패 = 트래픽 제외(재시작 안 함), Liveness 실패 = 재시작. 메모리 limit 초과는 OOMKilled(137), CPU limit 초과는 throttle(안 죽음)입니다([[resource-limits]]).
Pod 상태(state) — 장애 신호 사전
빨간 상태가 알려주는 원인
| 상태 | 의미 | 1차 대응 | 중요도 |
|---|---|---|---|
| CrashLoopBackOff | 시작→크래시→재시작 반복 | logs --previous로 기동 오류 확인 | ★★★ |
| ImagePullBackOff | 이미지 못 받음 | 태그 오타·레지스트리 인증(Secret) 확인 | ★★★ |
| OOMKilled | 메모리 limit 초과 종료(137) | limit 상향 vs 누수 구분 → [[resource-limits]] | ★★★ |
| Pending | 스케줄될 노드 없음 | 리소스 부족·노드셀렉터·PVC 미바인딩 | ★★ |
| Evicted | 노드 자원 압박으로 퇴거 | 노드 메모리/디스크 압박 | ★★ |
핵심: 상태 이름이 곧 진단의 출발점입니다. kubectl describe pod의 Events와 kubectl logs --previous가 1차 도구입니다([[k8s-troubleshooting]]).
Pod 상태 진단 — 직접 확인
K8s 장애는 상태 → 이벤트 → 로그 순으로 원인을 좁힙니다.
kubectl get pods # STATUS 열에서 상태 확인
kubectl describe pod <pod> # Events 섹션에 구체 사유
kubectl logs <pod> --previous # 죽기 직전(이전 컨테이너) 로그
NAME READY STATUS RESTARTS
app-xxx 0/1 CrashLoopBackOff 7 ← 7번 재시작. logs --previous 필수
api-yyy 0/1 ImagePullBackOff 0 ← describe Events에서 pull 실패 사유
db-zzz 0/1 OOMKilled 3 ← 메모리 limit 초과([[resource-limits]])
describe Events: Failed to pull image "myapp:v1.3": not found
→ 태그 오타 또는 레지스트리에 이미지 없음
kubectl get pods; kubectl describe pod <pod>; kubectl logs <pod> --previous- STATUS가 CrashLoopBackOff면 → kubectl logs <pod> --previous로 죽기 직전 로그 확인(설정 누락·의존성·기동 오류가 대부분)([[k8s-troubleshooting]])
- ImagePullBackOff면 → kubectl describe의 Events에서 "not found"(태그 오타) vs "unauthorized"(레지스트리 Secret 누락) 구분
- OOMKilled(RESTARTS 증가)면 → 메모리 사용 추세 확인. 일시 폭증이면 limit 상향, 우상향이면 누수([[resource-limits]]·[[jvm-operations]])
- READY 0/1인데 STATUS Running이면 → Readiness Probe 실패(앱은 떴으나 준비 안 됨). describe의 Readiness probe 실패 사유 확인
상황: 새 버전 배포 후 모든 Pod가 CrashLoopBackOff로 뜨고 서비스가 전면 중단됩니다.
원인: 컨테이너가 기동 중 필수 설정(DB 접속 주소)을 못 읽어 즉시 크래시합니다. ConfigMap의 오타나 Secret 누락이 흔한 원인입니다([[configmap-secret]]). 이미지/코드 문제가 아니라 설정 주입 문제입니다.
진단:
kubectl logs <pod> --previous | tail -30
# "Could not resolve host: db-prd" 또는 "Connection refused" → DB 주소/설정 문제
kubectl get configmap app-config -o yaml # 주소 오타 확인
해결: ConfigMap/Secret의 값을 정정하고 재배포(또는 롤아웃 재시작). 근본 대응: (1) 설정 변경도 [[code-review-pr]]·CI 검증을 거치게, (2) 즉시 [[release-strategy]]로 직전 정상 버전으로 롤백해 서비스 복구 후 원인 수정. CrashLoopBackOff는 "코드보다 설정/의존성 기동 실패"를 먼저 의심하는 것이 빠른 길입니다. 깊은 K8s 트러블슈팅은 [[k8s-troubleshooting]].
인프라/플랫폼 엔지니어에게 이 상태 사전은 K8s 운영의 일상 언어입니다 — get/describe/logs로 상태를 읽고, Probe·리소스 limit·HPA를 설계하며([[resource-limits]]·[[hpa-autoscaling]]), 롤링/카나리 배포를 운영합니다([[release-strategy]]). 깊은 실습은 Kubernetes 트랙에 있습니다. PM은 이 용어를 알면 "배포가 안 떠요"를 "CrashLoopBackOff(기동 실패) / ImagePullBackOff(이미지) / OOMKilled(메모리)"로 즉시 분류해, 영향 범위와 복구 시간을 가늠하고 롤백 결정을 빠르게 내릴 수 있습니다.
다음 용어사전에서는 이 컨테이너들을 빌드·배포하는 CI/CD·Git 용어를 정리합니다.