쿠버네티스 교육

14. Kube 교육 - Readiness/Liveness Probe

Jerry_이정훈 2021. 6. 4. 16:39
728x90

실습

  • Kafka Bitnami Helm Chart 실행하여 사용 중인 Probe 확인

Why Readiness, Liveness Probe?

Application이 아직 Traffic을 받을 준비가 안되어 있는 경우, 예를 들어 Tomcat에서 DB 연결이 제대로 안되면 Process는 실행 중이라도 정상적으로 Traffic 처리를 하지 못 합니다. 이 경우 Tomcat을 Traffic이 받지 못하도록 설정이 필요합니다.

이러한 기능을 Readiness(준비 여부 정도 번역) Probe가 담당합니다. Readiness Probe에서 정상 여부를 확인하여 정상적이지 못하다고 판단되면 Service에서 제외 합니다. 비슷한 사례로
readiness probe 설정이 없다면 nginx restart 시 잠깐이지만 정상적으로 DB 접속을 하지 못하는 빈페이지를 사용자에게 노출 할 수 있습니다. 

Readiness Probe란?
프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다. (공식 홈페이지)
(말이 어렵습니다.)

readinessProbe를 별도로 둠으로써 컨테이너가 실행된 다음에 바로 서비스에 투입되어서 트래픽을 받는게 아니라, 실제 트래픽을 받을 준비가 된걸 확인한 후에 트래픽을 받도록 할 수 있습니다. 자바 같은 경우처럼 프로세스가 시작된 후에 앱이 초기화되기까지 시간이 걸리는 경우에 유용하게 사용할 수 있습니다. 그 뿐만 아니라 앱이 구동될때 대용량 데이터를 로딩해야 하거나, 컨테이너는 시작됐지만 앱의 환경설정 실수로 앱 구동이 되지 않는 경우등을 대비할 수 있습니다. 
출처: https://arisu1000.tistory.com/27829 [아리수]

Liveness(살아 있음 정도 번역) probe(탐침봉 정도 번역)는 Readiness Probe와 유사하게 Process는 실행 중이라 POD는 Running 상태이지만 process hang 등으로 정상적으로 동작하지 않으면 자동으로 POD를 재시작하는 기능을 제공합니다. 

같은 Probe 입니다.

Readiness, Liveness Probe 실전 예제

아래는 tomcat probe 예제 입니다. tomcat이 정상 동작 여부를 검증하는 페이지를 만들어서(DB 접속이 정상적으로 되어야 실행되는 페이지) 해당 페이지 정상 접속 ‘200’ 응답 이 후 외부 트래픽을 받거나(readiness) 실패 시 POD를 자동 재시작(liveness)하도록 하였습니다. 해당 내역을 YAML 파일에 추가합니다. 

 

tomcat deploy YAML 파일 예제

(생략)
        livenessProbe:
          httpGet:
            path: /healthCheck
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 30
          failureThreshold: 3
          successThreshold: 1
          timeoutSeconds: 5
        readinessProbe:
          httpGet:
            path: /healthCheck
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 30
          failureThreshold: 3
          successThreshold: 1
          timeoutSeconds: 5
(생략)

Probe는 아래 3가지 type 사용 가능합니다. HTTP Test(200 응답), TCP Test(Port 오픈), Shell 실행(정상 실행) 입니다.

아래 예시는 Bitnami Kafka Helm Chart 설치 시 포함되는 ‘tcp socket’ type Probe 예제 입니다. 이렇게 대부분의 Helm Chart는 기본적으로 Readiness/Liveness Probe를 포함하고 있습니다.

[spkr@erdia22 44.Kafka (k3s:redis)]$ helm pull bitnami/kafka

[spkr@erdia22 44.Kafka (k3s:redis)]$ mv kafka/ kafka-12.18.3/

[spkr@erdia22 44.Kafka (k3s:redis)]$ cd kafka-12.18.3/

[spkr@erdia22 kafka-12.18.3 (k3s:redis)]$ ls
Chart.lock  charts  Chart.yaml  files  README.md  templates  values.yaml

[spkr@erdia22 kafka-12.18.3 (k3s:redis)]$ k create ns kafka
namespace/kafka created

[spkr@erdia22 kafka-12.18.3 (k3s:redis)]$ kns kafka
Context "k3s" modified.
Active namespace is "kafka".

[spkr@erdia22 kafka-12.18.3 (k3s:kafka)]$ helm install kafka -f values.yaml . -n kafka
NAME: kafka
LAST DEPLOYED: Wed Jun 16 07:12:20 2021
NAMESPACE: kafka
(이하 생략)

[spkr@erdia22 kafka-12.18.3 (k3s:kafka)]$ k get sts kafka -o yaml |k neat > kafka-sts.yml

[spkr@erdia22 kafka-12.18.3 (k3s:kafka)]$ cat kafka-sts.yml
(생략)
        livenessProbe:
          failureThreshold: 3
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          tcpSocket:
            port: kafka-client
          timeoutSeconds: 5

(생략)
        readinessProbe:
          failureThreshold: 6
          initialDelaySeconds: 5
          periodSeconds: 10
          successThreshold: 1
          tcpSocket:
            port: kafka-client
          timeoutSeconds: 5

다음 예제는 Binami RabbitMQ Helm Chart 입니다. 이번에는 'exec command' type의 Probe를 사용 하였습니다. 

[spkr@erdia22 ~ (dz-saas:rabbitmq-cloud01)]$ k get sts -o yaml |k neat > rabbitmq-sts.yml
[spkr@erdia22 ~ (dz-saas:rabbitmq-cloud01)]$ cat rabbitmq-sts.yml
(생략)
          livenessProbe:
            exec:
              command:
              - /bin/bash
              - -ec
              - rabbitmq-diagnostics -q ping
            failureThreshold: 6
            initialDelaySeconds: 120
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 20

          readinessProbe:
            exec:
              command:
              - /bin/bash
              - -ec
              - rabbitmq-diagnostics -q check_running && rabbitmq-diagnostics -q check_local_alarms
            failureThreshold: 3
            initialDelaySeconds: 10
            periodSeconds: 30
            successThreshold: 1
            timeoutSeconds: 20

위와 같이, 실제 운영 환경에서 공식 Helm Chart 등을 사용하면 대부분 기본으로 Probe 가 포함되어 있습니다. 공식 Helm Chart를 사용하지 않고 Custom으로 YAML 만드시면 반드시 포함하실 것을 권고 드립니다. 

 

감사합니다. 

반응형