3. 쿠버네티스에서 애플리케이션을 동작시키는 구조 - 5

3.5 파드를 안전하게 외부로 공개하기 위한 헬스 체크

서비스를 통해 파드가 공개되면서 요청에 대해 정상적으로 응답하지 못하는 에러가 발생할 수 있다. 여기서는 이러한 경우를 방지하기 위한 두 가지 헬스 체크에대해 설명한다.

 

3.5.1 Readiness Probe로 파드와 연결된 서비스 모니터링하기

Readiness Probe는 애플리케이션이 공개 가능한지의 여부를 확인하고 정상이라고 판단된 경우 처음으로 서비스를 통해 트래픽을 수신한다. 예를 들어 헬스체크용 응답 페이지를 생성해두고, 해당 페이지에 접속해 상태 코드가 200으로 돌아오면 서비스를 통해 접속하는 방법을 사용할 수 있다.

예제 애플리케이션의 디플로이먼트용 매니페스트인 22_deployment_backend-app_k8s.yaml.template에는 아래와 같이 ‘/heath’ 경로에 정상 응답을 받을 경우에만 요청을 받는다고 설정했다.

...
readinessProbe:
  httpGet:
    port: 8080 # 8080 포트에 접속한다.
    path: /health
  initialDelaySeconds: 15
  periodSeconds: 30 # 30초 간격으로.

Readiness Probe가 실패하면 파드 상태가 비정상으로 판단되어 Ready 상태가 되지 않으며, 서비스에서 트래픽을 보내지 않는다.

 

3.5.2 Liveness Probe로 파드 상태 모니터링

Liveness Probe는 실행 중인 파드가 정상적으로 동작하는지 모니터링한다. 예제 애플리케이션의 디플로이먼트용 매니페스트인 22_deployment_backend-app_k8s.yaml.template에 다음과 같이 정의되어 있다.

...
livenessProbe:
  httpGet:
    port: 8080
    path: /health
  initialDelaySeconds: 30
  periodSeconds: 30

Liveness Probe가 실패하면 파드는 재시작을 시도한다. 또한, 파드 이벤트에 그 내용이 출력되고 재시작 횟수를 센다.

 

3.5.2.1 초기화 처리에 걸리는 시간 고려

Readiness Probe는 파드 상태가 비정상으로 판단될 경우 서비스에서 트래픽이 전달되지 않는다. 하지만 Liveness Probe에는 헬스 체크에 실패하면 파드가 재시작된다. 따라서 Liveness Probe 실행은 Readiness Probe가 성공한 후(정상 응답을 받은 경우)에 하지 않으면 파드의 재시작 루프에 빠질 가능성이 있다.

 

이를 방지하기 위해 초기화 지연(Inital Delay) 설정으로 파드가 동작한 후 첫 번째 헬스 체크를 시작하기 까지 유예 시간을 설정할 수 있다. 애플리케이션 동작에 필요한 시간을 항상 의식하면서 이 값을 반드시 설정해야 한다. 때문에 예제 애플리케이션의 디플로이먼트용 매니페스트인 22_deployment_backend-app_k8s.yaml.template에 초기화 지연이 다음과 같이 설정되어 있다.

...
readinessProbe:
  httpGet:
    port: 8080 
    path: /health
  initialDelaySeconds: 15 # 파드 시작 15초 후 부터 Readiness Probe 시작
  periodSeconds: 30 
livenessProbe:
  httpGet:
    port: 8080
    path: /health
  initialDelaySeconds: 30 # 파드 시작 30초 후 부터 Readiness Probe 시작
  periodSeconds: 30