ポッド内のヘルスチェックの活性、準備、startupProbe

ポッドを作成するときは、活気と準備を使用して、ポッドの内部コンテナーの操作を検出できます。
1.活性度を使用して、コンテナー内のアプリケーションの存続をチェックし、コンテナーが実際に「実行中」であるかどうか、つまり「ライブ検出」を検出できます。チェックが失敗した場合、kubeletはコンテナプロセスを強制終了し、コンテナを停止します。コンテナを再起動するかどうかは、ポッドの再起動戦略によって異なります。
2.準備完了は、コンテナー内のアプリケーションが通常、外部にサービスを提供できるかどうか、つまり「準備完了」かどうかを確認します。たとえば、nginxコンテナーは、リロード構成中に外部にHTTPサービスを提供できません。検出が失敗した場合、エンドポイントコントローラーはポッドのIPをサービスから削除します。
3. startupProbeを使用して、上記のコンテナーのスロースタートの例のように、コンテナーが開始されたかどうかを判別できます。パラメータを使用して、「非常に長い」起動時間を処理するのに十分な時間を確保できます。検出に失敗した場合の動作はlivenessProbeと同じです。このプローブはバージョン1.16でのみ追加され、バージョン1.18でベータ版になりました。つまり、Kubernetesのバージョンが1.18未満の場合は、kube-apiserverの起動パラメーターの機能ゲートでこの関数を明示的に有効にする必要があります。このドキュメントを参照して、このパラメーターの構成方法を確認できます。

3つのプローブすべてに次のパラメーターがあります
。initialDelaySeconds:活性および準備プローブを開始する前に待機する秒数。
periodSeconds:プローブの周波数を確認します。
timeoutSeconds:プローブをタイムアウト(ヘルスチェックに失敗)としてマークするまでの秒数。
successThreshold:プローブが合格する必要のある連続した成功したチェックの最小数。
failureThreshold:プローブを失敗としてマークするまでの再試行回数。活性プローブの場合、これによりポッドが再起動します。準備プローブの場合、ポッドは準備完了としてマークされます。

準備プローブ

準備プローブにより、kubeletは、アプリケーションが新しいトラフィックを受け入れる準備ができたことを知ることができます。プロセスの開始後にアプリケーションが状態を初期化するのに時間がかかる場合は、Kubernetesが新しいトラフィックを送信する前に待機するように準備プローブを設定します。準備プローブの主な機能は、サービス後にトラフィックをデプロイメントに転送することです。
レディネスプローブの重要な点の1つは、コンテナのライフサイクル全体で実行されることです。これは、準備プローブが起動時に実行されるだけでなく、ポッドの実行中にも繰り返し実行されることを意味します。これは、アプリケーションが一時的に使用できない状況(大量のデータをロードするとき、外部接続を待機するときなど)を処理するためです。この場合、アプリケーションを強制終了する必要はありません。アプリケーションが回復するのを待つことができます。準備プローブを使用して、この状況を検出し、準備チェックに再度合格した後、これらのポッドにトラフィックを送信できます。

活性プローブ

活性プローブは、異常なコンテナを再起動するために使用されます。Kubeletは定期的に活性プローブにpingを実行してヘルスステータスを判断し、活性チェックが失敗した場合はポッドを強制終了します。活性チェックは、アプリケーションがデッドロックから回復するのに役立ちます。活性チェックが実行されない場合、Kubernetesの観点からは、ポッドの子プロセスはまだ実行中であり、正常であるため、Kubernetesはデッドロック状態のポッドが正常な状態にあると見なします。活性プローブを構成することにより、kubeletはアプリケーションが異常な状態にあることを検出し、ポッドを再起動して可用性を復元できます。

スタートアッププローブ

起動プローブは準備プローブに似ていますが、起動時にのみ実行され、起動が遅いコンテナや初期化中に予期しない動作をするアプリケーション向けに最適化できます。準備プローブを使用すると、initialDelaySecondsを構成して、準備プローブが準備ができるまで待機する時間を決定できます。
たまに大量のデータをダウンロードする必要があるアプリケーションがあるとします。initialDelaySecondsは静的な数値であるため、アプリケーションがそれほど長い初期化待機時間を必要としない場合でも、最も控えめな待機時間を設定する必要があります。起動プローブを使用して、この問題を解決するためにfailureThresholdとperiodSecondsを構成できます。たとえば、failureThresholdを15に、periodSecondsを5に設定します。これは、アプリケーションが失敗するまでの起動時間が10x5 = 75sであることを意味します。

プローブを構成します

さまざまなタイプのプローブを理解したので、次に各プローブを構成する3つの異なる方法を示します。
HTTP
kubeletは、エンドポイントとチェックの2xxまたは3xxの応答にHTTP GETリクエストを送信します。既存のHTTPエンドポイントを再利用するか、検出用に軽量HTTPサーバーをセットアップできます(たとえば、/ healthzエンドポイントを備えたExpressサーバー)。HTTPプローブには、その他の追加パラメーターが含まれています。host:
接続するホスト名(デフォルト:ポッドのIP)。
スキーム:HTTP(デフォルト)またはHTTPS。
path:HTTP / Sサーバー上のパス。
httpHeaders:カスタムヘッダー(認証、CORS設定などにヘッダーが必要な場合)。
port:サーバーにアクセスするためのポート名またはポート番号。
ここに画像の説明を挿入します

TCP

TCP接続を確立できるかどうかを確認するだけでよい場合は、TCPプローブを指定できます。TCP接続が確立されると、ポッドは正常としてマークされます。HTTPプローブの使用に適していないgRPCまたはFTPサーバーの場合、TCPプローブが役立つ場合があります。

コマンド

プローブは、シェルコマンドを実行するように構成できます。コマンドによって返される終了コードが0の場合、チェックは合格です。それ以外の場合、ポッドは異常としてマークされます。このタイプのプローブは、HTTPサーバーとポートを公開したくない場合、またはコマンドを使用して初期化手順を確認する場合(たとえば、構成ファイルが作成されているかどうかを確認する場合、CLIコマンドを実行する場合)に役立ちます。
ここに画像の説明を挿入します

おすすめ

転載: blog.csdn.net/qq_34939308/article/details/111453128