소개

지난번은 Liveness Probe의 동작을 확인했으므로 이번에는 Readiness Probe의 동작을 확인하고 싶습니다.

Liveness Probe와 Readiness Probe의 차이, 헬스 체크 방식, 간격은 전회의 내용을 참조해 주시면 좋겠습니다.

[Kubernetes] Liveness Probe의 동작 확인

동작 확인

포드가 두 개 있으면 Readiness Probe 검사가 성공하면 LoadBalancer에서 트래픽이 밸런싱됩니다. (이하 그림 왼쪽)
체크에 걸리면 LoadBalancer로부터의 트래픽이 흐르지 않도록 제어됩니다. (아래 그림 오른쪽)
이때 Readiness Probe는 Liveness Probe와 달리 Pod를 다시 시작하지 않습니다.



이 동작을 실제로 확인하고 싶습니다.

exec

서비스, ​​Pod 배포

먼저 LoadBalancer와 Readiness Probe를 설정하지 않은 Pod를 배포합니다.

lb.yaml

apiVersion: v1
kind: Service
metadata:
  name: load-balancer
spec:
  ports:
  - name: load-balancer
    port: 8080
    protocol: TCP
    targetPort: 80
    nodePort: 30002
  selector:
    app: app1
  type: LoadBalancer

nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: app1
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

$ kubectl apply -f lb.yaml
service/load-balancer created
$ kubectl apply -f nginx.yaml
pod/nginx created

그런 다음 Readiness Probe를 설정한 Pod를 배포합니다.
이번에는 worker 노드의/test를 hostPath로/check에 마운트하고, 부하의 testfile이 존재하는지 체크 대상으로 하고 있습니다.
또한 검사 대상인 testfile은 각 worker 노드에 미리 작성되어 있습니다.

readiness-exec.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: app1
  name: nginx-readiness
spec:
  containers:
  - name: nginx-readiness
    image: nginx:latest
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /check
      name: check-vol
    readinessProbe:
      exec:
        command:
        - cat
        - /check/testfile
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 1
  volumes:
  - name: check-vol
    hostPath:
      path: /test
      type: Directory

$ kubectl apply -f readiness-exec.yaml
pod/nginx-readiness created

외부에서 액세스를 확인하고 싶기 때문에 각 컨테이너의 index.html에 호스트 이름을 쓰고 어느 쪽으로 밸런싱되는지 알 수 있습니다.

$ kubectl exec -it nginx /bin/bash
root@nginx:/# echo `hostname` > /usr/share/nginx/html/index.html
root@nginx:/# cat /usr/share/nginx/html/index.html
nginx

또 다른 포드도 비슷한 절차로 호스트 이름을 나열합니다.

동작 확인

외부에서 LoadBalancer에 5초 간격으로 액세스합니다.

[client]$ while true; do  curl -s http://10.20.30.150:8080 ;sleep 5; done
nginx-readiness
nginx
nginx-readiness
nginx
nginx-readiness
nginx
nginx-readiness
nginx

이 때는 두 개의 포드로 밸런싱됩니다.

포드가 배포된 노드를 검토하고 작업자 노드에서 testfile을 제거해 봅니다.

$ kubectl get pod -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
nginx             1/1     Running   0          11m     192.168.79.99    k8s-worker01   <none>           <none>
nginx-readiness   1/1     Running   0          7m35s   192.168.69.247   k8s-worker02   <none>           <none>
$ ssh k8s-worker02
[worker02]$ sudo rm /test/testfile

그러면 'nginx'에만 밸런싱되어 있음을 알 수 있습니다.

[client]$ while true; do  curl -s http://10.20.30.150:8080 ;sleep 5; done
nginx-readiness
nginx
nginx-readiness
nginx
・・・　# Readiness Probeが失敗↓
nginx
nginx
nginx
nginx
nginx
nginx
nginx
nginx
nginx

testfile을 실행 취소합니다.

[worker02]$ sudo touch /test/testfile

다시 두 포드로 균형을 잡을 것입니다.

[client]$ while true; do  curl -s http://10.20.30.150:8080 ;sleep 5; done
nginx-readiness
nginx
nginx-readiness
nginx
・・・　# Readiness Probeが失敗↓
nginx
nginx
nginx
nginx
nginx
nginx
・・・　# Readiness Probeが再び成功↓
nginx-readiness
nginx
nginx-readiness
nginx
nginx-readiness
nginx

이러한 포드의 상태 변화를 확인하면 다음과 같습니다.

$ kubectl get pod -w
NAME              READY   STATUS    RESTARTS   AGE
nginx             1/1     Running   0          4m56s
nginx-readiness   1/1     Running   0          36s
nginx-readiness   0/1     Running   0          7m58s #testfileを削除し、Readiness Probeが失敗する
nginx-readiness   1/1     Running   0          9m58s #testfileを復元し、Readiness Probeが成功する

Pod는 READY 상태가 아니게 되는 것만으로, 재기동은 하고 있지 않는 것을 알 수 있군요.

httpGet/tcpSocket

httpGet과 tcpSocket의 경우,

설정 방법은 Liveness Probe 매니페스트의 "livenessProbe"를 "readinessProbe"로 변경

동작은 Readiness Probe의 exec뿐만 아니라

그러므로, 자세한 것은 할애합니다.

요약

전회와 이번에 Pod의 헬스 체크 기구인 「Liveness Probe」와 「Readiness Probe」의 동작을 확인했습니다. 둘 다 설정 자체는 그리 어렵지 않지만 요구 사항에 따라 무엇을 어떻게 확인할지 설계하는 것이 어려울 것 같네요.

또, Liveness Probe와 Readiness Probe는, 양쪽 모두 동시에 설정할 수 있기 때문에, 시스템의 기동시와 동작중의 체크를 나누어 생각할 필요가 있군요.