Day 1 — OOMKilled 직접 발생시켜보기

요약 

Day 1 — OOMKilled 직접 재현하기

→ 컨테이너 memory limit을 넘기면 Kubernetes가 어떻게 kill 하는지 눈으로 확인

---

 

📆 Day 1 — OOMKilled 직접 발생시켜보기

🎯 목표

• Kubernetes에서 OOMKilled가 정확히 언제 발생하는지 직접 본다
• “메모리 부족”이 아니라 limit 계약 위반이라는 걸 이해한다

 

🧱 실습 전제 조건

 

[사실] 아래 중 하나만 있으면 됨

• minikube / kind / k3s / 회사 k8s 클러스터
• kubectl 사용 가능

[사실] Kubernetes 공식 문서 (리소스 제한 개념)

• https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

 

---

 

1️⃣ OOM 실습용 Pod YAML 작성

 

의도

• memory limit을 일부러 작게
• 컨테이너에서 계속 메모리를 잡아먹게

 

 

oom-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: oom-demo
spec:
  restartPolicy: Always
  containers:
    - name: mem-hog
      image: busybox
      command: ["sh", "-c"]
      args:
        - |
          echo "Start memory hog";
          x=;
          while true; do
            x="$x$(head -c 1M </dev/zero)";
            sleep 0.1;
          done
      resources:
        requests:
          memory: "32Mi"
        limits:
          memory: "64Mi"

 

왜 이렇게 설정했냐 (중요)

• limit: 64Mi
  • 이걸 넘는 순간 커널이 kill
• head -c 1M </dev/zero
  • 1MB씩 계속 메모리 점유
• busybox
  • 가볍고 어디서나 됨

---

 

2️⃣ Pod 생성

kubectl apply -f oom-demo.yaml

 

---

 

3️⃣ 상태 바로 확인

kubectl get pod oom-demo -w

잠깐 기다리면 보일 것 👇

STATUS: CrashLoopBackOff
RESTARTS: 1, 2, 3 ...

 

---

 

4️⃣ 진짜 핵심: describe 로 원인 확인

kubectl describe pod oom-demo

아래 부분 반드시 찾기

Last State:     Terminated
  Reason:      OOMKilled
  Exit Code:   137

 

---

 

🔥 여기서 반드시 이해해야 할 것

 

1️⃣ OOMKilled는 “애플리케이션 에러”가 아님

• Linux 커널이 강제 종료
• 애플리케이션은 대응할 기회 없음

 

[사실] Exit Code 137

• SIGKILL (OOM)

 

---

 

2️⃣ request vs limit 차이 (운영에서 매우 중요)

항목의미

requests	스케줄링 기준
limits	넘으면 죽음

[사실]

 

• request 초과 → 아무 일도 안 일어남
• limit 초과 → 즉시 OOMKilled

 

---

 

3️⃣ 왜 Pod는 다시 살아나나?

restartPolicy: Always

[사실]

• kubelet이 컨테이너 재시작
• 장애가 자동으로 숨겨질 수 있음

👉 운영에서 제일 위험한 케이스

 

---

 

5️⃣ 로그 확인 (의미 없음도 같이 체감)

kubectl logs oom-demo

 

• 마지막 로그 거의 없음
• kill 당했기 때문

 

👉 OOM은 로그로 못 잡는다

---

 

🧠 Day 1 핵심 정리 (DevOps 관점)

• OOMKilled는:
  • 코드 문제가 아니라
  • 리소스 설계 문제
• 반드시 봐야 할 순서:
  1. kubectl get pod
  2. kubectl describe pod
  3. 그 다음에 logs

 

---

 

❗ 실무에서 바로 쓰이는 판단 기준

• OOM 자주 나면?
  • ❌ 무작정 memory 늘리기
  • ✅ 실제 사용량 측정 후 limit 재설계
• 사이드카 / 앱 / 에이전트
  • 각자 limit 따로

 

---

 

다음 Day 2 예고

 

• 같은 Pod 안에서
  • main 컨테이너는 멀쩡
  • sidecar만 OOM 나면?
• Pod는 왜 1/2 Running 이 되는가