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

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

이 조건을 준수하면 배포 중에 가동 중지 시간이 발생하지 않습니다. 그러나 매우 인기 있는 번들(NGINX 및 PHP-FPM 등)을 사용하는 경우에도 배포할 때마다 오류가 급증하는 어려움에 직면할 수 있습니다.

이론. 포드의 생활 방식

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

기본 유예 기간은 다음과 같습니다. 30 초: 이후에는 Pod가 종료되며 애플리케이션은 이 기간 전에 모든 요청을 처리할 시간을 가져야 합니다. 주의: 5~10초 이상 걸리는 요청은 이미 문제가 있으며, 우아한 종료로는 더 이상 도움이 되지 않습니다.

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

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

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

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

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

NGINX

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

그렇다면 모든 것이 간단합니다. preStop-hook 정상적인 종료 신호를 보내는 명령입니다. 이 작업은 배포의 컨테이너 블록에서 수행할 수 있습니다.

       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과의 거래는 무엇입니까? 우아한 종료를 어떻게 처리합니까? 그것을 알아 봅시다.

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 오류가 발생합니다. 2005년 이후부터 bugs.php.net에 여러 가지 버그 보고서가 있습니다(예: 여기에 и 여기에), 이 문제를 설명합니다. 그러나 로그에는 아무 것도 표시되지 않을 가능성이 높습니다. PHP-FPM은 오류나 제XNUMX자 알림 없이 프로세스 완료를 알립니다.

문제 자체는 응용 프로그램 자체에 어느 정도 의존할 수 있으며 모니터링 등에서 자체적으로 나타나지 않을 수 있다는 점을 명확히 할 필요가 있습니다. 이 문제가 발생하면 먼저 간단한 해결 방법이 떠오릅니다. 다음을 사용하여 preStop 후크를 추가합니다. sleep(30). 이를 통해 이전의 모든 요청을 완료할 수 있습니다. (그리고 포드 이후로 새로운 요청은 허용되지 않습니다.) 이미 할 수 있는 종료 중), 30초 후에 Pod 자체가 신호로 종료됩니다. SIGTERM.

그것은 밝혀 그 lifecycle 컨테이너의 모양은 다음과 같습니다.

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

하지만 30초라는 시간 때문에 sleep 우리 강하게 각 포드가 종료되므로 배포 시간이 늘어납니다. 최소한의 30초, 나쁘다. 이에 대해 무엇을 할 수 있습니까?

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

이 지식을 바탕으로 마지막 문제로 돌아가 보겠습니다. 앞서 언급했듯이 Kubernetes는 모놀리식 플랫폼이 아닙니다. 다양한 구성 요소 간의 통신에는 시간이 걸립니다. 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에만 적용되는 것이 아닙니다.. 다른 언어/프레임워크를 사용할 때 비슷한 상황이 어떤 식으로든 발생할 수 있습니다. 다른 방법(예: 애플리케이션이 종료 신호를 올바르게 처리하도록 코드를 다시 작성)으로 정상적인 종료를 해결할 수 없는 경우 설명된 방법을 사용할 수 있습니다. 가장 아름답지는 않을 수도 있지만 효과가 있습니다.

관행. 포드의 작동을 확인하기 위한 부하 테스트

부하 테스트는 컨테이너가 어떻게 작동하는지 확인하는 방법 중 하나입니다. 이 절차를 통해 사용자가 사이트를 방문할 때 실제 전투 조건에 더 가까워지기 때문입니다. 위의 권장 사항을 테스트하려면 다음을 사용할 수 있습니다. Yandex.Tankom: 우리의 모든 요구를 완벽하게 충족시켜줍니다. 다음은 Grafana 및 Yandex.Tank 자체의 그래프 덕분에 경험에서 얻은 명확한 예를 통해 테스트를 수행하기 위한 팁과 권장 사항입니다.

여기서 가장 중요한 것은 변경사항을 단계별로 확인하세요.. 새 수정 사항을 추가한 후 테스트를 실행하고 결과가 마지막 실행과 비교하여 변경되었는지 확인하세요. 그렇지 않으면 비효율적인 솔루션을 식별하기가 어려우며 장기적으로 해를 끼칠 수 있습니다(예: 배포 시간 증가).

또 다른 뉘앙스는 종료 중에 컨테이너 로그를 보는 것입니다. 정상 종료에 대한 정보가 거기에 기록되어 있나요? 다른 리소스(예: 인접 PHP-FPM 컨테이너)에 액세스할 때 로그에 오류가 있습니까? 위에서 설명한 NGINX의 경우처럼 애플리케이션 자체에 오류가 있습니까? 이 기사의 소개 정보가 컨테이너가 종료되는 동안 컨테이너에 어떤 일이 발생하는지 더 잘 이해하는 데 도움이 되기를 바랍니다.

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

Yandex.Tank 정보 패널에는 배포 시 발생하고 평균 최대 502초 동안 지속되는 5 오류 급증이 표시됩니다. 이는 아마도 이전 포드에 대한 기존 요청이 종료될 때 종료되었기 때문일 것입니다. 그 후 503 오류가 나타났는데, 이는 중지된 NGINX 컨테이너의 결과였으며 백엔드로 인해 연결도 끊어졌습니다(Ingress의 연결이 차단됨).

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

500번째 배포에는 더 이상 오류가 없습니다! 배포가 성공하고 정상적으로 종료됩니다.

그러나 시간 지연으로 인해 발생할 수 있는 작은 비율의 오류인 Ingress 컨테이너의 문제를 기억할 가치가 있습니다. 이를 방지하기 위해 남은 것은 다음과 같은 구조를 추가하는 것입니다. sleep 배포를 반복합니다. 그러나 우리의 특별한 경우에는 변경 사항이 표시되지 않았습니다(역시 오류 없음).

결론

프로세스를 정상적으로 종료하려면 애플리케이션에서 다음과 같은 동작이 필요합니다.

1. 몇 초 정도 기다린 후 새 연결 수락을 중지합니다.
2. 모든 요청이 완료될 때까지 기다렸다가 요청을 실행하지 않는 모든 연결 유지 연결을 닫습니다.
3. 프로세스를 종료합니다.

그러나 모든 애플리케이션이 이런 방식으로 작동할 수 있는 것은 아닙니다. Kubernetes 현실의 문제에 대한 한 가지 해결책은 다음과 같습니다.

• 몇 초 동안 기다리는 사전 정지 후크를 추가합니다.
• 적절한 매개변수에 대한 백엔드 구성 파일을 연구합니다.

NGINX의 예에서는 초기에 종료 신호를 올바르게 처리해야 하는 애플리케이션이라도 그렇게 하지 않을 수 있음을 분명히 보여줍니다. 따라서 애플리케이션 배포 중에 500 오류를 확인하는 것이 중요합니다. 또한 이를 통해 문제를 더 광범위하게 볼 수 있고 단일 포드나 컨테이너에 초점을 맞추지 않고 전체 인프라를 전체적으로 볼 수 있습니다.

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

기사에 대한 피드백에 대한 응답으로, 여기에 NGINX Ingress와 관련된 문제와 해결책이 설명되어 있다는 점을 언급할 가치가 있습니다. 다른 경우에는 다음 시리즈 자료에서 고려할 수 있는 다른 솔루션이 있습니다.

PS

기타 K8s 팁 및 요령 시리즈:

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

출처 : habr.com