startup probe (w. liveness, readiness)

startup probe 는 컨테이너의 애플리케이션이 실행되었는지를 확인한다.

startup probe 가 성공해야 readiness (준비성), liveness (활성) probe 가 실행된다.

startup probe 설정이 없는 경우 기본 success 상태이다.

참고로 readiness, liveness probe 는 동시에 실행되며, period seconds 설정대로 앱이 살아있는 동안 계속 실행된다.
반면, startup probe 는 앱 실행 시점 초기에만 실행된다.

경우에 따라 느리게 시작하는 애플리케이션에는 liveness probe (활성 프로브) 를 추가하면 컨테이너가 실행되지 못하고 계속 죽는 경우가 발생할 수 있다.

또는 만약 초당 수백, 천, 만 단위의 트래픽을 받는 서비스를 운영중이라면 readiness, liveness probe 설정만 했다면, 배포 시 초기 응답들은 다수 실패하는 경우를 보았을 것이다.

startup probe 를 이용해서 웜업을 하도록 처리하면 초기 트래픽도 정상적으로 처리 가능하다.

(ex. startup probe 가 호출하는 경로(ex. api) 내의 로직에서 실제 초당 트래픽 받는 만큼 반복해서 처리하도록 처리.)

startup probe 의 설정을 아래와 같이 하면, startup probe 는 (30 * 10 = 300s) 5분이라는 시간을 갖게된다.

(5분 동안은 startup probe 가 성공할때까지 기다린다.)

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

startup probe 가 성공하고 나면, liveness 와 readiness probe 에게 체크를 인계하게 된다.

만약, startup probe 가 실패하게 되면 해당 파드는 제거된다.

probe 설정에는 다음과 같은 필드가 있다.

initailDelaySeconds : 컨테이너가 실행된 후에 startup, liveness, readiness probe 가 실행되는 시간을 지연(대기). 디폴트 및 최소 설정 값은 0으로 설정하지 않으면 컨테이너 실행 후 바로 probe 가 실행된다.
periodSeconds : probe 를 수행하는 빈도(초)를 나타낸다. 디폴트 값은 10초 (최소 설정가능 값은 1). 즉, 설정하지 않으면 probe 는 10초 마다 실행된다. (timeoutSeconds 필드 설정 값보다 커야함)
timeoutSeconds : 해당 시간 내에 probe 응답을 받지 못하면 실패로 간주한다. 디폴트 값은 1초 (최소 설정 가능 값은 1). 즉, 1초내에 probe 에 설정한 응답을 받지 못하면 실패.
successThreshold : probe 가 성공한것으로 간주하는 연속 횟수. 디폴트 값은 1 (최소 설정가능 값은 1). 즉, 1번이라도 성공하면 컨테이너/파드가 준비된것으로 간주한다.
failureThreshold : 해당 필드에 설정된 수 만큼 실패하면 컨테이너를 재실행한다. 디폴트 값은 3 (최소 설정가능 값은 1). 즉, 3번 실패하면 파드 재실행.

편법이지만 liveness, readiness probe 를 아래와 같이 활용해볼 수 있지 않을까 생각한다.

liveness, readiness probe 중 하나로 웜업용 경로를 호출하도록 한 뒤, (내부에서는 초당 트래픽을 받는만큼 반복문으로 처리하도록 진행) 완료되면 완료되었다는 플래그로 static 변수에 success, true 와 같은 값을 저장한다.

그럼 그 다음 probe 의 요청들은 이미 성공했으니 로직을 실행하지 않을것이다.

이렇게 하는 경우 liveness probe 나 readiness probe 중 하나의 기능을 웜업용으로 사용해야 하기는 하지만, 대량의 트래픽을 받는 서비스에서 매번 배포 시 수백건의 요청 트래픽이 실패하는것보다는 나을것이다.

참고

MoonStorage