Liveness/Readiness/Startup Probe — 세 헬스체크의 서로 다른 결과
Kubernetes 공식 문서(kubernetes.io) 및 운영 블로그 종합 — 아키텍처부터 스케줄링까지 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/overview/components, workloads/pods, services-networking, pod-qos, pod-lifecycle) + 운영 블로그(Komodor, Datadog 등) 교차 확인 Kubernetes 공식문서 Pod Lifecycle — Container probes
이 모듈을 다 읽으면
- livenessProbe 실패와 readinessProbe 실패가 각각 어떤 다른 결과(재시작 vs 서비스 제외)로 이어지는지 설명할 수 있다
- startupProbe가 존재하는 이유(초기화가 느린 앱을 오탐으로부터 보호)를 설명할 수 있다
k8s-learn-05에서 다룬 requests/limits가 '자원 관점의 통제'였다면, 이 모듈은 '애플리케이션 상태 관점의 통제'인 세 가지 프로브가 서로 다른 결과를 낳는 이유를 정리한다.
livenessProbe — 실패하면 컨테이너를 재시작한다
livenessProbe는 컨테이너가 재시작이 필요한 '복구 불가능한 고장' 상태인지를 판단한다. 실패하면 재시작 정책에 따라 컨테이너가 재시작된다 — 예를 들어 애플리케이션이 데드락에 빠져 응답은 하지만 실제로는 아무 진전도 없는 상태를 감지해 강제로 다시 살리는 용도다.
핵심 포인트
- livenessProbe 실패 → 컨테이너 재시작(재시작 정책에 따라) — '재시작 말고는 복구 방법이 없는 고장' 감지용
readinessProbe — 실패하면 트래픽만 끊고 컨테이너는 그대로 둔다
readinessProbe는 컨테이너가 지금 당장 트래픽을 받을 준비가 됐는지를 판단한다. 실패하면 컨테이너를 재시작하지 않고, 대신 그 Pod를 Service의 엔드포인트 목록에서 제외해 트래픽이 더는 그 Pod로 오지 않게 만든다 — 예를 들어 일시적으로 다운스트림 의존성(DB 연결 등)에 문제가 생겨 잠깐 요청을 처리 못 하지만 곧 회복될 상황에 적합하다.
핵심 포인트
- readinessProbe 실패 → 컨테이너는 그대로 두고 Service 엔드포인트에서만 제외(트래픽 차단) — 재시작 없음
- '곧 회복될 일시적 불능' 상황(예: 다운스트림 의존성 일시 장애)에 적합
startupProbe — 초기화가 느린 애플리케이션을 오탐으로부터 보호한다
startupProbe는 liveness·readiness 프로브의 실행 자체를 지연시키는 역할을 한다 — startupProbe가 성공하기 전까지는 다른 두 프로브가 아예 실행되지 않는다. 이는 임의로 오래 걸리는 초기화 과정이 필요한(특히 레거시) 애플리케이션에서, '아직 초기화 중이라 응답이 느릴 뿐인데 livenessProbe가 이를 고장으로 오판해 계속 재시작시키는' 문제를 막기 위해 존재한다.
핵심 포인트
- startupProbe 성공 전까지는 liveness/readiness 프로브 자체가 실행되지 않음(지연)
- 초기화가 임의로 오래 걸리는(레거시) 애플리케이션에서 livenessProbe의 오탐 재시작을 막는 용도