Kubernetes のライブネスと準備状況のプローブ

回復力は、ミッションクリティカルで可用性の高いアプリケーションを設計する際に考慮すべき最も重要な要素の 1 つです。

アプリケーションは、障害から迅速に回復できる場合、回復力があると言えます。

クラウド ネイティブ アプリケーションは、多くの場合、各コンポーネントがコンテナー内に存在するマイクロサービス アーキテクチャを使用して設計されます。 Kubernetes でホストされるアプリケーションの高可用性を確保するには、クラスターを設計するときにいくつかの特定のパターンに従う必要があります。その 1 つが「ヘルス検出パターン」です。高観測性原則 (HOP) を適用すると、アプリケーションが受信するすべてのリクエストに対して、タイムリーに応答が返されるようになります。

高可観測性原則 (HOP)

高い可観測性の原則は、コンテナベースのアプリケーションの設計原則の 1 つです。マイクロサービス システムでは、各サービスが、呼び出された側がリクエストをどのように処理するかを気にしない (気にするべきではない) 必要があります。

HOP 原則では、各サービスが複数の API エンドポイントを公開することが要求され、サービスの健全性状態を明らかにすることを目的としています。 Kubernetes はこれらのエンドポイントを呼び出して、ルーティングと負荷分散の次のステップを決定します。

適切に設計されたクラウドネイティブ プログラムは、ログ イベントを STDERR と STDOUT に記録し、logstash や Fluent などのログ取り込みサービスは、これらのログを集中監視システム (Prometheus など) やログ集約システム (ELK など) に送信する必要があります。次の図は、クラウド ネイティブ アプリケーションが正常性検出パターンと高可観測性の原則にどのように準拠しているかを示しています。

Kubernetes でヘルス プローブ パターンを適用するにはどうすればよいでしょうか?

以前、ASP.NetCore + Docker ヘルス チェックに関するオリジナル記事を書きました: [Web プログラムが http ヘルス チェック エンドポイント、プラットフォーム ポーリング検出を公開]。 Kubernetes はさまざまな状況に合わせてプローブを改良し、さらに強力なのは対応する決定を下すことです。

生体プローブ

[survival probe] を使用して、コンテナをいつ再起動するかを決定します。

サバイバル プローブを使用して、コンテナー自体が応答していないか、デッドロック状態になっているかどうかを確認します。コンテナを再起動すると、このような問題が解決できることがよくあります。

公式の Kubernetes デモを例に挙げてみましょう。

 APIバージョン: v1
種類: ポッド
メタデータ:
  ラベル:
    テスト: 活性
名前: liveness -exec  
仕様:
  コンテナ:
  -名前: ライブネス
    画像: ビジーボックス
    引数:
    - /bin/sh - -c - /tmp/healthy をタッチします。睡眠30; rm -rf /tmp/healthy;睡眠600
    ライブネスプローブ:
実行:
        指示：
        - 猫
        - /tmp/健康
      initialDelaySeconds: 5 # 最初の検出を実行する前に 5 秒間待機するように kubectl に指示します
      periodSeconds: 5 # 5秒ごとにポーリング

• 5秒後、kubectlは最初の生存検出を開始する。
• 30秒以内に実行されたすべてのプローブは成功しました
• 30 秒後、コンテナ内のファイルは削除され、5 秒ごとの検出は失敗します。ライブネスのデフォルト設定によれば、3 回連続して失敗すると検出は中止されます。検出を中止するとコンテナが再起動されるため、コンテナは 45 秒後に再起動されます。
• 再起動後、上記のプロセスが再び開始されるため、このプローブは再起動を決定してアプリケーションの問題を修復しようとしていることがわかります。

このプローブはkubectl get podのRESTARTS列に反映されます。

準備プローブ

[準備状況プローブ] を使用して、コンテナの準備が整っていてトラフィックを受け入れることができるかどうかを判断します。

Pod 内のすべてのコンテナが準備完了の場合、Pod は準備完了とみなされます。 Pod の準備ができていない場合、サービス ロード バランシングから削除されます。

アプリケーションが一時的に利用できなくなる場合があります (大量のデータを読み込んでいる場合や外部サービスに依存している場合)。現時点では、Pod を再起動しても役に立たず、リクエストが Pod に送信されないようにする必要があります。

以下のアプリケーションは mongodb に大きく依存しています。これらの依存関係に対して準備プローブを設定します。

サービス.AddHealthChecks()
    .AddCheck<MongoHealthCheck>(nameof(MongoHealthCheck)、タグ: new[] { "readyz" });
 // ----------------------  
 app.UseHealthChecks( "/readyz" 、新しいHealthCheckOptions
 {
        述語 = ( check ) => check .Tags. （ 「readyz」 ）を含む
});

以下はMongodbの接続を検出するためのものです

シールクラス MongoHealthCheck : IHealthCheck
    { プライベート読み取り専用 IMongoDatabase _defaultMongoDatabase;
パブリックMongoHealthCheck(IDefaultMongoDatabaseProvider デフォルトMongoDatabaseProvider)
        _defaultMongoDatabase = defaultMongoDatabaseProvider.GetDatabase(); }パブリック非同期 Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext コンテキスト、 CancellationToken cancellationToken =デフォルト)
        { var doc = _defaultMongoDatabase.RunCommandAsync( を待機します
                新しい BsonDocumentCommand<BsonDocument>(
                    新しいBsonDocument() {
                        { "ping" 、 "1" }
                    })、キャンセルトークン: キャンセルトークン); var ok = doc[ "ok" ].ToBoolean();
            もし（大丈夫）
            { HealthCheckResult.Healthy( "OK" )を返します。
            } HealthCheckResult.Unhealthy( "NotOK" )を返します。
        } }

依存関係の検出では、検出サイクルとタイムアウトを少し長く設定できます。

準備プローブ:
  httpGet:
    パス: /readyz
    ポート: 80
  初期遅延秒数: 5
  periodSeconds: 60 # 60秒ごとに1回検出
  timeoutSeconds: 30 # 各検出には 30 秒のタイムアウトがあり、これはアプリケーションが依存関係との接続を確立するまでのタイムアウトと一致します。
  failureThreshold: 3 # 検出が3回連続して失敗した場合、Podは「Unready」としてマークされます

スタートアッププローブ

[スタートアップ プローブ] を使用して、コンテナ アプリケーションが起動されているかどうかを判断します。このプローブが設定されている場合、このプローブが成功するまで、活性プローブと準備プローブは無効になります。

プローブの設定

• initialDelaySeconds: コンテナが起動すると、プローブは遅延後に動作します。デフォルト値は0秒です
• periodSeconds プローブ検出期間、デフォルトは 10 秒
• timeoutSeconds: プローブのタイムアウト期間。デフォルトは1秒です。
• successThreshold: プローブは、連続して数回の検出が成功した後に成功したと見なされます。デフォルト値は1です
• failureThreshold: プローブが連続して複数回失敗すると、プローブは最終的に失敗したとみなされます。 livenes プローブの場合、最終的な失敗は再起動を意味します。準備状況プローブの場合、ポッドの準備ができていないことを意味します。デフォルトは3回です。

非現実的な識別エラーによる頻繁な再起動や準備不能状態を回避するために、アプリケーション構造に応じてプローブ パラメータを適切に設定することを強くお勧めします。

結論は：

• Kubernetes エコシステムは非常に大きいのに、なぜ k8s プローブだけに注目するのでしょうか? k8s プローブはアプリケーション構造に密接に関連するメカニズムであるためです。

使用法に関して：

• サバイバル プローブ: アプリケーション プロセスが応答していないかどうかを迅速に判断し、再起動して修復を試みるために使用されます。
• 準備状況プローブ: アプリケーションとその依存関係の準備ができているかどうか、およびトラフィックを割り当てることができるかどうかを判断します。そうでない場合は、Unready としてマークし、ロードバランサーから Pod を削除します。

Kubernetes のライブネス プローブと準備プローブにより、サービスの堅牢性と回復力が大幅に向上し、優れたエンドユーザー エクスペリエンスが実現します。