쿠버네티스 패턴 4장. 정상 상태 점검

쿠버네티스 패턴 4장. 정상 상태 점검

• 정상 상태 점검(health probe pattern) 은 애플리케이션이 쿠버네티스와 정상상태 여부를 통신하는 방법에 관한 패턴이다.
  • 쿠버네티스가 클라우드 네이티브 애플리케이션의 실행여부와 , 요청 처리 준비 상태 여부를 감지할 수 있어야함.
  • 클라우드 네이티브 애프리케이션은 애플리케이션 상태를 유추 가능하도록 잘 관측될 수 있어야함.
• 이러한 관측은 파드의 수명주기 관리 및 트래픽이 애플리케이션으로 라우팅되는 방식에 영향을 준다.

문제

• 애플리케이션이 예상대로 작동중이며, 컨슈머에게 서비스를 제공할 수 있는 지 여부를 확인할 방법이 필요하다.
  • 이상: 쿠버네티스는 컨테이너 프로세스의 상태를 주기적으로 확인하고, 문제가 감지되면, 컨테이너를 다시 시작한다.
  • 현실:
    • ( JVM 의 OOME(OutOfMemoryError) / 무한루프 교착상태, 스레싱(thrashing: 가상메모리 자원을 오버해서 사용해 일어나는 현상 ) 등으로 인해 ) 애플리케이션이 hang 에 걸리더라도 프로세스는 여전히 실행중이다.
    • 이런 상황을 감지하기 위해 쿠버네티스는 정상상태(health)를 체크할 수 있는 신뢰할만한 방법이 필요하다.

해결

• 사실 버그 없는 코드를 작성하는 것은 불가능하다.
• 결국 장애에 대한 세간의 관심은 장애를 피하는 것 에서 오류를 감지하고 복구하는 쪽으로 이동했다.
• 수많은 유형의 장애별로 알맞은 장애 조치가 필요하다.
  • 일시적인 장애는 충분한 시간이 주어지면 자체 복구
  • 애플리케이션 재시작이 필요한 장애..
• 쿠버네티스가 장애를 감지하고 해결하는데 쓰이는 여러가지 확인 단계를 살펴보자.

프로세스 정상상태 확인(process health check)

• 프로세스 정상상태 확인은 큐블릿(kubelet)이 컨테이너 프로세스에 대해 지속적으로 수행하는 가장 간단한 정상상태 확인이다.
• 컨테이너 프로세스가 실행 중이 아니라면, 점검 (probing) 은 다시 시작된다.

라이브니스 점검(Liveness Probe)= 생존상태점검

• 애플리케이션 비즈니스 로직에 따른 또 다른 형태의 장애를 감지 하기 위한 점검
  • 예. 애플리케이션이 교착상태의 빠짐 = 프로세스 health check 로는 정상으로 간주되지만 에러인 경우
• 라이브니스 점검이란 큐블릿 에이전트가 정기적으로 검사를 수행해 컨테이너가 여전히 정상상태인지를 확인하는 과정이다.
• 일부 장애는 애플리케이션 워치독(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:
    - image: k8spatterns/random-generator:1.0
      name: random-generator
      env:
      - name: DELAY_STARTUP
        value: "20"
      ports:
      - containerPort: 8080
      protocol: TCP
      livenessProbe:
        httpGet:                    1
          path: /actuator/health
          port: 8080
        initialDelaySeconds: 30     2
  
  # 1. 정상상태 확인 종단점으로 http 점검
  # 2. 애플리케이션 준비 시간을 위해, 첫번쨰 라이브니스 점검을 수행하기 전에 30초를 기다린다.

• 단점: 컨테이너를 재시작 하는 것이 소용없는 경우라면, 근본적인 문제 해결이 없어 정상상태 확인 실패는 아무도움 되지 않는다.
• 장점: 비정상적인 컨테이너를 죽이고, 새로운 컨테이너로 대체해 애플리케이션의 정상 상태를 유지하는 데 유용하다.

레디니스 점검(readiness probe)=준비상태 점검

• when: 때로는 컨테이너가 정상상태가 아니고, 재시작이 도움이 안될 때가 있다.
  • 예. 컨테이너가 여전히 시작중이고, 아직 요청을 처리할 준비가 안된 경우
  • 컨테이너 과부하가 걸릴 수도, 지연시간이 증가할 수 있으며,
  • 또다른 부하(load) 로 부터 잠시 보호받길 원할 수 있다.
• 라이브니스 점검(http, tcp, exec)동일하지만, 장애조치가 다르다.
• 해결 : 컨테이너를 재시작하지 않으며, 레디니스 점검에 실패하면, 컨테이너는 서비스(Service) 엔드포인트에서 제거되고, 새로운 트래픽을 수신할 수 없다.
• 레디니스 점검은 컨테이너가 서비스 요청을 받기 전에 준비할 수 있는 시간을 가지도록 컨테이너가 준비되는 시점에 신호를 보낸다.
• 또한, 레디니스 점검은 라이브니스 점검처럼 주기적으로 수행되므로, 이후 단계에서 트래픽으로부터 서비스를 보호하는데 유리하다.
• 밑 예제는 서비스 준비를 갖춘 시점에서 애플리케이션이 생성한 파일의 존재 여부를 점검하는 방식으로 구현한 레디니스 점검 코드이다.

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-readiness-check
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
    readinessProbe:
      exec:          1
        command: [ "stat", "/var/run/random-generator-ready" ]

# 애플리케이션이 서비스 요청을 처리할 준비가 되었음을 나타내는 파일이 존재하는지 확인한다.
# stat 은 파일이 존재하지 않으면, 에러를 반환하고, 레디니스 점검은 실패한다.

• 정상상태 확인 코드 구현 이후,
  • 점검 후 장애시, 컨테이너 재시작 = 프로세스 정상상태 확인 / 라이브니스 점검
  • 준비할 시간을 주고, 애플리케이션이, 스스로 복구되기를 기다린다. = 레디니스 점검
  • 시그텀(SIGTERM) 신호를 수신한 후, 쿠버네티스는 레디니스 점검 통과 여부와 관계 없이, 컨테이너가 새로운 요청(컨테이너가 종료될 때)을 받지 못하게 만든다는 사실을 명심하자.
• 대부분, 라이브니스와 레디니스 점검은 동일한 체크를 수행하지만, 레디니스 점검이 있으면, 컨테이너에게는 시작할 수 있는 시간이 주여진다.
• 오직, 레디니스 점검을 통과해야, 디플로이먼트가 성공한 것으로 간주된다.
• 라이브니스와 레디니스 점검은 클라우드 네이티브 애플리케이션 자동화의 기본 블록이다. 스프링 액추에잍, 와일드 플라이 스웜 정상상태 확인, 카라프 정상상태확인 등의 애플리케이션 프레임워크는 정상상태 점검 제공을 위한 구현 방법을 제공한다.

정리

• 완전 자동화를 위해 관리플랫폼은 애플리케이션의 health check가 잘돼야한다.
• 정상상태 확인은 배포, 자가치유, 스케일 등과 같은 자동화 활동 안에서 기본 역할을 수행한다.
• 그러나, 애플리케이션이 정상상태에 더 많은 가시성을 제공하는 방법은 더있다.

로깅(logging)

• 컨테이너가 중요 이벤트를 시스템 밖으로 보내고, 시스템 에러를 로그로 남기고, 추후 분석을 위해 이 로그들을 중앙에 수집하는 것이 좋ㄷ.
• 로그는 일반적으로 알람 발생+ 추가조사(장애에 대한 사후분석과 눈에 띄지 않는 오류에 대한 탐지)하는 데 쓰인다.
• 표준 스트림에 로그를 남기는 것 외에도 컨테이너가 종료되는 이유를 /dev/termination-log에 로그로 남기는 것이 좋다.
  • 이 위치는 컨테이너가 영적으로 사라지기 전에 마지막 상태를 남길 수 있는 장소이다.
  • 그림은 컨테이너가 런타임 플랫폼과 통신할 수 있는 방법에서 사용 가능한 옵션들을 보여준다.

• 컨테이너는 블랙박스처럼 취급되어 애플리케이션을 패키징하고 실행하는 통합된 방법을 제공헌더. 그러나, 정상 상태를 관찰하고, 그에 따라 행동하는 런타임 환경에 대한 api를 반드시 제공해야한다. 이것은 시스템의 회복성과 사용자의 경험을 향상시킨다.
  • 실제로 컨테이너화된 애프리케이션은 최소한의 정상상태 확인(라이브니스와 레디니스)을 위한 API 를 제공해야한다.
• 잘동작하는 애플리케이션이여도 관히 플랫폼이 오픈트레이싱(open tracing)이나 프로메테우스와 같이 트레이싱 메트릭 수집 라이브러리와 통합해 컨테이너화된 애플리케이션 상태를 관찰할 수 있도록 또 다른 수단을 제공해야한다.

참고자료

• Health Probe Example
• Configuring Liveness and Readiness Probes
• Setting Up Health Checks Wth Readiness and Liveness Probes
• Resource Quality of Service
• Graceful Shutdown with Node.js and Kubernetes
• Advanced Health-Check Patterns in Kubernetes