라이브니스 프로브 (Liveness Probe)

쿠버네티스는 라이브니스 프로브 (Liveness probe)를 통해 컨테이너가 아직 살아 있는지 확인 할 수 있다.

포드의 사양에서 각 컨테이너에 라이브니스 프로브를 지정할 수 있다.

 

쿠버네티스는 세 가지 메커니즘 중 하나를 사용해 컨테이너를 검색한다.

 

- [HTTP GET 프로브]는 지정한 IP 주소, 포트, 경로에 HTTP GET 요청을 수행한다.

   ㅁ 프로브가 응답을 수신하고 응답코드가 오류를 나타내지 않으면(즉, HTTP 응답코드가 2xx 또는 3xx 인 경우) 프로브는 성공한 것으로 간주

   ㅁ 서버가 오류 응답 코드를 리턴하거나 응답하지 않으면 프로브는 실패로 간주하고 결과적으로 컨테이너를 다시 시작

- [TCP 소켓 프로브]가 컨테이너의 지정된 포트에 TCP 연결을 열려고 시도. 성공적으로 연결되면 프로브가 성공, 그렇지 않으면 컨테이너가 다시 시작 됨

- [Exec 프로브]는 컨테이너 내부에 임의의 명령을 실행하고 명령의 종료 상태 코드를 확인. 상태 코드가 0이면 검사가 성공적, 다른 모든 코드는 오류로 간주.

 

1. HTTP 기반 라이브니스 프로브 생성

 

 Node.js 애플리케이션을 위한 라이브니스 프로브 추가 

 웹 애플리케이션이기 때문에 웹 서버가 요청을 처리하는지 여부를 확인할 라이브니스 프로브를 추가

 

 ㅁ 포드에 라이브니스 프로브 추가: kube-liveness-probe.yml

apiVersion: v1
kind: pod
metadata:
    name: kubia-liveness
spec:
    containers:
    - image: luksa/kubia-unhealthy       # 이것은 다소 문제가 있는 애플리케이션이 포함하는 이미지
      name: kubia
      livenessProbe:                               # HTTP GET을 수행할 라이브니스 프로브
         httpGet:
             path: /                                     # 네트워크 포트 HTTP 요청에서 요청할 경로
             port: 8080                             # 프로브가 연결해야 하는 네트워크 포트

 

 ㅇ 포드 디스크립터는 httpGet 라이브니스 프로브를 정의한다.

 ㅇ 이 프로보는 쿠버네티스에게 컨테이너가 여전히 정상 동작하는지 체크하기 위해 경로/포트 8080에서 HTTP Get 요청을 주기적으로 수행하도록 알려준다.

 ㅇ 이런 요청은 컨테이너가 실행되는 즉시 시작

 ㅇ 이런 요청이   다섯번 발생하면 쿠버네티스가 프로브 오류로 간주해 컨테이너를 다시 시작하도록 애플리케이션이 HTTP 상태 코드 500을 반환하기 시작한다.

 

[ 동작중인 라이브니스 프로브 보기 ]

 

$ kubectl get po kubia-liveness

NAME                  READY      STATUS       RESTARTS     AGE

kubia-livenss       1/1             Running       1                    2m

 

RESTARTS 열은 포드의 컨테이너가 한 번 다시 시작됐음을 나타낸다.

 

[비정상적 컨테이너 애플리케이션 로그 얻기]

 

컨테이너를 다시 시작하면 kubectl logs 명령에 현재 컨테이너의 로그가 표시

이전 컨테이너가 종료된 이유를 파악하려면 현재 컨테이너의 해당 로그를 확인해야 함. 이것은 --previous 옵션을 사용해 수행 가능

$ kubectl logs mypod --previous

 

ㅁ 컨테이너를 다시 시작한 후 포드의 디스크립션

 

$ kubectl describe po. kubia-liveness

Name:                          kubia-liveness
...
Containers:
    kubia:
         Container ID:           docker://480986f8
         Image:                     luksa/kubia-unhealthy
         Image ID:                 coker://sha256:26208508
         Port:
         State:                       Running                                                  # 컨테이너가 실행 중
              Started:               Sun, 14 May 2018 11:41:40 +0200
         Last State:                Terminated                                             # 이전 컨테이너가 에러코드 137번으로 중지됐다.
              Reason:                Error
              Exit Code:            137
              Started:                Mon, 01 Jan 0001 00:00:00 +0000
              Finished:              Sun, 14 May 2018 11:41:38 +0200
         Ready:                       True
         Restart Count:           1
         Liveness:                   http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3
         ....

 

 

[참고]

 

컨테이너가 강제 종료되면 완전히 새로운 컨테이너가 생성된다. 컨테이너가 재시작되는 것이 아니다.

 

[라이브니스 프로브의 추가 속성 구성]

 

kubectl describe가 라이브니스 프로브의 추가 정보를 표시 한다.

 

         Liveness:                   http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3

 

명시적으로 지정한 라이브니스 프로브 옵션 외에도 지연, 시간 초과, 기간 등과 같은 추가 속성을 볼 수 있다.

delay=0s 부분은 컨테이너가 시작된 직후 프로브가 시작됨을 나타냄

타임아웃(timeout)은 1초로 설정되므로 컨테이너가 1초 내에 응답을 반환해야 하며 그렇지 않으면 프로브가 실패로 간주한다.

 

다음은 라이브니스 프로브에 initialDealySeconds 속성을 추가하여 초기 지연을 설정한다.

 

ㅁ 초기 지연되는 라이브니스 프로브

livenessProbe:
    httpGet:
        path: /
        port?: 8080
    initialDelaySeconds: 15     # 첫번째 프로브 실행 전 15초 지연

 

- 초기 지연을 설정하지 않으면 프로브가 시작되는 즉시 컨테이너를 프로브하기 시작한다.

- 애플리케이션이 요청을 받을 준비가 되지 않았기 때문에 일반적으로 프로브가 실패한다.

- 실패 횟수가 실패 임계 값을 초과하면 요청에 올바르게 응답하기 전에 컨테이너가 다시 시작한다.

 

[효과적인 라이브니스 프로브 생성]

 

ㅁ 라이브니스 프로브가 확인해야 할 것

 

- 일반적으로 라이브니스 프로브는 단순히 서버가 응답하는지 검사하지만 더 나은 라이브니스 프로브를 위해 특정 URL 경로(예: /health)를 요청해 애플리케이션에서 실행 중인 중요한 구성 요소의 내부 상태가 죽었거나 반응이 없는 상태를 확인하도록 프로브를 구성한다.

  --> 팁: /health HTTP 엔드포인트가 인증을 필요로 하지 않는지 확인해야 한다. 그렇지 않으면 프로브가 항상 실패하여 컨테이너가 무한정 다시 시작된다.

 

- 애플리케이션 내부만 체크하고 외부 요소의 영향을 받지 않도록 하라 (예를 들어 프론트엔드 웹 서버의 라이브니스 프로브는 서버가 백엔드 데이터베이스에 연결할 수 없을 때 실패를 반환해서는 안된다. 기본 원인이 데이터 베이스 자체에 있는 경우 웹 서버 컨테이너를 다시 시작해도 문제가 해결되지 않는다.)