Kubernetes のヒントとテクニック: NGINX および PHP-FPM の正常なシャットダウンの機能

Kubernetes で CI/CD を実装する場合の一般的な条件: アプリケーションは完全に停止する前に、そして最も重要なことに、既存のリクエストを正常に完了するまで、新しいクライアント リクエストを受け入れられないようにする必要があります。

この条件に準拠すると、展開中にダウンタイムをゼロにできます。 ただし、非常に人気のあるバンドル (NGINX や PHP-FPM など) を使用している場合でも、デプロイメントごとにエラーが急増するという問題に遭遇する可能性があります。

理論。 ポッドの生き方

ポッドのライフサイクルについてはすでに詳しく公開しています この記事。 検討中のトピックのコンテキストでは、次のことに興味があります: ポッドが状態に入った瞬間 終了、新しいリクエストの送信が停止します (ポッド 削除されました サービスのエンドポイントのリストから)。 したがって、展開中のダウンタイムを回避するには、アプリケーションを正しく停止するという問題を解決するだけで十分です。

デフォルトの猶予期間は次のとおりであることにも注意してください。 30秒: この後、ポッドは終了され、アプリケーションはこの期間までにすべてのリクエストを処理する時間が必要です。 注意: ただし、5 ～ 10 秒以上かかるリクエストにはすでに問題があり、正常なシャットダウンはもう役に立ちません...

ポッドが終了すると何が起こるかをよりよく理解するには、次の図を見てください。

A1、B1 - 囲炉裏の状態に関する変更の受信
A2 - 出発シグターム
B2 - エンドポイントからポッドを削除する
B3 - 変更の受信 (エンドポイントのリストが変更されました)
B4 - iptables ルールの更新

注意: エンドポイント ポッドの削除と SIGTERM の送信は連続的に行われるのではなく、並行して行われます。 また、Ingress がエンドポイントの更新されたリストをすぐに受信しないため、クライアントからの新しいリクエストがポッドに送信され、ポッドの終了時に 500 エラーが発生します。 (この問題に関する詳細な資料については、 翻訳された)。 この問題は次の方法で解決する必要があります。

• 接続の送信: 応答ヘッダーで閉じます (HTTP アプリケーションに関する場合)。
• コードを変更できない場合は、次の記事で、猶予期間が終了するまでリクエストを処理できる解決策について説明します。

理論。 NGINX と PHP-FPM がプロセスを終了する方法

nginxの

NGINX を使えばすべてが多かれ少なかれ明らかになるため、NGINX から始めましょう。 理論を詳しく見てみると、NGINX には XNUMX つのマスター プロセスと複数の「ワーカー」があり、これらはクライアントのリクエストを処理する子プロセスであることがわかります。 便利なオプションが提供されています: コマンドを使用する nginx -s <SIGNAL> 高速シャットダウン モードまたは正常なシャットダウン モードでプロセスを終了します。 明らかに、私たちが興味を持っているのは後者のオプションです。

そうすれば、すべてが簡単になります。次のことを追加する必要があります。 プレストップフック 正常なシャットダウン信号を送信するコマンド。 これは、Deployment のコンテナ ブロックで実行できます。

       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"

一見すると、両方のコンテナーで正常なシャットダウンを実行するために必要なのはこれだけです。 しかし、その仕事は思っているよりも難しいです。 以下に、正常なシャットダウンが機能せず、展開中にプロジェクトが短期間利用できなくなる XNUMX つのケースを示します。

練習する。 正常なシャットダウンで考えられる問題

nginxの

まず、次のことを覚えておくと便利です。 コマンドの実行に加えて、 nginx -s quit もう一つ注目すべきステージがあります。 NGINX が SIGQUIT シグナルの代わりに SIGTERM を送信し、リクエストが正しく完了しないという問題が発生しました。 同様の事例は、例えば、次のような場合に見つかります。 ここで。 残念ながら、この動作の具体的な理由を特定することはできませんでした。NGINX のバージョンに関する疑いがありましたが、確認されていませんでした。 症状は、NGINX コンテナー ログにメッセージが観察されることでした。 「接続 10 に残っているソケット #5 を開きます」、その後ポッドは停止しました。

このような問題は、たとえば、必要な Ingress の応答から観察できます。

導入時のステータスコードのインジケーター

この場合、Ingress 自体から 503 エラー コードのみを受け取ります。NGINX コンテナにはアクセスできなくなったため、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 の問題は簡単に説明されています。PHP-FPM は子プロセスの完了を待たずに子プロセスを終了します。そのため、デプロイメントやその他の操作中に 502 エラーが発生します。 2005 年以降、bugs.php.net にはいくつかのバグ レポートがあります (例: ここで и ここで)、この問題について説明しています。 ただし、ほとんどの場合、ログには何も表示されません。PHP-FPM は、エラーやサードパーティの通知なしでプロセスの完了を通知します。

問題自体は多かれ少なかれアプリケーション自体に依存する可能性があり、監視などではそれ自体が現れない可能性があることを明確にする価値があります。 この問題に遭遇した場合は、まず簡単な回避策が思い浮かびます。それは、次のような preStop フックを追加することです。 sleep(30)。 これにより、以前のすべてのリクエストを完了できるようになります (ポッドがあるため、新しいリクエストは受け入れられません) すでに できる 終了)、30 秒後にポッド自体がシグナルで終了します。 SIGTERM.

これは、ことが判明 lifecycle コンテナは次のようになります。

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

ただし、30秒なので、 sleep 我々 強く 各ポッドが終了されるため、デプロイ時間が長くなります。 最小 30秒、これはひどいです。 これについて何ができるでしょうか?

アプリケーションの直接実行を担当する当事者に目を向けましょう。 私たちの場合はそうです PHP-FPMどちら デフォルトでは、子プロセスの実行を監視しません。: マスタープロセスは即時に終了します。 ディレクティブを使用してこの動作を変更できます process_control_timeout、子プロセスがマスターからのシグナルを待つ時間制限を指定します。 値を 20 秒に設定すると、コンテナー内で実行されているほとんどのクエリがカバーされ、クエリが完了するとマスター プロセスが停止します。

この知識を踏まえて、最後の問題に戻りましょう。 前述したように、Kubernetes はモノリシック プラットフォームではありません。さまざまなコンポーネント間の通信には時間がかかります。 これは、Ingresses やその他の関連コンポーネントの操作を考慮した場合に特に当てはまります。デプロイメント時の遅延により、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 だけに適用されるものではありません。。 他の言語/フレームワークを使用する場合にも、何らかの形で同様の状況が発生する可能性があります。 他の方法で正常なシャットダウンを修正できない場合 (たとえば、アプリケーションが終了信号を正しく処理するようにコードを書き直すなど)、説明されている方法を使用できます。 最も美しくはないかもしれませんが、機能します。

練習する。 ポッドの動作を確認するための負荷テスト

負荷テストは、ユーザーがサイトにアクセスしたときにコンテナーが実際の戦闘状態に近づくため、コンテナーがどのように機能するかを確認する方法の XNUMX つです。 上記の推奨事項をテストするには、次を使用できます Yandex.Tankom: すべてのニーズを完璧にカバーします。 以下は、Grafana と Yandex.Tank 自体のグラフによる私たちの経験からの明確な例を使用して、テストを実施するためのヒントと推奨事項です。

ここで最も重要なことは、 変更を段階的に確認する。 新しい修正を追加した後、テストを実行して、前回の実行と比較して結果が変化したかどうかを確認します。 そうしないと、効果のないソリューションを特定することが難しくなり、長期的には害を及ぼすだけになります (たとえば、導入時間の増加)。

もう XNUMX つのニュアンスは、終了時にコンテナーのログを確認することです。 正常なシャットダウンに関する情報はそこに記録されていますか? 他のリソース (たとえば、隣接する 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 の現実の問題に対する XNUMX つの解決策は次のとおりです。

• 数秒待機する停止前フックを追加します。
• バックエンドの設定ファイルで適切なパラメータを調べています。

NGINX の例では、最初は終了信号を正しく処理する必要があるアプリケーションでも、正しく処理できない可能性があることが明らかです。そのため、アプリケーションのデプロイ中に 500 エラーをチェックすることが重要です。 これにより、問題をより広く見ることができ、単一のポッドやコンテナーに焦点を当てるのではなく、インフラストラクチャ全体を全体として見ることができます。

テスト ツールとして、Yandex.Tank を任意の監視システムと組み合わせて使用​​できます (この例では、テスト用に Prometheus バックエンドを備えた Grafana からデータが取得されました)。 正常なシャットダウンの問題は、ベンチマークが生成する可能性のある高負荷の下で明確に確認でき、モニタリングはテスト中またはテスト後に状況をより詳細に分析するのに役立ちます。

記事に対するフィードバックへの回答: ここでは、問題と解決策が NGINX Ingress に関連して説明されていることを言及する価値があります。 他のケースについては、他の解決策があり、シリーズの次の資料で検討する可能性があります。

PS

K8s のヒントとテクニック シリーズのその他:

• «NGINX Ingress のカスタム エラー ページ";
• «Web アプリケーションのノード割り当てと負荷について";
• «開発サイトへのアクセス";
• «大規模データベースのブートストラップを高速化する'。

出所： habr.com