////

K8s 헬스 프로브 3종 선택 기준 (readiness/liveness/startup)

K8s 헬스 프로브 3종은 실패 시 동작이 다르다: liveness는 컨테이너 재시작, readiness는 트래픽 제거, startup은 초기화 완료 대기. liveness를 과도하게 사용하면 일시적 지연이 재시작 루프를 유발한다.

////

Summary#

K8s 헬스 프로브 3종은 실패 시 동작이 다르다: liveness는 컨테이너 재시작, readiness는 트래픽 제거, startup은 초기화 완료 대기. liveness를 과도하게 사용하면 일시적 지연이 재시작 루프를 유발한다.

Outcome#

프로브 실패 시 동작 언제 사용 주의
liveness 컨테이너 재시작 교착 상태·완전 멈춤 감지 임계값 보수적으로 설정
readiness 서비스 엔드포인트에서 제거 DB 연결 중·배치 실행 중 재시작 없음, 단순 트래픽 제어
startup 초기화 완료까지 liveness 비활성화 느린 앱·JVM 워밍업 등 failureThreshold × periodSeconds = 최대 초기화 시간

FastAPI 실전 예:

livenessProbe:
  httpGet:
    path: /health/live   # 단순 200 반환
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3    # 30초 연속 실패 시 재시작

readinessProbe:
  httpGet:
    path: /health/ready  # DB 연결·캐시 체크
    port: 8000
  periodSeconds: 5
  failureThreshold: 2

startupProbe:
  httpGet:
    path: /health/live
    port: 8000
  failureThreshold: 30   # 최대 300초 (30 × 10s) 대기
  periodSeconds: 10

Key Points#

  • liveness probe에 DB 쿼리 포함 금지 — DB 지연이 재시작 루프 유발
  • readiness failure는 재시작 없이 로드밸런서에서만 제외 — 안전
  • startup probe로 liveness의 initialDelaySeconds 추측 제거
  • 3개 엔드포인트: /health/live(간단), /health/ready(의존성), /health/startup(초기화)

Caveats#

PodDisruptionBudget(PDB) 없으면 readiness failure가 전체 롤링 재시작 시 무중단 보장 불가. liveness failureThreshold 너무 낮으면 트래픽 폭주 시 정상 파드도 재시작. minReadySeconds로 새 파드 안정화 시간 추가 권장.

Sagwan Revalidation 2026-04-15T14:55:59Z#

  • verdict: ok
  • note: LLM unavailable: [CLI 오류 1]

Sagwan Revalidation 2026-04-16T15:24:53Z#

  • verdict: ok
  • note: VERDICT: ok