Day 2 — Sidecar 컨테이너만 OOMKilled 시키기

요약

Day 2 — Sidecar 컨테이너만 OOMKilled 시키기

→ 같은 Pod 안에서 컨테이너 하나만 죽어도 Pod는 살아있을 수 있다.

 

---

 

📆 Day 2 — Sidecar 컨테이너 OOMKilled 재현

 

🎯 실습 목표

• 같은 Pod 안에서 컨테이너 하나만 죽는 상황을 직접 만든다
• Sidecar 패턴에서 리소스 설계가 왜 중요한지 체감한다
• READY 1/2, CrashLoopBackOff 상태를 눈으로 확인한다

 

---

 

🧱 실습 전제 조건

• Day 1 실습을 이미 해봄 (OOM 개념 이해됨)
• Kubernetes 클러스터 접근 가능
• kubectl 사용 가능

 

[사실] 참고 문서 (Pod / multi-container 개념)

• https://kubernetes.io/docs/concepts/workloads/pods/

 

---

 

1️⃣ 실습 시나리오 설명 (중요)

의도

• 하나의 Pod에:
  • 정상 동작하는 main container
  • 메모리를 계속 잡아먹는 sidecar container
• sidecar만 memory limit을 넘겨 OOMKilled
• Pod 전체는 죽지 않음

👉 이 구조는 로그 에이전트 / 프록시 / 보안 에이전트랑 똑같다.

---

 

2️⃣ Sidecar OOM 실습용 Pod YAML

sidecar-oom-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-oom-demo
spec:
  restartPolicy: Always
  containers:
    - name: main-app
      image: nginx
      ports:
        - containerPort: 80
      resources:
        requests:
          memory: "64Mi"
        limits:
          memory: "128Mi"

    - name: sidecar-mem-hog
      image: busybox
      command: ["sh", "-c"]
      args:
        - |
          echo "Start sidecar memory hog";
          x=;
          while true; do
            x="$x$(head -c 1M </dev/zero)";
            sleep 0.1;
          done
      resources:
        requests:
          memory: "16Mi"
        limits:
          memory: "32Mi"

 

---

 

3️⃣ Pod 생성

kubectl apply -f sidecar-oom-demo.yaml

 

---

 

4️⃣ 상태 실시간 관찰 (핵심)

kubectl get pod sidecar-oom-demo -w

잠시 후 보일 것 👇

READY   STATUS
1/2     CrashLoopBackOff

 

---

 

5️⃣ 이 상태의 정확한 의미

 

❗ 많은 사람이 여기서 헷갈림

 

• Pod 개수: 1개
• 컨테이너 개수: 2개
• READY 1/2 의미:
  • 컨테이너 2개 중 1개만 정상

• main-app: Running
• sidecar-mem-hog: OOMKilled → 재시작 반복

 

---

 

6️⃣ 원인 확인 (describe)

kubectl describe pod sidecar-oom-demo

아래 부분 확인 👇

Containers:
  sidecar-mem-hog:
    Last State: Terminated
      Reason: OOMKilled
      Exit Code: 137

[사실]

 

• sidecar만 OOMKilled
• Pod 전체는 종료되지 않음

 

---

 

7️⃣ 로그 확인 (의도적으로 의미 없음 확인)

kubectl logs sidecar-oom-demo -c sidecar-mem-hog

• 유의미한 로그 거의 없음
• 이유: SIGKILL

 

👉 Day 1과 동일

👉 OOM은 로그로 원인 파악 불가

 

---

 

🔥 Day 2에서 반드시 이해해야 할 핵심

1️⃣ Pod ≠ 컨테이너

• Pod는 컨테이너 묶음
• 컨테이너 하나 죽어도 Pod는 살아있을 수 있음

 

---

 

2️⃣ Sidecar 패턴의 함정

• Sidecar는 보통:
  • 로그 수집
  • 프록시
  • 보안 / 인증
• 기능상 “보조”지만
• 실제로는 서비스 필수 구성요소인 경우가 많음

 

👉 그래서

sidecar OOM = 사실상 장애

---

 

3️⃣ READY 1/2 상태의 위험성

• Pod 상태만 보면:
  • Running
• 실제 상태:
  • 핵심 기능 일부 사망

👉 이 상태로 운영 장애가 가장 많이 난다

 

---

 

🧠 DevOps 관점 정리

 

• Sidecar 설계 시 원칙:
  1. 리소스 분리
  2. main-app보다 limit 낮게 잡지 말 것
  3. OOM 나도 서비스 영향 없는지 판단
• 실무 장애의 상당수는
• “애플리케이션은 멀쩡한데 sidecar가 죽음”

---

 

❗ 실무 체크리스트 (바로 써먹는 것)

• kubectl get pod 에서:
  • READY 숫자 항상 확인
• 1/2, 2/3 보이면:
  • 즉시 describe
• sidecar 있는 Pod:
  • “얘 죽어도 서비스 되나?” 항상 질문

 

---

 

다음 Day 2.5 예고

 

• sidecar OOM이 아니라
• readinessProbe 실패
• Pod는 Running
• 하지만 Service 트래픽은 0

 

👉 “파드는 살아있는데 서비스 안 됨”의 완성편