Kubernetes のベスト プラクティス。 Readiness および Liveness テストによる Kubernetes の Liveness の検証

Kubernetes のベスト プラクティス。 小さなコンテナの作成
Kubernetes のベスト プラクティス。 名前空間を使用した Kubernetes の構成

分散システムには、システムが機能するためにすべてが適切に動作する必要がある、多くの移動および変化する要素があるため、管理が難しい場合があります。 いずれかの要素に障害が発生した場合、システムはそれを検出し、バイパスして修正する必要があり、これらすべてが自動的に行われる必要があります。 この Kubernetes ベスト プラクティス シリーズでは、Kubernetes クラスターの健全性をテストするための Readiness テストと Liveness テストを設定する方法を学びます。

ヘルスチェックは、アプリケーションインスタンスが実行されているかどうかをシステムに知らせる簡単な方法です。 アプリケーション インスタンスがダウンしている場合、他のサービスはそのインスタンスにアクセスしたり、リクエストを送信したりしてはなりません。 代わりに、リクエストは、すでに実行されているか、後で起動されるアプリケーションの別のインスタンスに送信する必要があります。 さらに、システムはアプリケーションの失われた機能を復元する必要があります。

デフォルトでは、Kubernetes はポッド内のすべてのコンテナーが実行されているときにポッドへのトラフィックの送信を開始し、クラッシュするとコンテナーを再起動します。 最初はこのデフォルトのシステム動作で十分かもしれませんが、カスタム健全性チェックを使用することで製品展開の信頼性を向上させることができます。

幸いなことに、Kubernetes ではこれを非常に簡単に実行できるため、これらのチェックを無視する言い訳はできません。 Kubernetes には XNUMX 種類のヘルスチェックが用意されており、それぞれの使用方法の違いを理解することが重要です。

Readiness テストは、アプリケーションがトラフィックを処理する準備ができていることを Kubernetes に伝えるように設計されています。 サービスがポッドにトラフィックを送信できるようにする前に、Kubernetes は準備状況チェックが成功したことを確認する必要があります。 Readiness テストが失敗した場合、Kubernetes はテストに合格するまでポッドへのトラフィックの送信を停止します。

Liveness テストは、アプリケーションが生きているのか死んでいるのかを Kubernetes に伝えます。 前者の場合、Kubernetes はポッドをそのままにし、後者の場合、死んだポッドを削除して新しいポッドに置き換えます。

アプリケーションのウォームアップと起動に 1 分かかるシナリオを想像してみましょう。 ワークフローはすでに開始されていますが、アプリケーションが完全にロードされて実行されるまで、サービスは動作し始めません。 また、この展開を複数のコピーにスケールアップする場合にも問題が発生します。これらのコピーは完全に準備が整うまでトラフィックを受信すべきではないためです。 ただし、デフォルトでは、Kubernetes はコンテナ内のプロセスが開始されるとすぐにトラフィックの送信を開始します。

Readiness テストを使用する場合、Kubernetes はアプリケーションが完全に実行されるまで待機してから、サービスが新しいコピーにトラフィックを送信できるようにします。

アプリケーションが長時間ハングし、リクエストの処理が停止する別のシナリオを想像してみましょう。 プロセスが実行を続けると、デフォルトで Kubernetes はすべてが正常であるとみなし、動作していないポッドにリクエストを送信し続けます。 ただし、Liveness を使用すると、Kubernetes はアプリケーションがリクエストを処理しなくなったことを検出し、デフォルトで停止したポッドを再起動します。

準備状況と実行可能性がどのようにテストされるかを見てみましょう。 HTTP、コマンド、TCP の XNUMX つのテスト方法があります。 それらのいずれかを使用して確認できます。 ユーザーをテストする最も一般的な方法は、HTTP プローブです。

アプリケーションが HTTP サーバーでない場合でも、Liveness テストと対話するためにアプリケーション内に軽量の HTTP サーバーを作成できます。 この後、Kubernetes はポッドへの ping を開始し、HTTP 応答が 200 または 300 ミリ秒の範囲にある場合は、ポッドが正常であることを示します。 それ以外の場合、モジュールは「異常」としてマークされます。

コマンド テストの場合、Kubernetes はコンテナー内でコマンドを実行します。 コマンドが終了コード 1 を返した場合、コンテナーは正常であるとマークされます。それ以外の場合は、255 ～ XNUMX の終了ステータス番号を受け取ると、コンテナーは「病気」とマークされます。 このテスト方法は、HTTP サーバーを実行できない、または実行したくないが、アプリケーションの正常性をチェックするコマンドを実行できる場合に役立ちます。

最後の検証メカニズムは TCP テストです。 Kubernetes は、指定されたポートで TCP 接続の確立を試みます。 これが可能であればコンテナは健全であるとみなされ、そうでなければ実行不可能とみなされます。 この方法は、HTTP リクエストまたはコマンド実行によるテストがうまく機能しないシナリオを使用している場合に役立ちます。 たとえば、TCP を使用した検証の主なサービスは gRPC または FTP です。

テストは、さまざまなパラメーターを使用していくつかの方法で構成できます。 実行頻度、成功と失敗のしきい値、応答を待つ時間を指定できます。 詳細については、Readiness テストと Liveness テストのドキュメントを参照してください。 ただし、Liveness テストの設定には非常に重要なポイントが 99 つあります。それは、テスト遅延の初期設定、initialDelaySeconds です。 前述したように、このテストに失敗するとモジュールが再起動されます。 したがって、アプリケーションの準備が整うまでテストを開始しないようにする必要があります。そうしないと、アプリケーションが再起動を繰り返すことになります。 PXNUMX の起動時間、またはバッファーからの平均アプリケーション起動時間を使用することをお勧めします。 アプリケーションの起動時間が速くなったり遅くなったりする場合は、この値を忘れずに調整してください。

ほとんどの専門家は、ヘルスチェックは分散システムにとって必須のチェックであり、Kubernetes も例外ではないことを認めています。 サービス ヘルス チェックを使用すると、Kubernetes の信頼性が高く、問題なく動作することが保証され、ユーザーにとっては簡単です。

続きはまたすぐに…

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com