Kubernetes Readiness Probe / 쿠버네티스 healthcheck, pod ready state

Kubernetes Readiness Probe

---

앞서 Ingress에 대해서 정리할때 Pod는 서비스에서 endpoints들로 관리된다고 정리한 적이 있음

(참고) 2022.12.25 - [개발/개발공부] - Kubernetes Ingress / 쿠버네티스 인그레스 정리

Kubernetes Ingress / 쿠버네티스 인그레스 정리

하지만 Pod가 새로 생성됐을 때 requests를 받을 준비가 되어있지 않은 상태라면?

Pod가 요청 받을 준비가 되었다는 것을 확인해주는 것이 Readiness probe

Readiness probe를 확인하는 방식이 여러가지가 있는데

  - Exec probe

        process의 exit status code에 따른 상태

        컨테이너 내 지정된 명령어를 실행하는 것

  - HTTP GET probe

        HTTP 요청을 보낸 후 받은 status code에 따른 상태

        아시다시피 400에러 외 200과 같은 success의 응답이 오면 성공

  - TCP Socket probe

        TCP connection 결과에 따른 상태

        지정된 포트로 컨테이너와 TCP 검사, 포트가 활성화되어있으면 성공

 

#readiness probe options in use

        readinessProbe: #exec probe 사용 중
          exec:
            command:
            - /~~/~~/~~/~~/healthcheck.sh
          failureThreshold: 5 #실패 threshold
          initialDelaySeconds: 60 #최초 delay 시간
          periodSeconds: 10 #몇초 주기로 readiness probe 체크할지
          successThreshold: 1 #성공 threshold
          timeoutSeconds: 5 #요청 timeout 제한

 

간단하게 주석을 달아놨는데, 옵션들의 이름이 명확하게 되어있어서 이해하기가 쉽습니다.

개인적인 경험으로는 Exec probe 위주로 많이 보였던 것 같습니다. 나중에 다른 방식도 찾아봐야겠습니다...

각각의 장단점이 있는 것 같은데, Exec probe를 사용할때는 Disk I/O에 따라 readiness probe가 영향을 받았었습니다.

Readiness Probe 동작 구조

Readiness probe 동작 구조에서 볼 수 있다시피, Readiness probe가 실패하면 Service Endpoints에서 해당 Pod를 제거

이러한 방법을 통해 사용자는 정상적인 Pod와만 통신을 함으로, 시스템의 문제와 별개로 서비스를 이용할 수 있음

Pod가 죽으면 어차피 서비스에서 제외가 되기 때문에, 해당 상황에 대한 처리는 할 필요가 없음