Kubernetes Probe Failure Modes and Rollout Design

Kubernetes의 readinessProbe, livenessProbe, startupProbe는 모두 컨테이너 상태를 확인하는 장치처럼 보이지만, 운영상 묻는 질문은 다르다. 설계 핵심은 트래픽 수신 가능 여부 , 프로세스 재시작 필요 여부 , 느린 기동 보호 여부 를 분리하는 것이다. - readinessProbe: Pod가 Service 트래픽을 받아도 되는지 판단한다. 실패하면 Pod는 실행 상태로 남지만 Service endpoint/로드밸런싱 대상

Summary#

Kubernetes의 readinessProbe, livenessProbe, startupProbe는 모두 컨테이너 상태를 확인하는 장치처럼 보이지만, 운영상 묻는 질문은 다르다. 설계 핵심은 트래픽 수신 가능 여부, 프로세스 재시작 필요 여부, 느린 기동 보호 여부를 분리하는 것이다.

readinessProbe: Pod가 Service 트래픽을 받아도 되는지 판단한다. 실패하면 Pod는 실행 상태로 남지만 Service endpoint/로드밸런싱 대상에서 제외된다.
livenessProbe: 컨테이너가 교착, 영구 오류, 복구 불능 상태인지 판단한다. 실패하면 kubelet이 컨테이너를 재시작한다.
startupProbe: 기동 시간이 긴 애플리케이션이 충분히 시작될 때까지 liveness/readiness 판정을 지연시켜 조기 재시작을 방지한다.

장애 패턴의 상당수는 probe 자체보다 probe가 묻는 질문이 부정확한 경우에 발생한다. readiness가 외부 의존성 장애를 지나치게 넓게 반영하면 롤아웃이 멈춘 것처럼 보일 수 있고, liveness가 DB·외부 API 같은 외부 의존성 장애를 재시작 조건으로 삼으면 재시작 폭풍이나 CrashLoopBackOff로 증폭될 수 있다.

Probe별 역할#

Probe	묻는 질문	실패 시 동작	주요 사용처	주의점
`readinessProbe`	지금 트래픽을 받아도 되는가?	Service endpoint/트래픽 대상에서 제외	초기화, 캐시 로딩, 백프레셔, 일시적 의존성 대기	재시작하지 않는다. 롤아웃 가용성과 결합해 설계해야 한다.
`livenessProbe`	재시작해야 회복될 상태인가?	kubelet이 컨테이너 재시작	deadlock, 이벤트 루프 정지, HTTP 서버 무응답 등	외부 의존성 실패를 직접 포함하면 재시작 폭풍을 만들 수 있다.
`startupProbe`	아직 초기 기동 중인가?	성공 전까지 liveness/readiness 판정 지연	JVM, 대형 캐시 로딩, cold start가 긴 서비스	`failureThreshold × periodSeconds`를 최대 기동 허용 시간으로 설계한다.

대표 장애 패턴#

1. 너무 공격적인 livenessProbe#

periodSeconds, timeoutSeconds, failureThreshold가 지나치게 짧으면 일시적인 GC pause, CPU throttling, slow I/O, 순간 부하를 장애로 오판할 수 있다.

결과: - 정상 회복 가능한 지연이 컨테이너 재시작으로 바뀐다. - 재시작 중 warm-up 비용이 더해져 장애가 길어진다. - 반복되면 CrashLoopBackOff 또는 가용성 저하로 이어질 수 있다.

2. 외부 의존성을 liveness에 포함#

DB, 외부 API, 메시지 브로커 등 외부 시스템 장애를 liveness 실패로 연결하면 애플리케이션 자체는 살아 있어도 Kubernetes가 계속 재시작한다.

권장: - liveness는 프로세스 내부의 치명적 상태, deadlock, 이벤트 루프 정지, HTTP 서버 무응답처럼 재시작이 의미 있는 상태에 집중한다. - 외부 의존성 준비 여부는 대개 readiness에서 더 신중하게 다룬다.

3. readiness가 항상 실패하여 롤아웃 정체#

새 버전 Pod의 readiness가 계속 실패하면 Deployment는 충분한 available Pod를 확보하지 못한다. maxUnavailable, maxSurge, minReadySeconds, readiness 조건이 결합되면 롤아웃이 지연되거나 실패한 것처럼 보일 수 있다.

점검: - readiness endpoint가 실제로 200/OK를 반환하는가? - readiness가 너무 많은 외부 의존성을 확인하고 있지는 않은가? - maxUnavailable=0 같은 보수적 설정과 readiness 실패가 결합되어 신규 Pod 전환이 막히지는 않는가?

4. startupProbe 부재#

기동 시간이 긴 애플리케이션에서 startupProbe 없이 livenessProbe만 설정하면, 애플리케이션이 정상 기동을 끝내기 전에 liveness가 실패하여 컨테이너가 반복 재시작될 수 있다.

권장: - 느린 앱은 initialDelaySeconds만 크게 늘리기보다 startupProbe로 의도를 분리한다. - failureThreshold × periodSeconds가 실제 최악 기동 시간보다 충분히 길어야 한다.

5. probe endpoint가 너무 무겁다#

health endpoint가 매번 DB 쿼리, 원격 API 호출, 복잡한 내부 검사를 수행하면 probe 자체가 부하를 만들거나 timeout을 유발할 수 있다.

권장: - liveness endpoint는 가볍고 로컬적인 검사를 우선한다. - readiness endpoint도 트래픽 수용 가능성을 판단하는 데 필요한 최소 신호만 포함한다.

6. Helm values 기본값 오설계#

Helm chart에서 probe 설정을 values로 노출하더라도 기본값이 서비스 특성과 맞지 않으면 설치 환경마다 반복 장애가 발생한다.

주의할 값: - initialDelaySeconds - periodSeconds - timeoutSeconds - failureThreshold - successThreshold(특히 readiness) - endpoint path와 port

권장: - 공통 chart라도 서비스별 기동 시간과 부하 특성을 반영할 수 있게 한다. - probe endpoint path를 values로 열어두되, 기본값은 애플리케이션의 실제 endpoint와 맞춘다. - startupProbe가 필요한 서비스와 필요 없는 서비스를 구분한다.

설계 기준#

readiness#

질문: 지금 트래픽을 받아도 되는가?

실패해도 컨테이너는 재시작하지 않는다.
Service endpoint에서 제외되어 신규 트래픽을 받지 않는다.
초기화, 캐시 준비, 백프레셔, 일시적 의존성 대기 상태를 표현하는 데 적합하다.
외부 의존성 포함 여부는 서비스 특성에 따라 신중히 결정한다.

liveness#

질문: 재시작하면 회복될 가능성이 높은가?

실패 시 kubelet이 컨테이너를 재시작한다.
외부 시스템 장애를 직접 포함하지 않는 편이 일반적으로 안전하다.
프로세스가 내부적으로 교착되었거나 HTTP 서버가 응답하지 않는 등 재시작이 유효한 상태를 확인한다.

startup#

질문: 초기 기동이 아직 진행 중인가?

startupProbe가 성공하기 전까지 liveness/readiness 판정이 지연된다.
느린 시작, JVM warm-up, 대형 캐시 로딩, cold start가 긴 서비스에 유용하다.
initialDelaySeconds 추측을 줄이고, 기동 보호 의도를 명확히 표현한다.

Maintenance note#

2026-05-14 점검에서 핵심 사실은 vault 및 validated public 검색 결과와 일치했다. 기존 본문 말미의 미완성 Helm chart 항목은 위의 “Helm values 기본값 오설계” 섹션으로 정리했다.

Sagwan Revalidation 2026-05-15T11:15:06Z#

verdict: ok
note: Probe 역할·실패 모드·설계 권고가 현재 Kubernetes practice와 일치함

Sagwan Revalidation 2026-05-16T11:30:06Z#

verdict: ok
note: probe 역할과 장애 설계 권장은 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-05-17T11:55:22Z#

verdict: ok
note: Kubernetes probe 동작과 권장 설계가 현재 practice와 일치함

Sagwan Revalidation 2026-05-18T12:19:39Z#

verdict: ok
note: Kubernetes probe 동작과 권장 설계가 현재 practice와 부합함

Sagwan Revalidation 2026-05-19T12:48:08Z#

verdict: ok
note: Kubernetes probe 역할·장애 패턴 설명은 현재 practice와 여전히 부합함

Sagwan Revalidation 2026-05-20T13:12:12Z#

verdict: ok
note: Probe 역할·장애 패턴·권장안 모두 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-05-21T13:47:50Z#

verdict: ok
note: Probe 역할과 장애 패턴 설명이 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-05-22T14:20:01Z#

verdict: ok
note: Kubernetes probe 동작과 설계 권고가 현재 practice와 부합함

Sagwan Revalidation 2026-05-23T14:58:08Z#

verdict: ok
note: Kubernetes probe 동작과 설계 권장은 현재 practice와 일치합니다.

Sagwan Revalidation 2026-05-24T15:11:14Z#

verdict: ok
note: Kubernetes probe 동작과 설계 권장안이 현재 practice와 일치한다.

Sagwan Revalidation 2026-05-25T15:28:28Z#

verdict: ok
note: Kubernetes probe 역할과 장애 패턴 설명이 현재 practice와 부합함

Sagwan Revalidation 2026-05-26T15:34:55Z#

verdict: ok
note: Probe 역할과 장애 패턴 설명이 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-05-27T16:19:53Z#

verdict: ok
note: [chatgpt 오류] The read operation timed out

Sagwan Revalidation 2026-05-28T16:48:26Z#

verdict: ok
note: Probe 역할과 장애 패턴 설명이 현재 Kubernetes practice와 부합한다.

Sagwan Revalidation 2026-05-29T17:16:07Z#

verdict: ok
note: Kubernetes probe 역할과 장애 설계 권장은 현재 practice와 일치함

Sagwan Revalidation 2026-05-31T17:26:02Z#

verdict: ok
note: Kubernetes probe 동작과 설계 권장안이 현재 practice와 일치한다.

Sagwan Revalidation 2026-06-01T18:07:29Z#

verdict: ok
note: [chatgpt HTTP 401] {

Sagwan Revalidation 2026-06-02T22:06:02Z#

verdict: ok
note: Kubernetes probe 역할과 권장 설계가 현재 practice와 일치한다.

Sagwan Revalidation 2026-06-03T22:56:12Z#

verdict: ok
note: Kubernetes probe 동작과 설계 권장안은 현재도 표준 practice와 부합한다.

Sagwan Revalidation 2026-06-04T23:28:11Z#

verdict: ok
note: Probe 역할과 장애 패턴 설명이 현재 Kubernetes practice와 부합함