Kubernetes :: Iiveness probe 정리

해당 내용은 공식문서와 쿠버네티스 인 액션을 참고하였습니다.

 

 

LivenessProbe

-  Kubernets에서 제공하는 컨테이너 헬스체크 방식 중 한가지

-  LivenessProbe를 사용하면 컨터이너가 서비스를 시작할 수 있는지 판별할 수 있다.

-  즉, 외부로부터 Request를 요청받을 수 있는 상태인지 판별

-  같이 쓰이는 헬스체크 방식 중 ReadinessProbe도 있다. 해당 속성을 사용하면 서비스가 계속 유지되고 있는지 체크할 수 있다.

 

 

 

예제로 사용한 Deployment 매니페스트 파일은 아래와 같다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-depolyment
  labels:
    app: test-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test-api
  template:
    metadata:
      labels:
        app: test-api
    spec:
      containers:
        - name: test-api-container
          image: test-repository-url
          imagePullPolicy: Always
          ports:
            - name: api
              containerPort: 8080
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /api/v1/health/hello
              port: api
            initialDelaySeconds: 60
            periodSeconds: 10

 

매니페스트를 위와 같이 작성 후 실행 시킨다음 Describe 명령어로 생성된 파드 조회 시 아래와 같이 확인할 수 있다.

 

 

위 그림을 살펴보면 코드로 설정한 값 이외에 success, failure에 대한 값이 추가로 들어가 있는 것을 확인할 수 있다.

 

sucess 값은 sucessThreshold 속성을 나타내며 디폴트 값은 1이다.

해당 속성은 Liveness 상태 체크 시 sucess 상태로 간주하는데 필요한 연속된 카운터 수이다.

 

failure 값은 failureThreshold 속성을 나타내며 디폴트 값은 3이다.

해당 속성은 Liveness 상태 체크 시 failure 상태로 간주하는데 필요한 연속된 카운터 수이다. (최소 값은 1)

 

 

이제 매니페스트 파일에서 설정한 설정 값들을 살펴보자.

 

먼저 가장 하단에 있는 initalDelaySeconds 와 periodSeconds 속성을 살펴보자.

 

initalDelaySeconds 속성은 애플리케이션 실행 시, 요청을 받기 위해 대기 해야하는 시간을 정의하는 부분이다.

스프링부트 프레임 워크를 예로 설명하면, 해당 프레임워크는 빌드 시간이 오래걸리기 때문에 설정 값을 1분으로 설정하였다.

 

그 다음으로 periodSeconds 속성은 retry하는 주기를 나타낸다. 

예를들어 periodSeconds 속성을 10으로 주면 헬스체크가 fail이 뜨면 10초간 대기 후 다시 시도한다.

 

 

 

이제 livenessProbe를 사용하는 방법에 대하여 좀 더 자세하게 살펴보자

위 Deployment 매니페스트 파일 중 livenessProbe를 정의한 부분만 살펴보면 아래 코드와 같다.

livenessProbe:
  httpGet:
    path: /api/v1/health/hello
    port: api
  initialDelaySeconds: 60
  periodSeconds: 10

 

위 코드는 livenessProbe를 사용하는 3가지 방법 중 HTTP GET 프로브를 사용하였다.

해당 글에서는 HTTP GET과 Command 프로브에 대하서 설명하려고 한다.

 

livenessProbe 속성에 관한 자세한 내용은 공식문서를 참고 바란다. 좀더 자세한 내용은 RedHat Docs가 좋았었다.

 

먼저 HTTP GET 프로브를 사용하기 위해서는 어플리케이션에 헬스체크를 위한 엔드포인트가 있어야한다.

예제에서는 /api/v1/health/hello로 헬스체크를 하도록 설정하였다. 

 

어플리케이션에서는 아래와 같은 코드가 미리 작성되어 있어야 한다. 

해당 코드는 스프링부트 프레임워크와 코틀린으로 작성하였다.

@RestController
@RequestMapping("/api/v1/health", produces = ["application/json"])
class HealthCheckRestController {

    @GetMapping("hello")
    fun hello(
    ): ResponseEntity<Any> {
        return ResponseEntity.ok("ok")
    }
}

 

 

이제 Command 프로브에 대해서 살펴보자. 해당 프로브 사용 시 아래와 같이 작성할 수 있다.

livenessProbe:
  exec:
    command:
      - cat
      - /tmp/healthy
  initialDelaySeconds: 1
  periodSeconds: 10

 

HTTP GET과의 차이점은 HTTP GET은 설정된 엔드포인트로 Request 요청 시 반환되는 Status 값에 의해서 성공 실패를 나누지만,

Command 프로브는 컨테이너 내에서 설정된 명령어를 실행하고 상태코드가 0일때 성공으로 간주한다.

 

따라서 Command 프로브를 사용하기 위해서는 헬스체크를 위한 커맨드가 미리 정의되어 있어야한다.

 

컨맨드 정의는 아래 도커 파일 생성 시 정의할 수 있다.

FROM java:8

EXPOSE 8080

ARG JAR_FILE=build/libs/rest-exam-0.0.1.jar

ADD ${JAR_FILE} rest-exam.jar

RUN touch /tmp/healthy

ENTRYPOINT ["java","-jar", "/rest-exam.jar"]

 

위 코드 중 RUN touch /tmp/healthy 명령어가 헬스체크를 위한 커맨드를 정의하는 부분이고 해당 커맨드를 매니페스트에 작성해주면 된다.