정상상태 점검 패턴

애플리케이션이 쿠버네티스와 정상상태 여부를 통신하는 방법에 관한 패턴입니다.

완전 자동화에 도닥하기 위해서는 쿠버네티스가 클라우드 네이티브 애플리케이션의 실행 여부와 요청 처리 준비 상태 여부를 감지할 수 있어야 하기 때문에 클라우드 네이티브 애플리케이션은 애플리케이션 상태를 유추 가능하도록 잘 관측될 수 있어야합니다.

이런 관측은 파드의 수명주기 관리 및 트래픽이 애플리케이션으로 라우팅되는 방식에 영향을 줍니다.

문제

쿠버네티스는 컨테이너 프로세스 상태를 주기적으로 확인하고 문제가 감지되면 컨테이너를 다시 시작합니다. 하지만 실제에서 프로세스 상태확인은 애플리케이션 정상상태를 결정하기에 충분하지 않습니다.

대부분의 경우 애플리케이션에 행(hang)이 걸리더라도 프로세스는 여전히 실행 중입니다. 이런 상황을 감지하기 위해 쿠버네티스는 애플리케이션의 정상상태(health)를 체크 할 수 있는 신뢰할만한 방법을 필요로 합니다.

즉 애플리케이션이 내부적으로 어떻게 작동하는지를 이해하려는 것이 아니라 애플리케이션이 옛아대로 작동중이며 컨슈머에게 서비스를 제공할 수 있는지 여부를 확인할 방법이 필요한 것입니다.

해결책

프로세스 정상상태 확인

프로세스 정상상태 확인는 kubelet이 컨테이너 프로세스에 대해 지속적으로 수행하는 가장 간단한 정상상태 확인입니다.

컨테이너 프로세스가 실행 중이 아니라면 점검을 다시 시작되고 다른 정상상태 확인을 하지 않더라도 애플리케이션은 이런 일반적인 확인 단계로 좀 더 견고해집니다. 애플리케이션이 모든 종류의 장애를 감지할 수 있고 자기 스스로 종료될 수 있다면 프로세스 정상상태 확인만으로도 충반하지만 대부분의 경우 이것만으로는 충분치 않습니다.

라이브니스 점검

애플리케이션이 교착 상태에 빠지면 프로세스 정상상태 확인으로는 여전히 정상으로 간주됩니다. 이런 종류의 문제와 애플리케이션 비즈니스 로직에 따른 또 다른 형태의 장래를 감지하기 위해 쿠버네티스에는 라이브니스 점검(liveness probe)이 있습니다.

라이브니스 점검이란?

kubelet 에이전트가 정기적으로 검사를 수행해 컨테이너가 여전히 정상상태인지 확인하는 과정입니다. 일부 장애는 애플리케이션 watchdog이 장애 보고를 못할 수 있으므로 애플리케이션 자체 내부보다는 외부에서 정상상태 확인을 수행하는 것이 중요합니다.

장애 조치와 관련해서는 장애가 감지된느 경우 컨테이너가 재시작되기 때문에 이 라이브니스 점검은 프로세스 정상상태 확인과 유사합니다. 그러나 애플리케이션 정상상태 확인 시에 어떤 방법을 쓰는지에 대해 서는 좀 더 밑 항목과 같이 융통성을 부여합니다.

• HTTP 점검은 컨테이너 IP 주소에 대해 HTTP GET 요청을 수행하며 200과 399 사이의 성공적인 HTTP 응답 코드를 기대합니다.
• TCP 소켓 점검은 성공적인 TCP 연결을 가정합니다.
• Exec 점검은 컨테이너 커널 네임스페이스에서 임의의 명령을 실행하고 성공적인 종료 코드(0)를 기대합니다.

HTTP 예제

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-liveness-check
spec:
  containers:
    - name: random-generator
      image: k8spatterns/random-generator:1.0
      env:
        - name: DELAY_STARTUP
          value: "20"
      ports:
        - containerPort: 8080
          protocol: TCP
      livenessProbe:
        httpGet:			# 정상상태 확인 종단점으로 HTTP 점검
          port: 8080
          path: /actuator/health
        initialDelaySeconds: 30		# 애플리케이션에 준비 시간을 주기 위해 첫 번째 라이브니스 점검을 수행하기 전 30초를 기다립니다

애플리케이션의 특성에 따라 가장 적합한 방법을 선택할 수 있습니다. 애플리케이션이 정상상태인지 아닌지 여부를 판별하는 것은 개발자의 구현에 달려있긴하지만 정상상태 확인을 통과하지 못하면 컨테이너가 다시 시작된다는 사실을 생각해야합니다.

컨테이너를 재시작하는 것이 소용없는 경우라면, 근본적인 문제 해결 없이 쿠버네티스 컨테이너를 재시작하므로 정상상태 확인 실패는 아무런 도움이 되지 않습니다.

레디니스 점검

liveness probe는 비정상적인 컨테이너를 죽이고 새로운 컨테이너로 대체함으로써 애플리케이션의 정상상태를 유지하는 데 유용합니다. 그러나 때로는 컨테이너가 정상상태가 아닐 수 있어 재시작하는 것도 도움이 안될 때가 있을 수 있습니다.

컨테이너가 여전히 시작중이고 아직 요청을 처리할 준비가 안됐을 경우나 컨테이너에 과부하가 걸릴 수도있고 지연시간이 증가할 수도 있으며 또 다른 부하로부터 잠시 보호 받길 원할 수도 있습니다.

레드니스 점검(readiness probe) 이란?

레드니스 점검 수행방법은 liveness probe(HTTP ,TCP ,Exec)와 동일하지만 장애 조치는 다릅니다.

readiness probe는 컨테이너를 재시작하지 않으며 레디니스 점검에 실패하면 컨테이너는 Service Endpoint에서 제거되고 새로운 트래픽을 수신할 수 없습니다. 레디니스 점검은 컨테이너가 서비스 요청을 받기 전에 준비할 수 있는 시간을 갖도록 컨테이너가 준비되는 시점에 신호를 보냅니다. 또한 readiness probe는 liveness probe처럼 주기적으로 수행되므로 이후 단계에서 트래픽으로부터 서비스를 보호하는데 유용합니다.

readiness prove 예제

apiVersion: v1
kind: Pod
metadata:
  name: pod-width-readiness-check
spec:
  containers:
    - image: k8spatterns/random-generator:1.0
      name: random-generator
      readinessProbe:
        exec:		# 애플리케이션이 서비스 요청을 처리할 준비가 되었음을 타나내는 파일이 존재하는지 확인힙니다.
          command:	# stat은 파일이 존재하지 않으면 에러를 반환하고 레디니스 점검은 실패합니다.
            - "stat"
            - "/var/run/random-generator-ready"

언제 애플리케이션이 작업을 수행할 준비가 되었는지를 판별하고 언제 애플리케이션을 그대로 둬야 할지를 결정하는 것은 정상상태 확인 코드를 어떻게 구현하는지에 따라 다릅니다. 프로세스 정상상태 확인과 liveness probe은 컨테이너를 재시작해 장애를 복구하기 위한 것이지만 readiness probe는 애플리케이션에 준비할 시간을 주고 애플리케이션이 스스로 복구되기를 기다립니다. SIGTERM 신호를 수신한 후에 쿠버네티스는 readiness probe 통과 여부와 상관없이 컨테이너가 새로운 요청을 받지 못하게 만듭니다.

readiness probe이 있으면 컨테이너에게 시작할 수 있는 시간이 주어집니다. 오직 readiness probe을 통과해야만 디플로이먼트가 성공한 것으로 간주됩니다. 예를 들면 이전 버전의 파드는 롤링 업데이트의 일부분으로서 종료될 수 있습니다.

정리

항목	프로세스 정상상태 확인	liveness probe	readiness probe
점검 방법	kubelet 컨테이너 프로세스 지속적인 점검	- HTTP - TCP - Exce	- HTTP - TCP - Exce
명세방법	기본 제공	똑같음	똑같음
기능	컨테이너 오류시 종료후 재시작	컨테이너 오류시 종료후 재시작	점검에 실패하면 컨테이너는 서비스 엔드포인트에서 제거 새로운 트래픽 수신 차단