ACTIVE INCIDENT
00:00 elapsed
LABLAB-K8S-05-OOMKILLEDSEV-2
Pod OOMKilled — 메모리 한도 진단과 설정
ELAPSED
00:00
PHASE
0 / 5
SLA
50분
⎈ Kubernetes← 목록
INCIDENT RESPONSE
0 / 6 단계 완료
📚 PREREQUISITES
TRACK
KUBERNETES
SLA
50분
SEV
SEV-2
PHASES
4단계
ENV
local
INCOMING TICKET
“모니터링 알람: "api-server Pod가 1시간 동안 7번 재시작됨 — OOMKilled 감지"”
YOUR ROLE
주니어 인프라 엔지니어
IMPACT IF UNRESOLVED
주기적인 Pod 재시작으로 API 응답 지연 및 일부 요청 실패 발생
🚨INCIDENT BRIEF
오전 9시 17분, 알림이 울렸습니다.
[ALERT] api-server Deployment — Pod RESTARTS: 7 (1시간 내) / OOMKilled 감지
kubectl get pods를 실행하니 RESTARTS 카운터가 계속 올라갑니다. 어젯밤 배포 이후 처음 몇 시간은 괜찮았는데, 트래픽이 붙기 시작하면서 Pod가 주기적으로 죽고 있습니다.
OOMKilled는 Out Of Memory Killed의 약자입니다. 컨테이너가 설정된 메모리 한도(limits.memory)를 초과하면 Kubernetes가 해당 컨테이너를 강제 종료합니다. exit code는 137입니다.
kubectl describe로 OOMKilled를 확인하고, kubectl top으로 실제 메모리 사용량을 측정한 뒤, resources 필드를 올바르게 설정해 안정화합니다.
확대⏱ 50분📊 중급🔧 4단계#kubernetes#oomkilled#resources#limits
MISSION
1
OOMKilled 증상 확인 — exit code 137
kubectl get pods와 describe로 OOMKilled 증상과 exit code 137을 확인하고 재시작 패턴을 파악한다
2
메모리 사용량 확인 — kubectl top
kubectl top pod로 현재 메모리 사용량을 측정하고 설정된 limits와 비교해 한도 초과 여부를 확인한다
3
resources.limits 설정 — requests/limits 적정값 설정
Deployment의 resources.requests/limits를 실제 사용량 기반으로 올바르게 설정하고 재배포한다
4
수정 후 검증 — OOMKilled 재발 방지 확인
설정 변경 후 Pod가 안정적으로 Running을 유지하고 RESTARTS가 더 이상 증가하지 않는지 확인한다
📌 선수 지식
• [실습] k8s-pod-crashloop
• [실습] k8s-basics-pod-deploy
• [이론] kubernetes/pod-lifecycle
• [이론] kubernetes/resource-limits
• [이론] kubernetes/deployment-basics
ℹ️ 실습 환경
환경: local
필요 도구: kubectl, kubernetes cluster
검증 스크립트:
/labs/lab-k8s-06-oomkilled/scripts/verify.sh🔒
실습 실행은 Pro 플랜 전용입니다
인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.
Pro로 업그레이드 →>_ LAB WORKSPACE
NOTES