프로젝트: One App — Three Probes — 실제 실패

I’m happy to translate the article for you, but I’ll need the text of the article itself. Could you please paste the content you’d like translated (excluding the source line you’ve already provided)? Once I have the full text, I’ll keep the source link at the top and translate the rest into Korean while preserving the original formatting and markdown.

시각적 정신 모델 (먼저 이것을 기억하세요)

트래픽 규칙 (중요)

• ❌ Startup probe 실패 → 컨테이너는 liveness/readiness 프로브에 의해 검사되지 않음.
• ❌ Readiness probe 실패 → pod가 트래픽 없음을 받음.
• ❌ Liveness probe 실패 → pod가 재시작됨.

무엇을 시연할 것인가

하나의 앱을 실행합니다:

• 느리게 시작 (startup probe 필요)
• 일시적으로 사용 불가능해질 수 있음 (readiness probe 필요)
• 멈출 수 있음 (liveness probe 필요)

이는 실제 프로덕션 동작을 반영합니다.

Step 0 — 사전 요구 사항

minikube start
kubectl get nodes

Step 1 — 데모 애플리케이션 (고의적으로 불완전함)

우리는 다음과 같은 작은 HTTP 앱을 사용할 것입니다:

• 20초 걸려 시작됩니다
• /ready와 /health 엔드포인트를 노출합니다

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe-demo
  template:
    metadata:
      labels:
        app: probe-demo
    spec:
      containers:
      - name: app
        image: ghcr.io/stefanprodan/podinfo:6.5.3
        ports:
        - containerPort: 9898

매니페스트를 적용합니다:

kubectl apply -f deployment.yaml
kubectl get pods

이 시점에서:

• 앱이 천천히 시작됩니다.
• Kubernetes는 트래픽이 너무 일찍 도달할 수 있다는 것을 알지 못합니다.

Step 2 — 앱 노출하기

service.yaml

apiVersion: v1
kind: Service
metadata:
  name: probe-demo-svc
spec:
  selector:
    app: probe-demo
  ports:
  - port: 80
    targetPort: 9898
  type: NodePort

서비스를 생성하고 브라우저에서 엽니다:

kubectl apply -f service.yaml
minikube service probe-demo-svc

이제 진정한 학습이 시작됩니다.

시작 프로브

정의

“컨테이너가 완전히 시작될 때까지 판단하지 마세요.”

DevOps가 필요로 하는 이유

시작 프로브가 없으면 liveness 프로브가 느린 애플리케이션을 끝없이 재시작할 수 있습니다 (예: JVM, Python, DB 연결 애플리케이션).

시작 프로브 추가

startupProbe:
  httpGet:
    path: /health
    port: 9898
  failureThreshold: 30   # try for 30 seconds
  periodSeconds: 1

의미:
쿠버네티스는 컨테이너를 시작된 것으로 표시하기 전에 최대 30 seconds까지 기다립니다. 이 기간 동안 liveness와 readiness 프로브는 비활성화됩니다.

실패 시연 (프로브 제거)

kubectl delete pod -l app=probe-demo
kubectl describe pod 

보게 될 내용:

• 파드가 시작을 마치기 전에 재시작됩니다 → 느린 애플리케이션에서 흔히 발생하는 CrashLoopBackOff.

준비성 프로브

무엇인가

“이 파드가 지금 바로 트래픽을 받을 수 있나요?”

DevOps가 신경 쓰는 이유

• 배포 중 트래픽을 방지합니다.
• 손상된 파드가 사용자에게 서비스를 제공하는 것을 차단합니다.
• 무중단 롤링 업데이트에 필요합니다.

준비성 프로브 추가

readinessProbe:
  httpGet:
    path: /ready
    port: 9898
  initialDelaySeconds: 5
  periodSeconds: 3

확인

kubectl get pods
kubectl describe pod 
kubectl get endpoints probe-demo-svc

준비성 검사가 실패할 때:

• 파드는 Running 상태를 유지합니다.
• Service 엔드포인트에서 제거되어 트래픽이 전송되지 않습니다.

누락 시 문제 시연

준비성 프로브를 제거하고 새 버전을 배포하면 → 트래픽이 반쯤 시작된 파드에 도달할 수 있어 사용자에게 502 / 빈 응답이 발생할 수 있습니다.

Source: …

라이브니스 프로브

무엇인가

“이 컨테이너가 아직 정상인지, 아니면 멈춰 있는가?”

DevOps가 필요로 하는 이유

• 애플리케이션이 영원히 멈출 수 있음 (데드락, 메모리 누수).
• 쿠버네티스가 이를 자동으로 재시작해야 함.

Liveness Probe 추가

livenessProbe:
  httpGet:
    path: /health
    port: 9898
  initialDelaySeconds: 20
  periodSeconds: 5

자동 재시작 시연

실패 상황을 시뮬레이션:

kubectl exec -it <pod-name> -- kill 1

결과 확인:

kubectl get pods

포드가 자동으로 재시작되는 것을 볼 수 있습니다—수동 개입이 필요 없습니다.

startupProbe:
  httpGet:
    path: /health
    port: 9898
  failureThreshold: 30
  periodSeconds: 1

readinessProbe:
  httpGet:
    path: /ready
    port: 9898
  periodSeconds: 3

livenessProbe:
  httpGet:
    path: /health
    port: 9898
  initialDelaySeconds: 20
  periodSeconds: 5

DevOps 엔지니어 체크리스트 (인터뷰 수준)

You must know:

• Startup → 느리게 부팅되는 앱을 보호합니다
• Readiness → 트래픽을 제어합니다
• Liveness → 자동 복구를 수행합니다

Common pitfalls:

• Readiness ≠ Liveness (가장 흔한 실수)
• Readiness 누락 → 다운타임 발생
• Liveness 누락 → 무음 실패
• 잘못된 Startup 설정 → 무한 재시작

프로덕션 환경에서 설명하는 방법

“Startup은 초기화를 보호하고, Readiness는 사용자를 보호하며, Liveness는 플랫폼을 보호한다.”