Kubernetes Probe (Liveness, Readiness, Startup)

Overview

 

Kubernetes에서 애플리케이션의 안정적인 운영을 위해 중요한 개념 중 하나가 바로 Probe이다.
클러스터를 구축하거나 배포 설정을 하다 보면 liveness, readiness, startup 같은 Probe 설정을 자주 마주하게 된다.

 

Probe는 단순히 컨테이너가 살아 있는지뿐만 아니라, 서비스 요청을 받을 준비가 되었는지, 기동이 완료되었는지 등 다양한 상태를 세밀하게 감지해준다.

이러한 Probe를 적절히 구성하면 장애 회복 속도 개선, 잘못된 트래픽 분산 방지, 무한 재시작 루프 방지 등의 효과를 얻을 수 있다.

 

이 글에서는 Kubernetes에서 지원하는 Probe의 개념과 종류, 각각의 용도와 동작 방식을 실무적 관점에서 정리해본다.

 

 

 

 

 

 

 

---

 

 

 

 

Probe란?

Probe는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다.

 

이 Probe를 통해 쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크한 후, 문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제가 있는 컨테이너를 서비스에서 제외할 수 있다.

 

kubelet은 컨테이너의 상태를 진단하기 위해 핸들러를 호출하는데 핸들러는 수행하는 작업의 분류에 따라서 ExecAction, TCPSocketAction, HttpGetAction로 나뉜다.

 

 

Handler

컨테이너의 상태를 진단하기 위해 어떻게 진단할 것인지 명시한 것이 Handler이다.

 

 

ExecAction

ExecAction은 컨테이너에서 지정된 명령어를 실행한다. 명령어를 실행했을 때 exit code가 0이면 성공, 이외의 값은 실패로 분류한다.

exec:
   command:
   - cat
   - /etc/nginx/nginx.conf

 

 

 

TCPAction

TCPAction은 지정된 포트로 TCP 소켓 연결을 시도한다.

tcpSocket:
    port: 8080
    initialDelaySeconds: 15
    periodSeconds: 20

 

 

HttpGetAction

지정된 포트와 url로 HTTP Get 요청을 전송하며, 응답 상태가 200 ~ 400 구간에 속하는 경우 성공, 이외에는 실패로 분류한다.

  httpGet:
    path: /healthz
    port: liveness-port

 

 

 

 

 

Probe의 종류

kubelet은 실행 중인 컨테이너에 대해 세 가지 종류의 프로브를 지정할 수 있다.

 

 

Liveness probe

애플리케이션의 상태를 체크해서 서버가 제대로 응답하는지 혹은 컨테이너가 제대로 동작중인지를 검사한다.

 

Pod은 정상적인 Running 상태이지만, 애플리케이션에 문제가 생겨서 접속이 안되는 경우를 감지한다. (메모리 오버플로우 등) 문제를 감지하면 Pod을 죽이고 재실행하여 애플리케이션의 문제를 해결한다.

 

 

 

Readiness probe

컨테이너가 요청을 처리할 준비가 되었는지 확인하는 probe이다.

Pod가 새로 배포되고 Running 상태여도 처음에 로딩하는 시간이 있기 때문에

이 시간 동안은 애플리케이션에 접속하려고 하면 오류가 발생한다.

 

Readiness probe는 어플리케이션이 구동되기 전까지 서비스와 연결되지 않게 해준다. (Readiness Probe가 실패할 때 엔드포인트 컨트롤러가 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. )

 

Liveness Probe와 비교했을 때 어떤 차이가 있냐면, Liveness Probe는 probe 핸들러 조건 아래 fail이 나면 pod을 재실행 시키지만 Readiness Probe는 pod을 서비스로부터 제외시킨다.

 

 

 

Startup probe

컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.

startup probe가 주어진 경우, 성공할 때 까지 다른 나머지 prob는 활성화 되지 않는다.

만약 startup probe가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다.

 

 

 

 

 

Probe 설정 시 유의할 값들

• `initialDelaySeconds`: 컨테이너 시작 후 Probe를 시작할 때까지 대기 시간. 너무 짧으면 false positive 발생.
• `timeoutSeconds`: 응답을 기다리는 최대 시간. 느린 I/O 작업이 있다면 충분히 확보 필요.
• `failureThreshold`: 실패를 몇 번 반복해야 실패로 간주할 것인지. 민감도 조절에 핵심.
• `periodSeconds`: Probe를 실행하는 주기. 지나치게 짧게 잡으면 시스템 부하가 늘어날 수 있음.

 

 

 

 

 

---

 

 

 

 

 

 

 

각 probe를 언제 사용해야할까?

 

Liveness Probe

사실 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 unhealty 상태가 되어(ex: out of memory) 프로세스가 중단된다면

원래는 kubelet이 파드의 restartPolicy에 따라서 올바른 대처를 자동으로 수행한다.

 

이와 같은 경우에는 Liveness Probe를 설정한다고 해서 큰 효과는 없고

애플리케이션이 데드락 상태에 머무르는 것을 감지하여 재시작시킬 때 유용하다.

 

 

Readiness Probe

probe가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면 Readiness probe를 지정하면 된다.

왜냐하면 그전까지는 애플리케이션이 로드되지 않은 상황에서도 트래픽이 해당 애플리케이션으로 라우팅될 수 있기 때문이다.

 

혹은 컨테이너의 지속적인 유지 및 관리를 위해서 자체적으로 중단을 수행하는 경우는

pod을 죽이는 Liveness probe말고 Readiness probe를 사용할 수 있다.

 

 

Startup Probe

서비스를 시작하는 데 오랜 시간이 걸리거나 불규칙적인 컨테이너에 설정하는 데 사용될 수 있다.

(예를 들면 third party 에서 특정 데이터를 다운받는 등의 경우) startup probe가 성공하고 나서

 

liveness, readiness probe가 동작하기 때문에 기동시간이 불규칙적인 애플리케이션이

liveness probe에 의해 기동되기도 전에 재시작 되는 것을 방지할 수 있다.

(Readiness probe랑 비슷하지만 방금 말한 부분은 Readiness probe로 해결하기 어렵다.

 

 

 

실무에서 흔히 발생하는 Probe 관련 오해 및 문제 사례

 

• Readiness Probe만 설정한 경우, 컨테이너가 죽었는데도 Pod 자체는 Running 상태로 남아 트래픽은 차단되지만 모니터링 시스템에서는 장애로 인지되지 않을 수 있음.
• Liveness Probe만 설정한 경우, 애플리케이션이 일시적으로 느려지거나 외부 의존 서비스 문제로 실패해도 무조건 재시작되어 오히려 더 큰 장애로 이어질 수 있음.
• Startup Probe는 생략했지만 실제로 초기 부팅 시간이 긴 경우, liveness probe가 너무 빨리 시작되어 무한 재시작 루프에 빠질 수 있음.

 

 

 

 

 

Helm 차트에서 Probe 설정하는 팁

내용: Helm 차트를 사용하는 경우 `values.yaml` 에서 probe 설정을 추상화하는 패턴을 자주 사용한다.

livenessProbe:
  enabled: true
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

readinessProbe:
  enabled: true
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

• 이처럼 `enabled, initialDelaySeconds, periodSeconds` 값을 `values` 로 노출시키고 템플릿에 `{{- if .Values.livenessProbe.enabled }}` 식으로 조건부 렌더링을 걸면, 환경별로 쉽게 제어할 수 있다.

 

 

 

 

 

모니터링 및 디버깅 팁

• `kubectl describe pod <pod-name>` 명령어로 Probe 상태와 최근 실패 이력을 확인할 수 있다.
• Events 섹션에서 Probe 실패 메시지를 통해 디버깅 힌트를 얻을 수 있다.
• `kubectl get events --sort-by='.lastTimestamp'` 로 최근 이벤트 흐름을 파악해보자.
• Prometheus나 Grafana에서 Probe failure metrics를 수집해 장애 조기 감지에 활용할 수 있다.

 

 

 

 

 

---

 

 

 

 

🔚 마무리: “올바른 Probe 설정은 장애를 줄이고, 신뢰성을 높인다”

Kubernetes의 Probe는 단순한 헬스 체크 이상의 역할을 한다.

 

잘못된 설정은 오히려 정상 동작 중인 애플리케이션을 재시작시키거나, 반대로 장애가 난 서비스에 트래픽을 전달하게 만들 수도 있다.

• Liveness Probe는 데드락 상태나 무한 루프처럼 정상적으로 종료되지 않는 문제를 감지하여 자동 복구할 수 있게 해준다.
• Readiness Probe는 애플리케이션이 실제로 요청을 받을 준비가 되었는지를 판단하여 잘못된 라우팅을 막아준다.
• Startup Probe는 기동 시간이 오래 걸리는 앱에 적절히 활용하여 불필요한 재시작을 방지한다.

 

 

모든 Probe를 무조건 사용하는 것보다, 애플리케이션 특성과 배포 목적에 따라 선별적이고 전략적으로 구성하는 것이 중요하다.
서비스 안정성과 자동 복구 능력을 높이기 위해 지금 사용하는 파드에 어떤 Probe가 필요한지 점검해보세요.

 

 

 

 

 

---

 

Reference

• Kubernetes 공식 문서 - Probes
• Kubernetes - Liveness vs Readiness vs Startup Probes 정리
• Blog: Understand Kubernetes Probes Deeply
• Kubernetes Docs - Configure Probes for containers