Day 2.5 — Pod는 살아있는데 Service 트래픽은 0

요약 

Day 2.5 — 파드는 Running인데 서비스는 안 됨

→ readinessProbe 실패 시 Kubernetes가 트래픽을 어떻게 차단하는지 직접 확인

 

---

 

📆 Day 2.5 — Pod는 살아있는데 Service 트래픽은 0

 

🎯 실습 목표

• Pod 상태가 Running이어도 서비스가 안 되는 상황을 직접 만든다
• livenessProbe 와 readinessProbe 차이를 행동 기준으로 이해한다
• Service → Endpoint → Pod 연결 흐름을 정확히 본다

 

---

 

🧱 실습 전제 조건

• Day 2까지 실습 완료 (multi-container Pod 이해)
• Kubernetes 클러스터 접근 가능
• kubectl 사용 가능

 

[사실] 참고 문서 (probe 공식 개념)

• https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

 

---

 

1️⃣ 실습 시나리오 (이게 핵심)

의도

• Pod는 죽이지 않는다
• 컨테이너도 죽이지 않는다
• 대신 “트래픽만 차단”

👉 운영에서 제일 위험한 상태

 

---

 

2️⃣ readiness 실패용 Pod + Service YAML

readiness-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: readiness-demo
  labels:
    app: readiness-demo
spec:
  containers:
    - name: app
      image: nginx
      ports:
        - containerPort: 80
      readinessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5

⚠️ 중요

• nginx 기본 설정에는 /health 경로가 없음
• 즉, readinessProbe는 계속 실패

 

Service 추가

---
apiVersion: v1
kind: Service
metadata:
  name: readiness-demo-svc
spec:
  selector:
    app: readiness-demo
  ports:
    - port: 80
      targetPort: 80

 

---

 

3️⃣ 리소스 생성

kubectl apply -f readiness-demo.yaml

 

---

 

4️⃣ Pod 상태 확인 (헷갈리기 쉬운 지점)

kubectl get pod readiness-demo

결과 👇

NAME              READY   STATUS    RESTARTS
readiness-demo    0/1     Running   0

👉 중요

• STATUS: Running
• 컨테이너 죽지 않음
• 재시작 없음

 

---

 

5️⃣ 왜 READY가 0/1 인가?

kubectl describe pod readiness-demo

아래 부분 확인 👇

Readiness probe failed: HTTP probe failed with statuscode: 404

• readiness 실패
• Pod Ready 조건 = False

 

---

 

6️⃣ Service Endpoint 확인 (핵심 중의 핵심)

kubectl get endpoints readiness-demo-svc

결과 👇

ENDPOINTS: <none>

👉 이게 핵심 결과물

 

---

 

7️⃣ 지금 이 상태를 말로 정확히 설명하면

 

• Pod: 살아 있음
• 컨테이너: 살아 있음
• Service:
  • selector는 맞음
  • 하지만 Endpoint에 Pod 미등록
• 결과:
  • 트래픽 전혀 안 감

 

---

 

🔥 Day 2.5 핵심 개념 정리

1️⃣ readinessProbe란?

 

• “이 컨테이너가 지금 트래픽을 받아도 되는 상태인가”
• 실패 시:
  • 컨테이너 재시작 ❌
  • Pod 종료 ❌
  • Service Endpoint 제거 ⭕

 

---

 

2️⃣ livenessProbe와의 차이 (운영 기준)

구분livenessreadiness

실패 시	재시작	트래픽 차단
목적	살아있나	받을 준비 됐나
Service 영향	없음	있음

👉 이걸 헷갈리면 장애 원인 100% 놓친다

 

---

 

3️⃣ 왜 이 상태가 제일 위험한가

 

• 모니터링:
  • Pod Running → 정상처럼 보임
• 실제:
  • 사용자 트래픽 0
• 로그:
  • 에러 없음

👉 “조용한 장애”

 

---

 

🧠 DevOps 관점 정리

 

• 장애 분석 순서 잘못 잡으면:
  • Pod 정상 → 로그 정상 → ??? 상태
• 반드시 봐야 할 순서:
  1. Pod READY
  2. Pod Conditions
  3. Service Endpoint
  4. 그 다음 로그

 

---

 

❗ 실무에서 바로 써먹는 체크리스트

 

• Service 장애 시:
  • kubectl get endpoints 무조건 확인
• readinessProbe 작성 시:
  • “지금 안 되면 트래픽 차단해도 괜찮은가?” 질문
• DB / 외부 API 연동 서비스:
  • readiness 설계 안 하면 연쇄 장애

 

---

 

📌 Day 1 ~ Day 2.5 전체 흐름 요약

 

1. Day 1
   • limit 초과 → OOMKilled
2. Day 2
   • sidecar만 죽어도 Pod는 살아있음
3. Day 2.5
   • Pod 살아있어도 Service는 차단 가능

👉 이 세 개 이해하면

“쿠버네티스 장애의 절반”은 이미 이해한 거다