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