[K8s] 쿠버네티스에서의 헬스체크 LivenessProbe, ReadnessProbe

Introduction 

시스템은 관리하기 어려울 수 있다. 가장 큰 이유는 시스템이 작동하려면 모두 작동해야하는 움직이는 부품이 많기 때문이다. 작은 부품이 파손되면 시스템은 이를 감지하고 우회하여 수리해야한다. 그리고 이 모든 작업이 자동으로 수행되어야합니다. 이 글에서는 쿠버네티스에서의 헬스체크 기능인 Readness와 Liveness를 설정하는 방법에 대해서 알아보겠다. 

 

헬스체크는 인스턴스가 작동하는지 여부를 시스템에 알리는 간단한 방법이다. 인스턴스가 작동하지않으면 다른 서비스에서 해당 인스턴스에 엑세스하거나 요청을 보내면 안된다. 대신 나중에 준비되거나 다시 시도되는 앱의 다른 인스턴스로 요청을 보내야한다. 

 

또한 시스템은 앱을 정상 상태로 되돌려야한다. 기본적으로 쿠버네티스는 Pod내의 모든 컨테이너가 시작될 때 pod로 트래픽을 보내기 시작하고 컨테이너가 충돌할 때 컨테이너를 다시 시작한다. 시작할 때 이 기본 동작만으로도 충분할 수 있지만 사용자 지정 상태 확인을 만들어 배포를 더욱 강력하게 만들 수 있다. 다행히도 쿠버네티스는 이를 비교적 간단하게 해주므로 그렇게 하지 않을 이유가 없다. 쿠버네티스는 두가지 유형의 헬스체크 기능을 제공한다. 

 

What is ReadnessProbe ?

- 앱이 트래픽을 처리할 준비가 된 시기를 쿠버네티스에게 알리도록 설계되어있다. 쿠버네티스는 서비스가 Pod에 트래픽을 전송하도록 허용하기 전에 ReadnessProbe가 통과하는지 확인한다. ReadnessProbe가 실패하기 시작하면 쿠버네티스는 다시 통과할 때 까지 Pod로의 트래픽 전송을 중지한다.  

 

What is Liveness Probe ? 

- 쿠버네티스는 LivenessProbe를 통해 Application이 살아있는지 죽었는지 알 수 있다. appication이 살아있으면 kubernetes는 appication을 그대로 둔다. appliction이 종료된 경우 kubernetes는 Pod를 제거하고 이를 교체하기 위해서 새 Pod를 시작한다. 

 

 application이 준비되고 시작되는데 1분정도 걸리는 시나리오를 상상해보자. 프로세스가 이미 시작되었더라도 서비스가 시작되어 실행될 때까지 작동하지 않는다.  여러 replicas(복사본)을 갖도록 이 deployment를 확장하려는 경우에도 문제가 있다. 새 replicas(복사본)는 완전히 준비될 때까지 트래픽을 수신하면 안된다. 

ReadnessProbe

그러나 기본적으로 쿠버네티스는 컨테이너 내부 프로세스가 시작되자마자 트래픽 전송을 시작한다. ReadnessProbe를 사용하면 쿠버네티스는 Service가 새 replicas(복사본)으로 트래픽을 보낼 수 있도록 허용하기 전에 Application이 완전히 시작될 때까지 기다린다. 극단적인 경우 Deadlock(교착상태)가 발생하여 Application이 무기한 중단되어 요청 처리가 중단되는 다른 시나리오를 상상해보자. 

LivenessProbe

프로세스가 계속 실행되기 때문에 기본적으로 쿠버네티스는 모든 것이 정상이라고 생각하고 손상된 Pod에 요청을 계속 보낸다.

쿠버네티스는 LivenessProbe를 사용하여 Application이 더 이상 요청을 처리하지 않는 것을 감지하고 기본적으로 문제가 있는 Pod를 다시 시작한다. 

 

다음은 ReadnessProbe와  LivenessProbe를 테스트할 Probe에 대해 알아보자. 

 

 

 

 

Probe의 3가지 유형

 

LivenessProbe 및 ReadnessProbe 확인을 위해 이들 중 하나를 사용할 수 있다. 

 

1. HTTP Probes

HTTP Probe는 아마도 가장 일반적인 유형의 사용자 지정 Probe이다. Application이 HTTP 서버가 아니더라도 일반적으로 Application 내부에 경량 HTTP 서버를 생성하여 Liveness에 응답할 수 있다. 그리고 200또는 300 범위의 HTTP 응답을 받으면 정상으로 표시된다. 그렇지 않으면 비정상으로 표시된다. 

 

2. Command Probes 

Command Probes의 경우 쿠버네티스는 컨테이너 내에서 명령을 실행한다. 명령이 종료코드 0으로 반환되면 컨테이너는 정상으로 표시된다. 그렇지 않으면 비정상으로 표시된다. 이 유형의 Probe는 HTTP Server를 실행할 수 없거나 실행하고 싶지 않을 때 유용하지만 Application이 정상인지 확인할 수 있는 명령을 실행할 수 있다. 

 

3. TCP Probe 

쿠버네티스는 저장된 Port에서 TCP 연결 설정을 시도한다. 연결을 설정할 수 있으면 컨테이너는 정상으로 간주된다. 그렇지 못한 경우에는 실패로 간주된다. 이제 HTTP Probe또는 Command Probe가 제대로 작동하지 않는 시나리오가 있는 경우 이러한 기능이 유용할 수 있다. 예를 들오 gRPC 또는 FTP 서비스는 이러한 유형 Probe에 대한 주요 후보가 된다. 

 

 

Probe 구성 방법

Probes는 다양한 방법으로 구성할 수 있다. 실행 빈도, 성공 및 실패 Limit 값, 응답 대기 시간을 지정할 수 있다. Liveness를 사용할 때 구성해야하는 매우 중요한 설정이 하나 있다. 

- initialDelaySeconds (초기 지연 설정 ) 

    - Liveness가 실패하면 Pod가 시작된다. application이 준비될 때까지 Probe가 시작되지 않는지 확인해야한다. 그렇지 않으면 Application이 loof에서 지속적으로 다시 시작되며 결코 준비되지 않는다. 시간을 초기 지연 시간(초)으로 사용하거나 평균 시작 시간을 사용하여 Buffer를 추가하는 것이 좋다. Application 시작 시간이 빨라지거나 느려지면 시간에 대한 설정을 업데이트 해야한다. 

- periodSeconds

- timeoutSeconds

- sucessThreshold 

- failureThreshold