Graceful Shutdown Pods in a Kubernetes Cluster

애플리케이션 서버를 직접 클라이언트에 노출하지 않는 것이 좋습니다. 로드 밸런서나, 리버스 프록시 같은 것을 중간에 둬서 서비스 트래픽을 제어할 수 있도록 합니다. 애플리케이션을 종료할 필요가 있을 경우, 로드 밸런서나 리버스 프록시에서 해당 애플리케이션을 제외 시켜버리면, 서비스 트랙이 해당 애플리케이션으로 전달되지 않으므로, 애플리케이션의 입장에서는 새로운 요청을 들어오지 않게됩니다.

로드 밸런서에 특정 서버를 제외할 수 있는 방법은 크게 두가지 있습니다.

  • 로드 밸런서에 서버를 제외 시키는 명령어를 보내기
  • 로드 밸런서에서 서버의 상태를 체크하여, 정상 상태가 아닐 경우 자동으로 제외하기

일반적으로는 두 번째 방법을 많이 사용합니다. 로드 밸런서에서 주기적으로 서버들을 체크하여, 정상 상태가 아닐 경우, 자동으로 해당 서버를 제외시켜버리는 것입니다. 그리고 정상 상태로 돌아올 경우 다시 로드 밸런서에 해당 서버를 추가 시킵니다.

쿠버네티스의 상태 프로브(Health Probe)

쿠버네티스는 컨테이너의 상태를 주기적으로 진단합니다. 각 노드에 설치된 kubelet 에 의하여 컨테이너의 상태를 진단하게 됩니다. 컨테이너의 상태를 진단하기 위하여, 다음과 같은 세가지 타입의 핸들러를 제공하고 있습니다.

  • HTTP : 지정한 경로와 포트에 HTTP GET 요청을 수행합니다. HTTP 응답 코드가 200 보드 크거나 같고, 400보다 작으면 진단이 성공한것으로 간주합니다.
  • TCP : 지정한 포트에 대하여 TCP 검사를 수행합니다. 포트가 활성화 되어 있으면, 진단이 성공한 것으로 간주합니다.
  • Exec : 컨테이너 안에서 지정한 명령어를 실행합니다. 명령어의 종료 코드가 0이면 진단이 성공한것으로 간주합니다.

라이브니스 프로브(Liveness Probe)

애플리케이션이 교착 상태 같은 비정상 상태에 빠졌을 경우, 단순히 프로세스의 상태 확인 만으로는 정상인지 아닌지 판단하기가 어렵습니다. 애플리케이션이 정상 작동 하지 않는 상태에서도, 프로세스의 상태는 정상으로 나올 수 있기 때문입니다. 이런 종류의 문제와, 비즈니스 로직에 따른 다른 형태의 장애를 감지가기 위해서, 쿠버네티스는 라이브니스 프로브를 사용합니다.

쿠버네티스의 노드에 설치된 kubelet이 정기적으로 파드 컨테이너의 라이브니스 상태를 점검하게 됩니다. 만약 비정상 상태가 감지된다면, 컨테이너를 재시작 시킵니다.

애플리케이션의 상태를 확인 할 수 있는 방법은 다음과 같습니다.

애플리케이션이 정상상태인지 아닌지를 판단하는 것은 개발자의 구현에 달려있습니다. 정상상태가 아닐 경우, 컨테이너가 다시 시작된다는 사실을 잘 기억하고 있어야 합니다. 컨테이너 재시작이 아무 소용 없는 경우라면, 해당 라이브니스의 상태값은 아무런 도움이 되지 않기 때문입니다.

레디니스 프로브(Readiness Probe)

쿠버네티스는 파드(Pod)를 이용하여, 애플리케이션을 실행 시킵니다. 그리고 이 파드에 주어진 주소를 이용하여 애플리케이션에 접근할 수 있습니다. 하지만 파드란 것은 상황에 따라 생성되고 없어지는 성질을 가지고 있습니다. 예를 들어, 새로운 배포에 의해 기존 파드가 제거되고, 새로운 파드가 생성될 수 있습니다. 그리고 스케일 아웃을 하기 위하여, 파드의 개수를 늘리 수도 있습니다.

이러한 이유로, 파드의 주소 만으로는 애플리케이션에 접근하는게 쉽지 않습니다. 그래서 쿠버네티스에서는 서비스(Service) 라는 개념을 만들어서, 파드의 애플리케이션으로 접근할 수 있게 하였습니다. 서비스는 레이블 셀렉터를 이용하여, 자신에게 속한 포드들의 목록을 가져올 수 있습니다. 그래서 파드들이 생성되고, 사라지더라도 대상 파드들 중 하나에게 트래픽을 보낼 수 있습니다. 하지만 파드들이 실행중에 있더라도, 무조건 트래픽을 보내면 문제가 생길 수 있습니다. 파드가 비정상 상태에 있을 수도 있기 때문입니다. 그래서 서비스는 파드의 상태를 체크할 필요가 있습니다. 이럴때 사용되는게 레니니스(Readniess) 프로브 입니다. 서비스는 파드의 레디니스(Readiness) 상태를 체크하고, 정상 상태일 때문에 해당 파드로 트래픽을 보냅니다. (정확히 말하면, 서비스가 트래픽을 보내는 것은 아니지만, 개념적으로는 그렇게 이해하시는게 편할것입니다.) 그리고 비정상 상황 파드일 경우, 트래픽을 보내는 대상에서 제외시켜버립니다.

정리하자면, 애플리케이션이 작업을 처리할 준비가 되어있는지를 판별하고, 준비가 되었다면 트래픽을 수신할 수 있도록 해줍니다.

파드 종료 생명주기

애플리케이션의 배포 단위는 파드입니다. 파드는 하나 또는 그 이상의 컨테이너로 이루어져 있습니다. 파드가 종료되면, 파드에 속한 컨테이너도 종료됩니다.

컨테이너가 종료될때 다음과 같은 절차를 따르게 됩니다.

  • 노드에 있는 kubelet이 파드에 정의한 preStop 훅(hook)을 호출합니다.
  • preStop 훅이 완료되면, kubelet 은 파드 컨테이너에서 실행중인 애플리케이션에게 SIGTERM 신호를 보냅니다.
  • kubelet 은 컨테이너가 종료될때 까지 유예 시간(기본값 30초) 동안 기다립니다. 그 후 SIGKILL 을 사용하여 프로세스를 강제로 종료 시킵니다. 이 유예 시간은 preStop 훅을 실행하는 시간까지 포함됩니다.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/5dc89ac3-b345-4f1f-aa3d-1a572ea8c46b/Container_Stop.png

이러한 흐름을 참조하여, preStop 훅이나, SIGTERM 신호를 이용하여, 애플리케이션이 정상적으로 종료될 수 있도록 정리 작업 같은 것을 할 수 있습니다. 예를 들면, 새로운 요청이 들어오지 못하게 하고, 이미 대기열에 있는 작업들의 처리가 완료될때까지 종료가 되지 않도록 기다리게 할 수 있습니다.

물론, preStop 훅이나, SIGTERM 신호를 이용하여 블록킹하더라도, 컨테이너가 종료되는것을 막을 수 없습니다. 유예 기간이 지나면 강제적으로 종료되기 때문입니다.

종료전 훅

preStop 훅은 컨테이너가 종료되기 전에 호출하는 블럭킹 호출입니다. SIGTERM 신호와 동일한 의미를 가지고 있으며, 컨테이너가 SIGTERM 신호를 처리하는 것이 불가능할 때 사용합니다.

preStop 훅 에서 사용할 수 있는 핸들러는 다음과 같습니다.

  • httpGet: 지정한 경로와 포트에 HTTP GET 요청을 수행합니다.
  • exec: 컨테이너 안에서 지정한 명령어를 실행합니다.

다음은 preStop 훅을 사용하는 컨테이너 예제입니다. 애플리케이션의 xxx 엔드포인트를 호출합니다.

apiVersion: v1
kind: Pod
metadata:
  name: pre-stop-hook
spec:
  containers:
  - name: demo-app
    image: xxxx
    lifecycle:
      preStop:
        httpGet:
          path: /shutdown
          port: 8080

SIGTERM 신호

컨테이너를 종료하려고 할때, kubelet 은 컨테이너에게 SIGTERM 신호를 보냅니다. SIGTERM 신호는 컨테이너한테, 종료할거라는 것을 미리 알려주는 역할을 합니다. SIGTERM 신호를 받은 애플리케이션은 가능한 한 빠르게 애플리케이션을 종료시켜야 합니다. 그리고 안전하고 깨끗하게 애플리케이션을 종료하기 위한 작업들도 진행할 수 있습니다.

SIGKILL 신호

SIGTERM 신호 후에도 컨테이너가 종료되지 않는다면, SIGKILL 신호를 발생시켜 강제로 종료시킵니다. SIGTERM 신호 발생 후, 지정된 유예 시간 동안 컨테이너가 종료되지 않으면, SIGKILL 신호를 발생시키는 것입니다. 이 유예 시간은 .spec.termicationGracePeriodSeconds 필드를 이용하여 설정할 수 있습니다.

종료 후 트래픽

파드의 정상적인 종료는, 종료 전에 들어온 트래픽을 처리하도록 보장할 수 있습니다. 하지만 파드가 종료된 후에도 트래픽을 계속 수신하여, 서비스에서 다운타임이 발생할 수 도 있습니다.

어떻게 해서 이런 문제가 발생하는지에 대해서 살펴보겠습니다. 다음 예제에서는 두 개의 포드가 실행되어 있고, 트래픽을 받기 위해서 하나의 서비스 가 있습니다. 트래픽은 서비스를 거처 두 개의 포드 중 하나로 전달됩니다.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/6a050a05-fa7f-4b24-8141-7591171354c5/Kubernetes-service_(1).png

이 시점에서 파드 A1을 삭제한다가 가정하겠습니다. 파드 A1을 종료하기 위해서 kubectlpreStop 훅을 먼저 실행하게 되고, 파드 A1의 애플리케이션을 정상적인 종료 절차가 시작됩니다.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/5217f1df-6adc-4491-9c7e-5c0ce1776eff/Kubernetes-preStop_(1).png

파드 A1의 종료를 위하여, preStop 훅을 호출 하는 시점에서도, 파드는 서비스에 등록되어 있을 수 있기 때문에 여전히 트래픽을 받을 수 있습니다.

파드 A1의 애플리케이션이 preStop 훅을 수신 받으면, 정상적인 종료를 위한 절차를 실행할 것입니다. 일반적인 종료 절차는, 이미 들어온 요청을 처리하고, 애플리케이션을 종료시키는 등의 작업일 것입니다. 그런데 이런 절차에 의해서, 애플리케이션이 종료되었는데, 새롭게 들어오는 추가 트래픽이 발생한다면, 오류를 발생시킬 수 있습니다.

그래서, 보다 안전하게 파드를 종료시키려면, 해당 파드를 서비스로부터 제거해야 하는 것입니다.

파드 종료 절차

API를 통해서 파드를 삭제한다고 가정해보겠습니다. API를 통해서 파드를 삭제하면, 메타데이터 서버에 파드가 삭제되길 원한다고 표시되기만 합니다. 이렇게 되면, 파드 삭제 통지가 전파가 됩니다. 그리고, 파드 삭제에 관련있는 시스템은 다음과 같은 처리를 하게 됩니다.

  • 파드를 실행하는 kubelet은 앞에 설명한 “파드 종료 생명주기”의 종료 절차를 시작하게 됩니다.
  • 엔드포인트 컨트롤러(endpoints controller) 가 유효한 엔드포인트 목록에서 파드를 제거하게 되고, 해당 서비스에서 파드가 제거됩니다.

여기서 중요한 점은, 여러 시스템이 관련이 있고, 서로 다른 노드에서 실행될 수도 있기 때문에, 이러한 절차가 병렬로 처리될 수도 있다는 것입니다. 그래서 종료 절차가 시작된 후에도 트래픽을 계속 수신할 수도 있는 것입니다.

문제 완화

불행히도 이러한 문제점을 완벽하게 해결할 수 있는 방법은 없습니다. 하지만 충분한 종료 절차 지연을 두어서, 대부분의 경우에는 이문제를 회피할 수 있습니다. 가장 간단한 방법은 preStop 훅에, sleep을 실행하여, 종료 절차를 지연시키는 것입니다.

다음은 preStop 훅에 지연을 추가한 매니페스트의 일부분입니다. 정확하게 몇초를 지연시키는것이 좋다는 것은 알 수 없습니다. 하지만, “Kubernete in Action”책에서 5-10초를 추천하였기 때문에, 예제에서는 5초를 사용하였습니다.

lifecycle:
  preStop:
    exec:
      command: [
        "sh", "-c",
        # Introduce a delay to the shutdown sequence to wait for the
        # pod eviction event to propagate. Then, gracefully shutdown
        "sleep 5",
      ]
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/dcd36ceb-3ceb-4137-b11c-3c85e121b568/Kubernetes-sleep.png

preStop 훅에 의해서 5초간 지연을 시켰기 때문에, 유효한 엔드포인트 목록에서 파드를 제거하고, 해당 서비스에서도 파드를 제거하기 충분한 시간을 확보할 수 있게 됩니다.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다