1. 개요

정상 상태 점검(Health Probe) 패턴은 애플리케이션이 쿠버네티스와 정상 상태 여부를 주고받는 방법에 관한 패턴입니다.

2. 문제

• 쿠버네티스는 컨테이너 프로세스 상태를 주기적으로 확인하고 문제가 감지되면 컨테이너를 다시 시작합니다.
• 그러나 실제 상황에서는 애플리케이션이 멈췄더라도 프로세스 자체는 계속 실행 중일 수 있습니다.
  • 예: Java OOM이 발생해도 JVM 프로세스는 살아 있을 수 있음.
  • 무한 루프, 교착 상태, 스레싱 등으로 인해 동작하지 않을 수도 있음.

3. 해결책

• 장애를 피하는 것에서, 오류를 감지하고 복구하는 것으로 전환합니다.

1) 프로세스 정상 상태 확인

Process health는 Kubelet이 컨테이너 프로세스에 대해 지속적으로 수행하는 가장 단순한 확인 방식입니다.

2) Liveness Probe

(1) 정의

• Kubelet 에이전트가 정기적으로 컨테이너가 정상 동작 중인지 확인하는 과정입니다.
• 애플리케이션 내부보다는 외부에서 정상 상태를 점검하는 것이 중요합니다.

(2) 동작 원리

1. Liveness Probe 실행
   • Kubelet은 Pod 정의에 설정된 livenessProbe 구성을 기반으로, 주기(periodSeconds)마다 Run Handler를 실행합니다.
   • Run Handler는 httpGet, tcpSocket, exec 방식 중 하나로 상태를 점검합니다.
2. 상태 확인 요청
   • 지정된 엔드포인트 호출, TCP 연결 시도, 명령 실행 등을 통해 상태를 점검합니다.
3. 상태 판별
   • 정상 응답 시 healthy로 판단하고 그대로 유지합니다.
   • 응답이 없거나 오류 시 unhealthy로 간주합니다.
4. 실패 처리
   • failureThreshold 횟수만큼 연속 실패하면 Kubelet이 컨테이너를 재시작합니다.

(3) 예제

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet: 
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 30
      periodSeconds: 3 
      timeoutSeconds: 3 
      failureThreshold: 2 
      

• initialDelaySeconds: 최초 점검 전 대기 시간
• periodSeconds: 점검 주기(초)
• timeoutSeconds: 응답 제한 시간
• failureThreshold: 연속 실패 허용 횟수

⇒ LivenessProbe는 문제의 근본 원인을 해결하지 않고 컨테이너를 재시작하므로, 적절한 설계가 필요합니다.

3) Readiness Probe

(1) 정의

• 점검 실패 시 해당 Pod를 Service 엔드포인트에서 제거해 새로운 트래픽을 받지 않도록 합니다.
• 컨테이너가 서비스 요청을 처리할 준비가 되었을 때 신호를 보냅니다.

(2) 동작 원리

1. Readiness Probe 실행
   • Kubelet이 주기적으로 Run Handler를 실행하여 준비 여부를 점검합니다.
2. 준비 상태 확인
   • 예: /ready 호출, DB 연결 가능 여부, TCP 연결 가능 여부 확인.
3. 결과 처리
   • 성공 시 Pod를 Service 엔드포인트에 등록하여 트래픽을 수신합니다.
   • 실패 시 엔드포인트에서 제거하고, 준비될 때까지 반복 점검합니다.

(3) 예제

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-readiness-check
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
    readinessProbe:
      exec:
        command: { "stat", "/var/run/random-generator-ready"

• 특정 파일이 존재해야 준비 완료로 판단합니다.
• 파일이 없으면 점검에 실패하고 트래픽이 차단됩니다.

4) Startup Probe

(1) 정의

• 느린 기동(콜드 스타트, 캐시 워밍, 대형 마이그레이션) 서비스에 필요합니다.
• 성공하기 전까지 Liveness/Readiness Probe가 실행되지 않아, 성급한 재시작이나 트래픽 유입을 방지합니다.

(2) 동작 원리

1. Startup Probe 실행
   • Kubelet은 Pod 정의에 설정된 startupProbe 구성을 기반으로, 컨테이너 시작 시 Run Handler를 실행합니다.
   • Run Handler는 httpGet, tcpSocket, exec 방식 중 하나로 애플리케이션의 기동 여부를 점검합니다.
2. 시작 여부 확인 요청
   • 지정된 엔드포인트 호출, TCP 연결 시도, 명령 실행 등을 통해 컨테이너 애플리케이션이 시작되었는지를 확인합니다.
3. 상태 판별
   • 정상 응답 시 healthy로 판단하고, Liveness/Readiness Probe를 활성화합니다.
   • 응답이 없거나 오류 시 unhealthy로 간주하며, Liveness/Readiness Probe를 비활성 상태로 유지합니다.
4. 실패 처리
   • failureThreshold 횟수만큼 연속 실패하면 Kubelet이 컨테이너를 재시작합니다.
   • 재시작 후 동일한 Startup Probe 절차를 반복합니다.

(3) 예제

startupProbe:
  httpGet:
    path: /healthz 
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

4. Liveness vs Readness vs Startup

[비교]

구분	목적	동작 시점	실패 시 동작	사용 예	비고
LivenessProbe	앱이 살아 있는지 확인	실행 중 지속	재시작	Deadlock, 장시간 응답 없음	응답은 있으나 기능이 멈춘 경우도 감지
ReadinessProbe	트래픽 수신 준비 여부 확인	실행 후 지속	엔드포인트 제거	초기화 후 트래픽 시작, DB 오류 시 트래픽 차단	재시작 없음
StartupProbe	초기 기동 상태 확인	시작 시 1회	재시작	대규모 데이터 로딩, JIT 컴파일	긴 로딩 시간 보호

[핵심 요약]

• LivenessProbe → 앱이 죽었는지 감시 (죽으면 재시작)
• ReadinessProbe → 앱이 요청 받을 준비 됐는지 확인 (준비 안 되면 트래픽 차단)
• StartupProbe → 앱이 처음 시작될 때만 체크 (기동 완료 시 다른 Probe로 전환)

5. 전체적인 동작 순서

1) Pod 시작 후 Startup Probe부터 시작

• Pod가 실행되면, Kubelet은 먼저 Startup Probe를 실행하여 컨테이너 내부 애플리케이션이 정상적으로 시작되었는지 확인합니다.
• Startup Probe가 성공해야만 이후 Readiness Probe와 Liveness Probe가 활성화됩니다. Kubelet의 Probe 간 전환 흐름이 이 다이어그램에서 가장 먼저 표현된 흐름입니다.
  

2) Startup Probe 실패 시

• 설정한 failureThreshold 횟수만큼 연속 실패하면, Kubelet이 컨테이너를 재시작합니다.
• Liveness 및 Readiness Probe는 아직 실행되지 않습니다.

3) Startup Probe 성공 후, Readiness Probe 수행

• Startup Probe 성공 이후 컨테이너 초기화가 완료되었다고 판단되면, 그다음으로 Readiness Probe를 시작합니다.
• Readiness는 Pod가 트래픽 수신이 가능한 상태인지를 검사하며, healthy로 평가되면 Service Endpoint에 등록되고, unhealthy일 경우는 등록 해제됩니다.

4) 마지막으로 활성화되는 Liveness Probe

• 컨테이너가 정상적으로 기동되어 Ready 상태가 되면, Liveness Probe가 주기적으로 실행되어 컨테이너가 계속 동작 중인지 확인합니다.
• 응답하지 않거나, 오류 상태가 지속되면 failureThreshold 기준에 따라 컨테이너를 재시작합니다.

순서	Probe 유형	역할 요약
1	Startup Probe	애플리케이션이 시작되지 않았다면 Liveness/Readiness을 차단
2	Readiness Probe	트래픽 수신 준비 여부 판단, Service Endpoint 등록/제거
3	Liveness Probe	실행 중인 애플리케이션의 정상 상태 지속 여부 확인, 실패 시 재시작

6. 추가 내용

• Liveness, Readiness는 네이티브 애플리케이션의 자동화의 기본 빌딩 블록이다.
• Spring Actuator, Wild-Fly Swarm 정상상태 확인, Karaf 정상상태 확인, 자바용 마이크로프로파일 스펙 등의 애플리케이션이 정상상태 점검 제공을 위한 구현 방법을 제공한다.
• 로깅을 통해서 중요한 이벤트, 로그를 남기고 추후 분석하기 위해 중앙에서 수집하는것이 좋다.

7. 참조

• 쿠버네티스 공식 문서 : https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• 다이어그램 : http://cloudacode.com/hello-kubernetes/hello-kubernetes/section02/readiness-liveness-probe/?utm_source=chatgpt.com
• 전체 동작 원리 : https://seongjin.me/kubernetes-pods/