Probe

1. 개요

Probe는 kubelet 이 주기적으로 컨테이너를 찔러 보는 검사다. 세 종류가 있고, 실패했을 때 벌어지는 일이 서로 다르다. 이 차이를 모르면 잘못 쓰기 쉽다.

2. 순서

셋은 나란히 도는 게 아니라 단계가 있다.

공식 문서 그대로다 — “startup 프로브가 설정되어 있으면, 그것이 성공할 때까지 쿠버네티스는 liveness 와 readiness 프로브를 실행하지 않는다.”

3. 세 프로브의 용도

liveness 는 교착을 위한 것이다. 공식 문서의 예시가 “프로세스는 돌고 있는데 진행하지 못하는 상태"다. 앱이 문제가 생겼을 때 스스로 죽는다면 liveness 는 필요 없다 — kubelet 이 restartPolicy 로 알아서 처리한다.

readiness 는 의존성을 위한 것이다. 앱 자체는 멀쩡한데 DB 연결이 아직이라면, 죽일 게 아니라 트래픽만 안 보내면 된다.

앱은 정상, DB 연결 대기 중
  liveness  → 통과   (앱은 살아 있으니까)
  readiness → 실패   (아직 요청을 처리 못 하니까)
결과: 재시작 없이 트래픽만 안 온다 ✅

4. 검사 방식

네 가지 중 하나만 지정한다.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15   # 첫 검사까지 대기
  periodSeconds: 10         # 검사 주기 (기본 10초)
  failureThreshold: 3       # 몇 번 실패하면 조치할지

5. 연쇄 장애

공식 문서가 경고(Caution) 로 표시한 지점이다.

“Incorrect implementation of liveness probes can lead to cascading failures.”

부하가 높을 때 응답이 느려지면 liveness 가 실패하고, 컨테이너가 재시작된다. 그 사이 다른 Pod 들이 그 부하를 나눠 받아 더 느려지고, 그것들도 재시작된다.

부하 증가
  → 응답 지연 → liveness 실패 → 재시작
  → 그 Pod 몫이 남은 Pod 로 → 더 느려짐 → 또 실패 → 또 재시작
  → 전체가 무너진다

재시작이 해결책이 아닌 상황에서 재시작을 하기 때문이다. 느린 것은 죽은 것이 아니다.

그래서 공식 문서가 권하는 패턴이 있다 — liveness 와 readiness 에 같은 저비용 엔드포인트를 쓰되, liveness 의 failureThreshold 를 더 높게 두는 것이다. 그러면 문제가 생겼을 때 트래픽이 먼저 끊기고(readiness), 그래도 회복되지 않을 때만 재시작된다(liveness).

문제 발생
  readiness 먼저 실패 → 트래픽 차단 → 부하가 빠지며 회복 기회
  회복 안 되면 → liveness 실패 → 그때 재시작

6. startupProbe 의 판단 기준

시작이 느린 앱에 liveness 를 그냥 걸면 뜨는 도중에 죽는다. 초기화가 안 끝났는데 검사가 시작되기 때문이다.

initialDelaySeconds 를 크게 잡는 방법도 있지만, 그러면 평상시 장애 감지도 그만큼 늦어진다. startupProbe 는 이 둘을 분리한다.

공식 문서의 판단 기준은 명확하다.

컨테이너가 보통 initialDelaySeconds + failureThreshold × periodSeconds 보다 오래 걸려 시작한다면, liveness 와 같은 엔드포인트를 검사하는 startup 프로브를 지정해야 한다.

7. 관련 문서

• Service — readiness 실패 시 EndpointSlice 에서 빠진다
• restartPolicy — liveness 실패 후의 동작을 정한다 (예정)

8. 출처

세 프로브의 동작, 순서, 연쇄 장애 경고는 공식 문서 “Liveness, Readiness, and Startup Probes” 에 근거한다.

“If a startup probe is configured, Kubernetes does not execute liveness or readiness probes until the startup probe succeeds.”

“If the readiness probe returns a failed state, the EndpointSlice controller removes the Pod’s IP address from the EndpointSlices of all Services that match the Pod.”

“Liveness probes could catch a deadlock, where an application is running, but unable to make progress.”

“Incorrect implementation of liveness probes can lead to cascading failures. This results in restarting of container under high load; failed client requests as your application became less scalable; and increased workload on remaining pods due to some failed pods.”

• Kubernetes — Liveness, Readiness, and Startup Probes
• Kubernetes — Configure Liveness, Readiness and Startup Probes