Liveness/Readiness Probe

파드에서 어플리케이션이 비정상 작동을 할 경우에 대비하여 Liveness/Readiness Probe 를 설정할 수 있다. Liveness Probe 는 컨테이너가 정상적으로 구동 중 인지를 체크할 수 있다. 결과가 정상이 아니면 컨테이너를 재시작한다. Readiness Probe 는 파드가 트래픽을 처리할 준비가 되어 있는지를 체크한다. 결과가 정상이 아니면 해당 파드는 로드밸런스에서 제외된다. 두가지 Probe 에 대하여 설정한 대로 노드의 kubelet 이 주기적으로 상태 체크를 하게 되며, 결과가 비정상일 경우 해당 파드는 not ready 상태로 변경된다. 

아래처럼 readiness/liveness probe 를 가진 파드를 생성해 보자.

apiVersion: v1
kind: Pod
metadata:
  name: "healthy-monolith"
  labels:
    app: monolith
spec:
  containers:
    - name: monolith
      image: kelseyhightower/monolith:1.0.0
      ports:
        - name: http
          containerPort: 80
        - name: health
          containerPort: 81
      resources:
        limits:
          cpu: 0.2
          memory: "10Mi"
      livenessProbe:
        httpGet:
          path: /healthz
          port: 81
          scheme: HTTP
        initialDelaySeconds: 5
        periodSeconds: 15
        timeoutSeconds: 5
      readinessProbe:
        httpGet:
          path: /readiness
          port: 81
          scheme: HTTP
        initialDelaySeconds: 5
        timeoutSeconds: 1

각 Liveness/Readiness Probe 에 대해서 체크하는 방법으로는 Command / HTTP / TCP 등이 있는데 위 예제에서는 HTTP 를 사용하였다. livenessProbe 의 경우 http://ip:81/healthz 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. readinessProbe 도 마찬가지로 http://ip:81/readiness 에 접근했을 때 응답코드가 2xx, 3xx 이면 정상이다. initialDelaySeconds 는 컨테이너가 준비되고 probe 를 실행하기 까지의 대기 시간이다. periodSeconds 는 probe 체크를 반복할 시간 설정이다. 

Liveness 테스트

아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 컨테이너의 restart 카운팅이 늘어나며, 컨테이너가 자동으로 재시작 될 것이다.

$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0         29m
 
$ kubectl port-forward healthy-monolith 10081:81
$ curl http://127.0.0.1:10081/healthz/status
$ curl http://127.0.0.1:10081/healthz/status
 
$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0         29m
healthy-monolith   0/1       Running   1         30m
healthy-monolith   1/1       Running   1         30m
healthy-monolith   0/1       Running   2         31m
healthy-monolith   1/1       Running   2         31m

Readiness 테스트

아래와 같이 토글 주소를 반복 실행하여 probe 의 성공과 실패를 반복할 경우 어떤 변화가 생기는지 알아보자. 아마도 실패를 할 경우 해당 파드는 not ready 상태가 되며 로드밸런스에서 제외되는데, 로드밸런스 테스트는 생략한다 ^^;

$ kubectl port-forward healthy-monolith 10081:81
$ curl http://127.0.0.1:10081/readiness/status
$ curl http://127.0.0.1:10081/readiness/status
$ curl http://127.0.0.1:10081/readiness/status
 
$ kubectl get pods healthy-monolith -w
NAME               READY     STATUS    RESTARTS   AGE
healthy-monolith   1/1       Running   0          13m
healthy-monolith   0/1       Running   0          16m
healthy-monolith   1/1       Running   0          17m
healthy-monolith   0/1       Running   0          17m
 
$ kubectl describe pods healthy-monolith
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
 
Events:
  Type    Reason     Age   From                                              Message
  ----    ------     ----  ----                                              -------
  Normal  Scheduled  1m    default-scheduler                                 Successfully assigned default/healthy-monolith to gke-bootcamp-default-pool-bb4d9176-tpk5
  Normal  Pulling    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  pulling image "kelseyhightower/monolith:1.0.0"
  Normal  Pulled     1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Successfully pulled image "kelseyhightower/monolith:1.0.0"
  Normal  Created    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Created container
  Normal  Started    1m    kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Started container
 Warning  Unhealthy  8s (x15 over 2m)  kubelet, gke-bootcamp-default-pool-bb4d9176-tpk5  Readiness probe failed: HTTP probe failed with statuscode: 503