Kubernetes の Liveness Probe は危険な可能性があります

ノート。 翻訳。：Zalando のリード エンジニアである Henning Jacobs は、Kubernetes ユーザーの間で liveness (および readiness) プローブの目的とその正しい使用方法を理解する際に問題があることに繰り返し気づいてきました。 したがって、彼は自分の考えをこの分厚いメモにまとめました。これは最終的に K8s ドキュメントの一部になります。

ヘルスチェック。Kubernetes では次のように呼ばれます。 活性プローブ (つまり、文字通り「生存性テスト」 - おおよその翻訳)、非常に危険な可能性があります。 可能であれば、それらを避けることをお勧めします。唯一の例外は、それらが本当に必要で、その使用の詳細と結果を十分に理解している場合です。 この出版物では、稼働状況と準備状況のチェックについて説明し、どのような場合に当てはまるかについても説明します。 コスト そしてそれらを使用すべきではありません。

私の同僚の Sandor は最近、readiness/liveness プローブの使用に関連するエラーなど、遭遇する最も一般的なエラーを Twitter で共有しました。

正しく構成されていない livenessProbe 高負荷状況 (雪だるま式シャットダウン + コンテナ/アプリケーションの起動時間が長くなる可能性) を悪化させ、依存関係の低下などの他の悪影響を引き起こす可能性があります。 (こちらも参照 私の最近の記事 K3s+ACME の組み合わせでのリクエスト数の制限について)。 liveness プローブを外部データベースであるヘルスチェックと組み合わせると、状況はさらに悪化します。 単一の DB 障害が発生すると、すべてのコンテナが再起動されます!

一般的なメッセージ 「活性プローブを使用しないでください」 この場合、それはあまり役に立たないので、readiness チェックと liveness チェックが何のために行われるかを見てみましょう。

注: 以下のテストの大部分は、もともと Zalando の内部開発者ドキュメントに含まれていました。

準備状況と活性度のチェック

Kubernetes は、次の XNUMX つの重要なメカニズムを提供します。 liveness プローブと readiness プローブ。 アプリケーションが期待どおりに動作していることを確認するために、HTTP リクエストの送信、TCP 接続のオープン、コンテナ内でのコマンドの実行などの何らかのアクションを定期的に実行します。

Kubernetes の使用法 レディネスプローブコンテナがいつトラフィックを受け入れる準備ができているかを理解します。 すべてのコンテナーの準備ができている場合、ポッドは使用可能であるとみなされます。 このメカニズムの使用法の XNUMX つは、Kubernetes サービス (特に Ingress) のバックエンドとして使用されるポッドを制御することです。

活性プローブ Kubernetes がコンテナを再起動する時期を理解できるようにします。 たとえば、このようなチェックを使用すると、アプリケーションが XNUMX つの場所でスタックした場合にデッドロックを阻止できます。 この状態でコンテナを再起動すると、エラーがあってもアプリケーションを開始できますが、連鎖的な障害が発生する可能性もあります (以下を参照)。

ライブネス/準備状況チェックに失敗したアプリケーション更新をデプロイしようとすると、Kubernetes がステータスを待機するため、そのロールアウトは停止します。 Ready すべてのポッドから。

例

これは、パスをチェックする Readiness Probe の例です。 /health デフォルト設定の HTTP 経由 (インターバル： 10秒、 タイムアウト： 1秒、 成功のしきい値：1、 障害のしきい値: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

提言

1. HTTP エンドポイントを備えたマイクロサービス (REST など) の場合 常に Readiness プローブを定義する、アプリケーション (ポッド) がトラフィックを受け入れる準備ができているかどうかを確認します。
2. Readiness Probe を確認してください 実際の Web サーバー ポートの可用性をカバーします。:
   • 「admin」または「management」と呼ばれる管理目的のポート (9090 など) を使用します。 readinessProbe、プライマリ HTTP ポート (8080 など) がトラフィックを受け入れる準備ができている場合にのみ、エンドポイントが OK を返すようにしてください*。

     *私は、これが起こらなかったザランドでの少なくとも XNUMX つのケースを知っています。 readinessProbe 「管理」ポートを確認しましたが、キャッシュのロードに問題があったため、サーバー自体が動作し始めませんでした。

   • Readiness Probe を別のポートに接続すると、メイン ポートの過負荷がヘルス チェックに反映されなくなる可能性があります (つまり、サーバー上のスレッド プールがいっぱいであっても、ヘルス チェックではすべてが正常であることが示されます)。 ）。
3. それを確認してください readiness Probe によりデータベースの初期化/移行が可能になります;
   • これを実現する最も簡単な方法は、初期化が完了した後でのみ HTTP サーバーに接続することです (たとえば、データベースを移行するなど)。 フライウェイ 等々。）; つまり、ヘルス チェックのステータスを変更するのではなく、データベースの移行が完了するまで Web サーバーを起動しないだけです*。

     * ポッドの外部の init コンテナからデータベース移行を実行することもできます。 私は今でも自己完結型アプリケーション、つまりアプリケーション コンテナが外部調整なしでデータベースを望ましい状態にする方法を知っているアプリケーションのファンです。

4. 使用 httpGet 一般的なヘルス チェック エンドポイント (たとえば、 /health).
5. デフォルトのチェックパラメータを理解する (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • デフォルトのオプションでは、ポッドは次のようになります。 準備ができていない 約 30 秒後 (健全性チェックが 3 回失敗)。
6. テクノロジー スタック (Java/Spring など) で許可されている場合は、「admin」または「management」に別のポートを使用して、正常性とメトリクスの管理を通常のトラフィックから分離します。
   • ただし、ポイント 2 を忘れないでください。
7. 必要に応じて、readiness プローブを使用してキャッシュをウォームアップ/ロードし、コンテナーがウォームアップするまで 503 ステータス コードを返すことができます。
   • 新しいチェックも読むことをお勧めします startupProbe, バージョン1.16で登場 （私たちはそれについてロシア語で書きました） ここで — 約翻訳）.

警告

1. 外部依存関係に依存しない (データ ウェアハウスなど) 準備/活性テストの実行時 - これにより、連鎖的な障害が発生する可能性があります。
   • 例として、10 つの Postgres データベースに依存する 10 個のポッドを持つステートフル REST サービスを考えてみましょう。チェックが DB への動作中の接続に依存する場合、ネットワーク/DB 側で遅延があると、XNUMX 個のポッドすべてが失敗する可能性があります。通常は、すべては想像以上に悪い結末を迎えます。
   • Spring Data はデフォルトでデータベース接続をチェックすることに注意してください*。

     * これは Spring Data Redis のデフォルトの動作です (少なくとも私が最後に確認したときはそうでした)。これにより「壊滅的な」障害が発生しました。つまり、Redis が短時間利用できなくなると、すべてのポッドが「クラッシュ」しました。

   • この意味での「外部」は、同じアプリケーションの他のポッドを意味することもあります。つまり、連鎖的なクラッシュを防ぐために、チェックは同じクラスターの他のポッドの状態に依存しないことが理想的です。
     • 分散状態のアプリケーション (ポッド内のメモリ内キャッシュなど) では結果が異なる場合があります。
2. liveness プローブを使用しないでください ポッドの場合 (例外は、ポッドが本当に必要で、その使用の詳細と結果を十分に認識している場合です):
   • liveness プローブはハングしたコンテナの回復に役立ちますが、アプリケーションを完全に制御できるため、ハングしたプロセスやデッドロックのような事態は理想的には発生しないはずです。最良の代替策は、アプリケーションを意図的にクラッシュして以前の定常状態に戻すことです。
   • liveness プローブが失敗するとコンテナが再起動され、それによって読み込み関連のエラーの影響が悪化する可能性があります。コンテナを再起動するとダウンタイムが発生し (少なくともアプリケーションの起動中、たとえば 30 数秒間)、新たなエラーが発生します。 、他のコンテナへの負荷が増加し、それらのコンテナが失敗する可能性が増加するなど。
   • liveness チェックと外部依存関係の組み合わせは最悪の組み合わせであり、連鎖的な障害が発生する恐れがあります。データベース側でのわずかな遅延がすべてのコンテナの再起動につながります。
3. liveness チェックと readiness チェックのパラメータ 違うはずだ:
   • 同じヘルスチェックで liveness プローブを使用できますが、応答しきい値が高くなります (failureThreshold)、たとえばステータスを割り当てます。 準備ができていない 3 回の試行後、liveness プローブは 10 回の試行後に失敗したとみなします。
4. 実行チェックを使用しないこれらは、ゾンビ プロセスの出現につながる既知の問題に関連しているためです。
   • 詳細: 参照 Datadog スペシャリストによるプレゼンテーション.

サマリー

• readiness プローブを使用して、ポッドがいつトラフィックを受信できるかを判断します。
• liveness プローブは、本当に必要な場合にのみ使用してください。
• readiness/liveness プローブを不適切に使用すると、可用性の低下や連鎖的な障害が発生する可能性があります。

トピックに関する追加資料

• Kubernetes ドキュメント: Liveness プローブと Readiness プローブの構成;
• Kubernetes Liveness プローブと Readiness プローブの再考: 不当な攻撃を避ける方法;
• NRE Labs の停止後の事後分析 (彼は livenessProbe についても話しています)。

1-2019-09 更新第 29 号

データベース移行の初期コンテナについて: 脚注を追加しました。

EJが思い出させてくれた PDB について: 活性チェックの問題の XNUMX つは、ポッド間の調整が欠如していることです。 Kubernetes には ポッド中断予算 (PDB) アプリケーションが同時に発生する可能性のある障害の数を制限しますが、チェックでは PDB は考慮されません。 理想的には、K8 に「テストが失敗した場合は XNUMX つのポッドを再起動するが、状況の悪化を避けるためにすべてのポッドを再起動しないでください」と指示できます。

ブライアンはそれを完璧に言い表した: 「何が正確にわかっている場合は、活性プローブを使用してください 最善の策はアプリケーションを強制終了することです「（繰り返しますが、調子に乗らないでください）。

2-2019-09 更新第 29 号

ご使用前の説明書の閲覧について: 対応するリクエストを作成しました (機能リクエスト) liveness プローブに関するドキュメントを追加します。

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes: ポッドライフ";
• «Google によるコンテナ使用に関する 7 つのベスト プラクティス";
• «コンテナベースのアプリケーションを設計するための 7 つの原則'。

出所： habr.com