[K8S] Probe

Pod의 Probe란?

쿠버네티스에서 Probe는 컨테이너가 정상적으로 동작 중인지 주기적으로 확인하는 검사 기능입니다. 이 기능을 통해 쿠버네티스는 애플리케이션 상태를 파악하고, 문제가 생겼을 때 자동으로 재시작하거나 로드밸런서에서 제외할 수 있습니다.

 

Probe에는 Startup Probe, Readiness Probe, Liveness Probe 총 3가지가 있습니다.

 

1. Startup Probe

Startup Probe는 애플리케이션이 기동되는 데 시간이 오래 걸리는 경우를 고려하여 도입된 Probe입니다. 주로 초기 구동 시간이 긴 대규모 서비스나 프레임워크 기반 애플리케이션(Spring Boot)에 유용합니다. 이 Probe는 컨테이너가 완전히 시작되기 전까지는 다른 Probe(Liveness 등)가 실패해도 재시작하지 않도록 보호합니다. 즉, 초기 기동 시간 동안만 활성화되며, 한 번이라도 성공적으로 응답하면 Startup Probe는 비활성화되고, 이후에는 Liveness와 Readiness Probe가 그 역할을 이어받습니다.

 

예를 들어, SpringBoot 애플리케이션있다고 가정한다면, 애플리케이션 시작시 클래스 로딩과 초기화, 의존성 주입, 외부 설정 파일 주입, DB연결 등 많은 과정을 거칩니다. 이러한 초기화 과정 중에는 HTTP 요청을 처리할 준비가 되지 않았기 때문에 /startup 또는 /health 등의 엔드포인트에 대한 요청이 반복적으로 실패하는 것이 정상적입니다. 이 때, Startup Probe는 응답이 실패하더라도 재시작을 하지 않습니다. 응답에 성공한 경우, 더 이상 Startup Probe는 실행되지 않고, Liveness Probe와 Readiness Probe가 동작을 이어받습니다.

 

2. Readiness Probe

Readiness Probe는 애플리케이션이 외부 요청(트래픽)을 받을 준비가 되었는지 여부를 판단하는 Probe입니다.

이 Probe는 컨테이너가 살아있더라도, 아직 트래픽을 받아서는 안 되는 상황(예: DB 연결 재시도, 캐시 준비 중 등)을 처리할 수 있게 해줍니다.

 

Readiness Probe가 실패할 경우, 해당 Pod는 Service의 Endpoints 목록에서 제거되어 로드밸런싱 대상에서 제외됩니다.

단, 컨테이너가 재시작되지는 않습니다. 즉, 응답에 실패한다면 트래픽 전달을 중단하게 되고, 응답이 성공한다면 트래픽 전달을 다시 시작하게 됩니다.

 

3. Liveness Probe

Liveness Probe는 컨테이너가 살아있는지(정상 동작 중인지)를 판단하는 데 사용됩니다. 애플리케이션이 무한 루프에 빠졌거나, deadlock이 발생한 경우 Liveness Probe는 이를 감지해 컨테이너를 자동으로 재시작합니다. 즉, 이 Probe는 장기적인 컨테이너의 생존 여부를 감시하며, 실패 시 Kubernetes는 해당 컨테이너를 종료하고 재기동합니다. 응답 실패시, 컨테이너를 재시작하고 성공하면 정상 상태를 유지하게 됩니다.

 

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image
      ports:
        - containerPort: 8080
      startupProbe:
        httpGet:
          path: "/ready"
          port: 8080
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 10
      readinessProbe:
        httpGet:
          path: "/ready"
          port: 8080
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 2
      livenessProbe:
        httpGet:
          path: "/ready"
          port: 8080
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 2

 

예를 들어, 위와 같은 startupProbe, readinessProbe, livenessProbe가 모두 설정된 Pod가 하나 있다고 가정해봅시다.

1. Startup Probe

• Pod가 생성되고 컨테이너가 시작되면, 가장 먼저 Startup Probe가 작동합니다.
• /ready 경로로 10초마다 HTTP 요청을 보냅니다.
• 이 요청이 연속 10번 실패하면 Kubernetes는 “기동 실패”로 판단하고 컨테이너를 재시작합니다.
• 즉, 최대 100초(10×10) 동안 기다려줍니다.
• 단 한 번이라도 응답이 성공하면, Startup Probe는 종료되고 다음 Probe로 넘어갑니다.

2. Readiness Probe

• Startup Probe가 성공하면, 이제 Readiness Probe가 활성화됩니다.
• /ready 경로로 10초마다 요청을 보내며, 컨테이너가 외부 요청을 받을 준비가 되었는지를 판단합니다.
• 2번 연속 실패하면, 해당 Pod는 Service의 로드밸런서 대상에서 제외되어 트래픽을 받지 않게 됩니다.
• 단, 컨테이너가 살아는 있으므로, 재시작되진 않습니다.

3. Liveness Probe

• Liveness Probe 역시 Startup Probe 성공 이후 함께 작동합니다.
• 이 Probe는 컨테이너가 내부적으로 정상 작동 중인지(예: 무한 루프, deadlock 여부 등)를 판단합니다.
• /ready 경로가 2회 연속 실패하면, 해당 컨테이너는 “비정상 상태”로 판단되어 재시작됩니다.

이처럼 3개의 Probe를 함께 설정하면, 시작은 유연하게, 서비스 노출은 안전하게, 장애 복구는 자동으로 처리할 수 있습니다.

 

 

Probe 실습

이번에는 실제 상황을 시뮬레이션하며, Kubernetes의 Probe가 어떻게 동작하는지를 좀 더 깊이 이해해보겠습니다. 저, Horizontal Pod Autoscaler(HPA)의 최소 Replica 수를 1로 변경해줍니다. 왜냐하면 다수의 Replica가 존재하면 Pod마다 상태가 달라질 수 있어, Probe의 동작을 추적하기가 어렵기 때문입니다.

kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":1}}'

 

 

Pod가 하나만 있는 것을 확인하고 재시동하여 다음과 같이 Grafana 대시보드를 통해 Probe의 요청 로그를 확인할 수 있습니다.

 

처음에는 Startup Probe가 실패로 나오고 애플리케이션 기동이 완료가 되면 Liveness, Readiness Probe의 로그가 성공적으로 나옵니다. 서비스가 유지되는 동안 Liveness, Readness Probe는 계속 요청을 하게 됩니다.

 

한 가지 주의할 점은 Liveness Probe와 Readiness Probe는 지속적으로 애플리케이션의 특정 엔드포인트에 요청을 보내는 방식으로 동작합니다. 그래서 최대한 가볍고 빠르게 응답할 수 있도록 구현해야 합니다. 예를 들어, DB의 쿼리를 이용해 데이터를 CRUD 하거나, 복잡한 로직, 외부 API 호출같은 무거운 작업은 피해야 합니다.

 

정리

과거에는 애플리케이션의 상태를 확인하고, 비정상 동작 시 재시작하거나 트래픽을 차단하는 작업을 운영자가 수동으로 처리해야 했습니다.

예를 들어, 모니터링 도구를 통해 장애를 감지하고, 사람이 직접 로그를 확인하거나 재기동 스크립트를 실행하는 방식이 일반적이었습니다.

하지만 쿠버네티스의 등장, 그리고 그 안에서 제공하는 Probe 기능 덕분에 애플리케이션의 상태 점검과 대응이 자동화되었습니다. 구체적으로 애플리케이션이 느리게 시작되더라도 Startup Probe가 보호해주고 준비되지 않은 상태에서는 Readiness Probe가 트래픽을 막아주며 비정상적으로 작동할 경우에는 Liveness Probe가 자동으로 재시작해주는 구조입니다.

 

결국, 운영의 복잡도는 낮아지고, 서비스의 안정성과 회복력은 높아진 셈입니다. Probe는 단순한 기술 요소가 아니라, 클라우드 네이티브 시대의 운영 자동화 철학을 잘 보여주는 핵심 기능이라 할 수 있습니다.