Clever Geek Handbook

Kubernetesサンプルの理解：タイプ、構成、およびベストプラクティス



出典



この記事は、Kubernetes aaSチームによって翻訳された、異常なモジュールを検出して処理するための準備、正常性、および起動プローブの構成に関するものです。



Kubernetesの検証が必要な理由



分散システムとマイクロサービスアーキテクチャの課題の1つは、障害のあるアプリケーションの自動検出、他の利用可能なシステムへの要求のリダイレクト、および損傷したコンポーネントの修復です。ヘルスチェックは、この問題を解決して信頼性を確保する1つの方法です。 Kubernetesでは、プローブを使用してヘルスチェックを構成し、各ポッドのステータスを判別します。



デフォルトでは、Kubernetesはポッドのライフサイクルを監視し、コンテナが保留から成功に移行すると、ポッドへのトラフィックのルーティングを開始します。 Kubeletはまた、アプリケーションのクラッシュを監視し、回復のためにモジュールを再起動します。



多くの開発者は、特にモジュール内のアプリケーションがNode.js用のPM2などのプロセスマネージャーを使用して構成されている場合は、この基本的なセットアップで十分であると考えています。



ただし、Kubernetesはモジュールが正常でリクエストの準備ができていると見なすため、すべてのコンテナが開始されるとすぐに、アプリケーションは実際に準備ができる前にトラフィックの受信を開始できます。これは、アプリケーションがアプリケーションロジックを処理する前に、ある状態を初期化する、データベース接続を確立する、またはデータをロードする必要がある場合に発生する可能性があります。



アプリケーションが実際に利用可能になってから、Kubernetesがアプリケーションの準備ができていると見なすまでのこの時間は、展開の拡張が開始され、準備されていないアプリケーションがトラフィックを受信して​​500エラーを送り返すときに問題になります。



ここで、Kubernetesプローブを使用して、コンテナがトラフィックを受け入れる準備ができたときと、再起動する必要があるときを判断します。Kubernetes 1.16以降、3種類のプローブがサポートされています。



この記事では、さまざまなタイプのプローブ、および潜在的な構成の問題がある展開を検出するためのベストプラクティスとツールについて説明します。



Kubernetesプローブ



Kubernetesは、バージョンが1.15以下の準備およびヘルスプローブをサポートします。起動プローブは1.16でアルファ機能として追加され、1.18でベータ版になりました。



警告：バージョン1.16では、KubernetesAPIの一部が非推奨になりました。この移行ガイドを使用して、互換性を確認してください。



すべてのサンプルには、次のパラメータがあります。



  • initialDelaySeconds



    : ;
  • periodSeconds



    : ;
  • timeoutSeconds



    : - ( );
  • successThreshold



    : , ;
  • failureThreshold



    : . . , .




準備プローブは、アプリケーションが新しいトラフィックを受け入れる準備ができたことをkubeletに通知するために使用されます。プロセスの開始後にアプリケーションの初期化に時間がかかる場合は、準備プローブを設定して、Kubernetesが新しいトラフィックを送信する前に待機するようにします。準備プローブの主な使用例は、サービスの展開にトラフィックを転送することです。





ソース



準備プローブはモジュールの存続期間を通じて機能することを覚えておくことが重要です。これは、起動時だけでなく、モジュールの動作時間全体を通して再び起動されることを意味します。



これは、ビッグデータのロードや外部接続の待機など、アプリケーションが一時的に利用できない状況で必要になります。この場合、アプリケーションを強制終了したくはありませんが、復元されるまで待ちます。準備プローブは、このシナリオを検出するために使用され、準備チェックに再度合格するまで、これらのモジュールにトラフィックを送信しません。



パフォーマンステスト



ヘルスプローブは、異常なコンテナを再起動するために使用されます。Kubeletは定期的にヘルステストを呼び出し、ポッドのヘルスを検出し、ヘルスチェックに失敗した場合はポッドを強制終了します。



トライアルは、アプリケーションがデッドロックから抜け出すのに役立ちます。ヘルスチェックがない場合、メインプロセスはKubernetesの観点から実行され続けるため、Kubernetesは正常な状態でロックされていると見なします。ヘルスプローブを設定することにより、kubeletはアプリケーションが不良状態にあることを検出し、ポッドを再起動して可用性を復元します。





ソース



サンプルの起動



起動テストは準備完了テストに似ていますが、起動時にのみ実行されます。これらは、予測できない初期化プロセスを伴うコンテナまたはアプリケーションの起動が遅い場合に最適化されています。準備プローブを使用すると、準備をinitialDelaySeconds



確認する前に待機する時間を決定するために微調整できます。



ここで、プロセスの開始時に大量のデータをロードしたり、リソースを大量に消費する操作を実行したりする必要があるアプリケーションについて考えてみます。これinitialDelaySeconds



は静的な数値であるfailureThreshold



ため、このアプリケーションが長い初期化を実行する必要がない場合でも、常に最悪のシナリオを取り（または値を大きくすると、さらなる動作に影響を与える可能性があります）、長時間待つ必要があります。



代わりに、起動プローブを使用して、構成できますfailureThreshold



そしてperiodSeconds



、この不確実性をより適切に処理するために。たとえばfailureThreshold



、15とperiodSeconds



5の設定は、障害が診断される前にアプリケーションを開始するのに15 x 5 = 75秒かかることを意味します。



サンプルセットアップ



さまざまなタイプのサンプルを理解したので、各サンプルを設定する3つの異なる方法を検討できます。



HTTP



Kubeletは指定されたURLにHTTPGET要求を送信し、2xxまたは3xx応答をチェックします。既存のHTTPエンドポイントを使用するか、テスト用に軽量のHTTPサーバーを構成できます（たとえば、エンドポイントを備えたExpressサーバー/healthz



）。



HTTPプローブは、追加のパラメーターを取ります。



  • host



    ：接続用のホスト名（デフォルトでは、これはモジュールのIPアドレスです）。
  • scheme



    ：デフォルトのHTTPまたはHTTPS。
  • path



    ：HTTP / Sサーバー上のパス。
  • httpHeaders



    ：認証、CORS設定などにヘッダー値が必要な場合はカスタムヘッダー
  • port



    ：サーバーにアクセスするための名前またはポート番号。


livenessProbe:
  httpGet:
    path: /healthz
    port: 8080


TCP



TCP接続を確立できるかどうかを確認する必要がある場合は、TCPプローブを使用してください。モジュールがTCP接続を確立できる場合、そのモジュールは正常としてマークされます。TCPプローブの使用は、HTTP呼び出しが適切でないgRPCまたはFTPサーバーに役立ちます。 



readinessProbe:
  tcpSocket:
    port: 21


コマンド



シェルコマンドを実行するようにプローブを構成することもできます。コマンドが終了コード0で戻った場合、チェックは合格です。それ以外の場合、モジュールは障害としてマークされます。



このタイプのチェックは、HTTPサーバー/ポートを開きたくない場合、またはコマンドを使用して初期化手順をチェックする方が簡単な場合に役立ちます。たとえば、構成ファイルが作成されたかどうかを確認するか、CLIコマンドを実行します。 



readinessProbe:
  exec:
    command: ["/bin/sh", "-ec", "vault status -tls-skip-verify"]


Kubernetesをサンプリングするためのベストプラクティス



正確なサンプルパラメータはアプリケーションによって異なりますが、開始するための一般的なガイドラインは次のとおりです。



  1. 古い（≤1.15）Kubernetesクラスターの場合は、初期ラグレディプローブを使用してコンテナーの起動フェーズを処理します。これを行うには、99％のパーセント時間を使用します。ただし、準備テストはモジュールの存続期間を通じて実行されるため、このチェックを簡単にしてください。準備チェックに時間がかかるため、プローブがタイムアウトしないようにします。
  2. (≥ 1.16) Kubernetes . (, /healthz



    ), . failureThreshold



    , , . .
  3. , . , , , . .
  4. , . , , , . , .


要するに、明確に定義されたプローブは通常、安定性と可用性を向上させます。アプリケーションの変更に応じてサンプル設定を調整するために、起動時間とシステムの動作を必ず追跡してください。



ツール



Kubernetesプローブの重要性を考えると、Kubernetesリソース分析ツールを使用して、欠落しているプローブを見つけることができます。これらのツールは、既存のクラスターで実行するか、CI / CDプロセスに組み込んで、適切に構成されたリソースなしでワークロードの展開に自動的に失敗する可能性があります。



  • ポラリスは、検証のウェブフックまたはコマンドラインツールとして使用することができます美しいツールバーとリソースの分析ユーティリティです。
  • kube-scoreは、Helm、Kustomize、および標準のYAMLファイルで機能する静的コード分析ツールです。
  • popeyeは、Kubernetesクラスターをスキャンし、潜在的な構成の問題を報告する読み取り専用のユーティリティツールです。


これらの2つのテレグラムチャネルでは、KubernetesaaSからのニュースと@Kubernetesミートアップイベントの発表を見つけることができます。



他に読むべきこと：





More articles:


All Articles