[Health Check] 2. Readiness and Startup Probe

 지난 글에서 Liveness Probe에 대해 살펴보았습니다. Command, HTTP, TCP 등의 방법으로 컨테이너의 상태를 확인하고, 비정상인 경우 컨테이너를 재시작하여 이를 해결하고자 하였습니다. 이번 글에서는 쿠버네티스에서 제공하는 또 다른 Probe인 Readiness probe 및 Startup probe 에 대하여 알아보겠습니다.

Liveness Probe

 Liveness probe는 애플리케이션이 교착 상태에 머무르는 것을 감지하고, 컨테이너를 재시작하여 이를 해결합니다. 이렇게 하여 애플리케이션의 가용성을 확보할 수 있습니다.

Readiness Probe

 Readiness probe는 바쁜 컨테이너를 잠시 서비스에서 제외시켜 트래픽을 받지 않도록 하는 기능입니다. Pod 내의 모든 컨테이너가 Ready 상태가 된 경우, 해당 Pod는 준비가 된 것으로 간주하지만, 그렇지 않은 경우 서비스 로드밸런서로부터 제외되어 더 이상 트래픽을 받을 수 없게 됩니다. 이러한 기능은 Pod 내 일부 컨테이너가 일시적으로 트래픽을 처리할 수 없을 때에 유용하게 활용할 수 있습니다.

Startup Probe

 Startup Probe는 Readiness Probe와 비슷하게 Pod 내 각 컨테이너의 준비 상태를 확인합니다. 차이점은 최초 1회 Pod가 시작될 때에만 적용된다는 점입니다. 또한 모든 컨테이너가 준비 되기 전 까지는 Liveness 및 Readiness Probe를 비활성화합니다. 시작 시간이 오래 걸리는 컨테이너나, 초기화에 걸리는 시간이 예측 불가능한 애플리케이션에 유용합니다.

 

---

Readiness Probe

 한 번 실행된 애플리케이션 인스턴스는 오랜 시간 계속해서 실행 중인 상태로 존재합니다. 이렇게 오랜 시간 동작하다 보면 가끔은 트래픽을 일시적으로 처리할 수 없는 단계에 빠지기도 합니다. 대용량의 데이터 혹은 구성 파일을 불러오는 경우가 이에 해당합니다. 이런 경우에는 인스턴스를 재시작하는 것 보다는, 수행 중인 작업이 처리되기까지는 해당 인스턴스에서는 트래픽을 받지 않고 다른 인스턴스를 통해 처리하다가, 트래픽을 처리할 수 있는 상태가 되었을 때 다시 트래픽을 수용하도록 하는 것이 좋습니다. 쿠버네티스에서는 각 인스턴스는 Pod 단위로 구현되며, 이러한 상황을 감지하고 대응하기 위해 Readiness probe 기능을 제공합니다. 

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-exec
spec:
  containers:
  - name: readiness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

 Readiness probe는 Liveness probe와 유사하게 설정할 수 있습니다. Liveness probe 설정에서 livenessProbe: 로 되어있는 항목을 readinessProbe: 로 바꾸기만 하면 됩니다. Readiness probe 역시 마찬가지로 명령 기반 Probe 뿐만 아니라 HTTP 및 TCP 로도 Readiness probe에 동일하게 적용할 수 있습니다. 이런 설정을 통해 Readiness probe는 컨테이너의 준비 상태를 확인합니다. 

 Liveness probe와 달리 Readiness probe는 실패 시 컨테이너를 재시작시키지 않습니다. 대신 연결된 Service에서 잠시 분리시켜 둡니다. 이렇게 함으로써 외부에서 추가적으로 유입되는 트래픽이 차단되고, 컨테이너는 처리 중인 작업에 집중할 수 있게 됩니다. 모든 처리를 잘 끝낸 후 successThreshold(기본값: 1) 만큼 Readiness probe가 성공하여 트래픽을 받을 준비가 되었을 때, 다시 Service와 연결되어 트래픽을 받을 수 있게 됩니다. 

 이처럼 Liveness와 Readiness 는 이름이 비슷할 뿐, 각자 수행하는 역할이 다릅니다. 따라서 한 컨테이너에서 Readiness probe와 Liveness probe를 병행하여 사용하도록 구성할 수 있습니다. 두 설정을 함께 사용할 경우 Readiness probe에 실패한, 즉 준비되지 않은 컨테이너에 대해서는 트래픽을 전달하지 않으며 Liveness probe에 실패한 컨테이너는 재시작하여 애플리케이션의 가용성을 확보할 수 있습니다. 

 

---

Startup Probe

 Startup probe는 쉽게 말해 '시작 시점에만 적용되는 Readiness probe' 입니다. 몇몇 오래된 애플리케이션의 경우, 초기화에 소요되기까지 걸리는 시간이 오래 걸리는 경우가 있습니다. 이런 경우 Liveness probe에 의해 컨테이너가 정상적으로 시작되기 전에도 재시작되는 것을 막기 위해 initialDelaySeconds 를 매우 길게 설정하거나 failureThreshold를 충분히 늘려두어야 하는데, 이렇게 설정해두면 실제로 애플리케이션의 문제를 빠르게 감지하기가 어려워집니다. 이럴 때 유용하게 사용할 수 있는 것이 Startup probe 입니다. 

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

 Startup probe 설정 또한 Liveness probe 와 매우 유사합니다. 위 설정은 매 10초마다 한번씩 /healthz 경로로 HTTP 요청에 대한 응답 코드를 확인하여, 애플리케이션이 정상적으로 실행되었는지 여부를 판단합니다.

 Startup probe는 성공하기 전까지 Liveness 및 Readiness probe의 동작을 비활성화합니다. Startup Probe가 성공하게 되면 그 시점 이후부터 Liveness 및 Readiness probe가 동작하게 됩니다. 이러한 설정은 시작시간이 느린 애플리케이션이 Liveness probe에 의해 시작되기도 전에 재시작되는 것을 방지할 수 있습니다. 또한 Liveness probe의 initialDelaySeconds 및 failureThreshold 값을 늘려서 설정하는 것과는 달리 실제 실행 중인 애플리케이션에 대한 감시가 느슨해지는 것을 막을 수도 있습니다.

 이렇게 Startup probe를 설정해두면 컨테이너 시작에 소요되는 최대 소요 시간(worst case)이 failureThreshold(30) * periodSeconds(10) = 300초로 제한됩니다. 만약 failureThreshold에 명시된 횟수(30) 만큼 Startup probe가 실패한 경우, kubelet은 Pod의 .spec.restartPolicy 설정에 따라 해당 Pod를 재시작 혹은 중단시킵니다.

 

restartPolicy 값의 종류

• Always: 컨테이너가 정상적으로 종료되었다 하더라도, 해당 컨테이너를 다시 시작 (기본값)
• OnFailure: 컨테이너에 문제가 있어 종료된 경우, 해당 컨테이너를 다시 시작
• Never: 컨테이너를 재시작하지 않음

 

---

참고자료

[1] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Configure Liveness, Readiness and Startup Probes

[2] https://blog.devgenius.io/understanding-kubernetes-probes-5daaff67599a

Understanding Kubernetes Probes