[Kubernetes] LivenessProbe 개요 및 테스트 시 유의점

LivenessProbe란?

LivenessProbe는 명칭 그대로 컨테이너의 생명(liveness)를 진단(probe)하는 것으로,

k8s의 주요 특성 중 하나인 Self-healing을 구현해주는 기능입니다.

kubernetes.io에서 제시하는 self-healing의 정의는 아래와 같은데요.

출처: kubernetes.io

즉, 실행 중이던 컨테이너에 문제가 생겼을 때 이를 시스템적으로 복구해주는 것을 말합니다.

LivenessProbe는 컨테이너 구동 후 최초 '한번은' 성공해야 한다

시나리오

아래 yaml의 가장 하단을 보면, 컨테이너를 실행 후 /tmp/healthy라는 파일을 생성하고 30초 후에 sleep 후 해당 파일을 삭제합니다.

/tmp/healthy 파일이 존재할 경우를 정상으로 보고, 모종의 이유로 해당 파일이 삭제되는 상황을 가정한 것입니다.

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: busybox
  name: busybox-pod
spec:
  containers:
  - name: busybox-container
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

 

 

문제 발생

여기에 livenessProbe을 아래와 같이 설정해보겠습니다.

livenessProbe:
  exec:
   command:
   - ls
   - /tmp/healthy

 

언뜻 보면 문제가 없어보이지만, 이렇게 실행 시 back-off 상태에 빠지게 됩니다.

다시 말해, 컨테이너가 실패 상태에서 재시작 대기(back-off) 중인 것입니다.

문제 이유

이유는 컨테이너 구동 후 최초 livenessProbe가 실패했기 때문입니다.

실패했을 때를 대비해서 작성한 스크립트인데 실패한 게 뭐가 문제가 되나 할 수 있습니다. 하지만 최초 '한번은' 조건에 따라 성공해야 한다는 조건이 있습니다.

 

livenessProbe는 컨테이너를 살리는 메커니즘입니다. 만약 컨테이너가 정상적으로 실행 중임에도 첫 번째 probe가 실패하면, Kubernetes는 이를 비정상 상태로 판단하여 불필요한 재시작을 유발합니다.

 

따로 옵션을 설정하지 않았을 때 livenessProbe가 동작하는 시점은 컨테이너 실행 직후(0s)입니다. 따라서 채 /tmp/healthy 파일이 생성되기도 전에 probe를 진행할 경우 실패할 가능성이 있는 것이죠. 

 

참고) livenessProbe 하위의 변수들의 기본값은 아래와 같습니다.

변수	기본값	설명
initialDelaySeconds	0초	컨테이너 시작 후 프로브를 시작하기 전 대기 시간
periodSeconds	10초	프로브를 실행하는 주기
timeoutSeconds	1초	프로브가 타임아웃으로 실패하기 전 대기 시간
failureThreshold	3번	실패를 허용하는 최대 횟수. 이를 초과하면 재시작
successThreshold	1번	공 판정을 위한 최소 연속 성공 횟수 (주로 readinessProbe에서 사용)

 

해결법

initialDelaySeconds 옵션을 상황에 맞게 수정해줍니다. 예를 들어, 10 정도의 값으로 설정하여 컨테이너 실행 후 여유시간을 둔 뒤 probe가 동작하도록 한다면 최초 probe의 실패를 방지할 수 있을 것입니다.

livenessProbe:
  exec:
    command:
    - ls
    - /tmp/healthy
  initialDelaySeconds: 10