Kubernetes 팁과 요령: NGINX 및 PHP-FPM의 우아한 종료 기능

Kubernetes에서 CI/CD를 구현할 때 일반적인 조건은 애플리케이션이 완전히 중지되기 전까지는 새로운 클라이언트 요청을 수락하지 않아야 하며, 가장 중요한 것은 기존 요청을 성공적으로 완료해야 한다는 것입니다.

이 조건을 준수하면 배포 중 다운타임을 최소화할 수 있습니다. 하지만 NGINX나 PHP-FPM과 같이 널리 사용되는 번들을 사용하더라도 배포할 때마다 오류가 급증하는 문제에 직면할 수 있습니다.

이론. 포드의 생활 방식

우리는 이미 포드 수명주기에 대한 자세한 기사를 게시했습니다. 이 문서. 고려 중인 주제의 맥락에서 우리는 다음 사항에 관심이 있습니다. 포드가 상태에 진입하는 순간 종료 중, 새로운 요청이 더 이상 전송되지 않습니다(pod 삭제됨 (서비스의 엔드포인트 목록에서) 따라서 배포 중 가동 중지 시간을 방지하려면 애플리케이션을 올바르게 중지하는 문제를 해결하는 것으로 충분합니다.

또한 기본 유예 기간은 다음과 같다는 점도 기억해야 합니다. 30초: 이후에는 포드가 종료되고, 애플리케이션은 이 기간 전에 모든 요청을 처리할 시간이 필요합니다. 주의: 실행하는 데 5~10초 이상 걸리는 쿼리는 이미 문제가 있는 것이고, 정상적인 종료로는 해결되지 않습니다.

포드가 종료될 때 어떤 일이 일어나는지 더 잘 이해하려면 다음 다이어그램을 살펴보세요.

A1, B1 - 포드 상태 변경 수신
A2 - SIGTERM 전송
B2 - 엔드포인트에서 포드 제거
B3 - 변경 사항 수신(엔드포인트 목록이 변경됨)
B4 - iptables 규칙 업데이트

참고: 파드 엔드포인트 삭제 및 SIGTERM 전송은 순차적으로 이루어지지 않고 병렬로 진행됩니다. 또한 Ingress가 업데이트된 엔드포인트 목록을 즉시 수신하지 않기 때문에 클라이언트의 새로운 요청이 파드로 전송되어 파드 종료 시 500 오류가 발생합니다. (우리는 이 문제에 대해 더 자세한 자료를 가지고 있습니다. 번역됨)이 문제는 다음과 같은 방법으로 해결해야 합니다.

• 연결 보내기: 응답 헤더에서 닫습니다(HTTP 애플리케이션에 적용되는 경우).
• 코드를 변경할 수 없는 경우, 이 문서에서는 유예 기간이 끝날 때까지 요청을 처리할 수 있는 솔루션을 자세히 설명합니다.

이론: NGINX와 PHP-FPM이 프로세스를 종료하는 방법

NGINX

NGINX부터 시작해 보겠습니다. NGINX에서는 모든 것이 어느 정도 명확하기 때문입니다. 이론을 자세히 살펴보면 NGINX에는 하나의 마스터 프로세스와 여러 개의 "워커"가 있다는 것을 알 수 있습니다. 워커는 클라이언트 요청을 처리하는 자식 프로세스입니다. 편리한 옵션은 다음 명령을 사용하는 것입니다. nginx -s <SIGNAL> 빠른 종료 모드 또는 우아한 종료 모드로 프로세스를 종료합니다. 당연히 후자에 관심이 있습니다.

그러면 모든 것이 간단합니다. 추가해야 합니다. 프리스톱 후크 정상적인 종료 신호를 보내는 명령입니다. 이 작업은 배포 프로세스의 컨테이너 블록에서 수행할 수 있습니다.

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

이제 포드가 종료되면 NGINX 컨테이너 로그에서 다음을 볼 수 있습니다.

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

즉, NGINX는 요청이 완료될 때까지 기다렸다가 프로세스를 종료합니다. 하지만 아래에서는 명령을 사용하더라도 발생할 수 있는 일반적인 문제도 살펴보겠습니다. nginx -s quit 프로세스가 비정상적으로 종료됩니다.

이 단계에서는 NGINX에 대한 작업이 완료되었습니다. 최소한 로그를 보면 모든 것이 제대로 작동하고 있음을 알 수 있습니다.

PHP-FPM은 어떤 기능을 할까요? 정상적인 종료(graceful shutdown)는 어떻게 처리할까요? 함께 알아보겠습니다.

PHP-FPM

PHP-FPM의 경우 정보가 조금 부족합니다. 공식 매뉴얼 PHP-FPM에서는 다음 POSIX 신호가 허용된다는 메시지가 표시됩니다.

1. SIGINT, SIGTERM — 빠른 종료
2. SIGQUIT — 우아한 종료(우리에게 필요한 것).

나머지 신호는 이 작업에 필요하지 않으므로 분석은 건너뛰겠습니다. 프로세스를 올바르게 완료하려면 다음과 같은 preStop 후크를 작성해야 합니다.

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

언뜻 보기에는 두 컨테이너 모두에서 정상 종료를 수행하는 데 필요한 모든 작업이 완료되었습니다. 하지만 실제 작업은 보기보다 훨씬 복잡합니다. 아래는 정상 종료가 제대로 작동하지 않아 배포 중에 프로젝트를 일시적으로 사용할 수 없게 된 두 가지 사례입니다.

연습. 정상적인 종료 시 발생할 수 있는 문제

NGINX

우선, 명령을 실행하는 것 외에도 다음 사항을 기억하는 것이 유용합니다. nginx -s quit 주의해야 할 단계가 하나 더 있습니다. NGINX가 SIGQUIT 신호를 보내는 대신 SIGTERM 신호를 보내 요청이 제대로 완료되지 않는 문제가 발생했습니다. 예를 들어 다음과 같은 유사한 사례가 있습니다. 여기에. 안타깝게도 이 동작의 구체적인 원인을 파악할 수 없었습니다. NGINX 버전 관련 의심은 있었지만, 확인되지는 않았습니다. NGINX 컨테이너 로그에서 다음과 같은 메시지가 관찰되었습니다. "연결 10에 열린 소켓 #5이 남아 있습니다", 그 후 포드가 멈췄습니다.

예를 들어, Ingress에 대한 응답에서 이러한 문제를 관찰할 수 있습니다.

배포 시점의 상태 코드 표시기

이 경우 Ingress 자체에서 503 오류 코드가 발생합니다. NGINX 컨테이너를 더 이상 사용할 수 없기 때문에 액세스할 수 없습니다. NGINX 컨테이너의 로그를 살펴보면 다음과 같은 내용을 확인할 수 있습니다.

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

정지 신호를 변경한 후 컨테이너가 정상적으로 멈추기 시작합니다. 이는 503 오류가 더 이상 관찰되지 않는다는 사실로 확인됩니다.

비슷한 문제가 발생하면 컨테이너에 어떤 종류의 정지 신호가 사용되었는지, 그리고 preStop 후크가 정확히 어떻게 생겼는지 파악하는 것이 좋습니다. 아마도 이것이 원인일 가능성이 높습니다.

PHP-FPM… 및 기타

PHP-FPM의 문제점은 간단하게 설명할 수 있습니다. 자식 프로세스가 완료될 때까지 기다리지 않고 종료시켜 배포 및 기타 작업 중에 502 오류를 발생시킵니다. bugs.php.net에는 2005년부터 여러 버그 리포트가 게시되어 있습니다(예: 여기에 и 여기에), 문제를 설명하는 내용이 있습니다. 하지만 로그에는 아무것도 표시되지 않을 가능성이 높습니다. PHP-FPM은 오류나 타사 알림 없이 프로세스 완료를 알립니다.

문제 자체는 애플리케이션 자체에 따라 다소 달라질 수 있으며, 예를 들어 모니터링에서 나타나지 않을 수도 있다는 점을 명확히 해두는 것이 좋습니다. 문제가 발생하면 먼저 간단한 해결 방법이 떠오릅니다. preStop 후크를 추가하는 것입니다. sleep(30). 이를 통해 이전에 수행된 모든 요청을 완료할 수 있습니다(그리고 pod가 새로운 요청을 수락하지 않으므로). 이미 할 수 있는 종료 중), 그리고 30초 후에 포드 자체가 신호와 함께 종료됩니다. SIGTERM.

그것은 밝혀 그 lifecycle 컨테이너의 경우 다음과 같이 보입니다.

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

하지만 30초 표시로 인해 sleep 우리 강하게 각 포드가 종료되므로 배포 시간이 늘어납니다. 최소한의 30초면 너무 짧네요. 어떻게 해야 할까요?

애플리케이션을 직접 실행하는 당사자에 대해 살펴보겠습니다. 이 경우에는 다음과 같습니다. PHP-FPM어느 기본적으로 자식 프로세스의 실행을 모니터링하지 않습니다.: 마스터 프로세스가 즉시 종료됩니다. 이 동작은 다음 지시어를 사용하여 변경할 수 있습니다. process_control_timeout는 자식 프로세스가 마스터 프로세스의 신호를 기다리는 시간 제한을 지정합니다. 값을 20초로 설정하면 컨테이너에서 실행 중인 대부분의 요청이 처리되고, 요청이 완료되면 마스터 프로세스가 중지됩니다.

이러한 지식을 바탕으로 마지막 문제로 돌아가 보겠습니다. 앞서 언급했듯이 쿠버네티스는 모놀리식 플랫폼이 아닙니다. 여러 구성 요소 간의 상호 작용에는 시간이 걸립니다. 특히 Ingress와 다른 인접 구성 요소의 작업을 고려할 때 더욱 그렇습니다. 이러한 지연은 배포 시점에 500개의 오류가 급증하는 결과로 이어질 수 있기 때문입니다. 예를 들어, 업스트림으로 요청을 전송하는 단계에서 오류가 발생할 수 있지만, 구성 요소 간 상호 작용의 "시간 지연"은 XNUMX초 미만으로 매우 짧습니다.

그러므로, 전체적으로 이미 언급된 지침과 함께 process_control_timeout 다음 구조를 사용할 수 있습니다 lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

이 경우 우리는 명령으로 지연을 보상합니다. sleep 그리고 우리는 배포 시간을 크게 늘리지 않습니다. 결국 30초와 XNUMX초의 차이가 눈에 띄지 않습니까? 본질적으로 그것은 정확히 process_control_timeout과 lifecycle 지연이 발생할 경우를 대비한 "백업"으로만 사용됩니다.

일반적으로 말하기 설명된 동작과 해당 해결 방법은 PHP-FPM에만 국한되지 않습니다.다른 PL/프레임워크를 사용할 때도 비슷한 상황이 발생할 수 있습니다. 다른 방법으로도 정상적인 종료 문제를 해결할 수 없다면 (예: 애플리케이션이 종료 신호를 올바르게 처리하도록 코드를 다시 작성하는 경우) 설명된 방법을 사용할 수 있습니다. 가장 좋은 방법은 아니지만 작동합니다.

연습: 포드 작동을 확인하기 위한 부하 테스트

부하 테스트는 컨테이너 작동 방식을 확인하는 한 가지 방법으로, 사용자가 사이트를 방문할 때 실제 전투 상황에 더 가깝게 다가갈 수 있도록 해줍니다. 위의 권장 사항을 테스트하려면 다음을 사용할 수 있습니다. Yandex.Tank: 모든 요구 사항을 완벽하게 충족합니다. Grafana와 Yandex.Tank 차트를 활용한 저희 경험의 시각적 예시를 통해 테스트할 수 있는 몇 가지 팁과 요령을 소개합니다.

여기서 가장 중요한 것은 단계별로 변경 사항 확인새로운 수정 사항을 추가한 후 테스트를 실행하여 이전 실행 결과와 차이가 있는지 확인하세요. 그렇지 않으면 비효율적인 해결책을 파악하기 어렵고, 장기적으로는 오히려 해를 끼칠 수 있습니다(예: 배포 시간 증가).

또 다른 중요한 점은 컨테이너 종료 시 로그를 살펴보는 것입니다. 정상 종료(graceful shutdown) 관련 정보가 기록되어 있습니까? 다른 리소스(예: 인접한 PHP-FPM 컨테이너)에 접근할 때 로그에 오류가 있습니까? 애플리케이션 자체의 오류(위에서 설명한 NGINX의 경우처럼)는 있습니까? 이 글의 소개 정보가 컨테이너 종료 시 발생하는 상황을 더 잘 이해하는 데 도움이 되기를 바랍니다.

그래서 첫 번째 테스트 실행은 다음과 같이 진행되었습니다. lifecycle 그리고 애플리케이션 서버에 대한 추가 지침 없이 (process_control_timeout PHP-FPM에서). 이 테스트의 목적은 대략적인 오류 수(그리고 오류가 있는지 여부)를 파악하는 것이었습니다. 또한, 추가 정보를 통해 각 포드의 평균 배포 시간이 완전히 준비될 때까지 약 5~10초였다는 것을 알 수 있습니다. 결과는 다음과 같습니다.

Yandex.Tank 대시보드는 배포 중 발생한 502 오류가 평균 5초 동안 급증했음을 보여줍니다. 이는 기존 Pod에 대한 기존 요청이 종료되었기 때문일 수 있습니다. 그 후 503 오류가 발생했는데, 이는 NGINX 컨테이너가 중지되었고 백엔드(Ingress가 연결할 수 없음)로 인해 연결이 끊어졌기 때문입니다.

어떻게 되는지 보자 process_control_timeout PHP-FPM에서는 자식 프로세스가 완료될 때까지 기다리도록 하여 이러한 오류를 수정하는 데 도움이 됩니다. 다음 지시어를 사용하여 재배포할 수 있습니다.

배포 중 500 오류가 더 이상 발생하지 않습니다! 배포가 성공적으로 완료되었으며, 정상적인 종료가 가능합니다.

하지만 Ingress 컨테이너의 경우, 시간 지연으로 인해 발생할 수 있는 소수의 오류가 있다는 점을 기억하는 것이 좋습니다. 이를 방지하려면 다음과 같은 구문을 추가해야 합니다. sleep 배포를 다시 진행했습니다. 하지만 저희의 경우에는 아무런 변화도 보이지 않았고 오류도 발생하지 않았습니다.

결론

프로세스를 올바르게 완료하려면 애플리케이션에서 다음과 같은 동작이 필요합니다.

1. 몇 초간 기다린 후 새로운 연결을 수락하지 마세요.
2. 모든 요청이 완료될 때까지 기다리고, 요청을 실행하지 않는 모든 Keepalive 연결을 닫습니다.
3. 프로세스를 완료하세요.

하지만 모든 애플리케이션이 이런 방식으로 작동할 수 있는 것은 아닙니다. 쿠버네티스 현실에서 이 문제에 대한 한 가지 해결책은 다음과 같습니다.

• 몇 초간 기다리는 사전 정지 후크를 추가합니다.
• 관련 매개변수에 대한 백엔드 구성 파일을 검사합니다.

NGINX 예시는 초기에는 종료 신호를 올바르게 처리해야 하는 애플리케이션조차도 제대로 처리하지 못할 수 있다는 점을 이해하는 데 도움이 됩니다. 따라서 애플리케이션 배포 중에 500 오류를 확인하는 것이 매우 중요합니다. 또한 이를 통해 문제를 더 광범위하게 살펴보고 단일 포드나 컨테이너에 집중하지 않고 전체 인프라를 전체적으로 살펴볼 수 있습니다.

Yandex.Tank는 모든 모니터링 시스템과 함께 테스트 도구로 사용할 수 있습니다(이 경우, Prometheus 형태의 백엔드를 사용하는 Grafana에서 데이터를 가져와 테스트했습니다). 벤치마크에서 발생할 수 있는 과부하 상황에서는 정상 종료 문제가 명확하게 드러납니다. 모니터링을 통해 테스트 중이나 테스트 후에 상황을 더욱 자세히 분석할 수 있습니다.

이 기사에 대한 피드백에 대한 답변입니다. 여기에 설명된 문제와 해결책은 NGINX Ingress에도 적용 가능합니다. 다른 경우에는 이 시리즈의 다음 자료에서 살펴볼 수 있는 다른 해결책들이 있습니다.

PS

기타 K8s 팁 및 요령 시리즈:

• «NGINX Ingress의 사용자 정의 오류 페이지";
• «웹 애플리케이션의 노드 할당 및 로드 정보";
• «개발 사이트에 대한 액세스";
• «대규모 데이터베이스의 부트스트랩 속도 향상".

출처 : habr.com