【クラウドネイティブ】Kubernetes(k8s)ヘルスチェックの詳細解説と実践デモ(準備プローブと生存プローブ)

1. 概要

Kubernetes のヘルスチェックは、主に準備プローブと生存プローブを使用して実装されます。サービスは負荷分散です。 K8s は、サービスの背後にあるすべてのポッドが利用可能であることを保証します。これは、K8s における自己修復の主な手段です。これら 2 つの検出メカニズムに基づいて、次の要件を満たすことができます。

• 異常なインスタンスは自動的に削除され、新しいインスタンスが再起動されます
• 異常なポッドがトラフィックにアクセスしないようにするためのさまざまな種類のプローブ検出
• ノンストップのデプロイメント、より安全なローリングアップグレード

公式ドキュメント: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ Kubernetes (k8s) 環境のデプロイメントについては、私の記事を参照してください: Kubernetes (k8s) 環境デプロイメントの最新かつ最も完全なバージョン + マスター高可用性実装 (k8sV1.24.1+dashboard+harbor)

1) k8sのプローブの種類

1. 準備状況チェック (readinessProbe)

準備プローブ​ エンドポイントがトラフィックを受信する準備ができているかどうかを確認する準備チェック。準備ができている場合はエンドポイントに追加され、そうでない場合は削除されます。コンテナーが準備プローブを提供しない場合、デフォルトのステータスは成功です。

2. 生存チェック（livenessProbe）

ライブネスプローブ​ アプリケーションが利用可能かどうかを確認するオンラインチェックメカニズム。デッドロックや応答不能状態になった場合は、異常時の restartPolicy に従って Pod ステータスが設定され、コンテナが自動的に再起動されます。コンテナーが活性プローブを提供しない場合、デフォルトのステータスは成功です。

restartPolicy には 3 つのオプション値があります。

• 常に: コンテナが終了すると、常に再起動されます。これはデフォルトのポリシーです。
• OnFailure: コンテナが異常終了した場合にのみ (終了ステータス コードが 0 以外) コンテナが再起動されます。
• なし: コンテナが終了したときに、コンテナを再起動しません。

3. 起動チェック (startupProbe、起動プローブ、バージョン 1.17 の新機能)

• startupProbes 起動チェック メカニズムは、起動が遅い一部のサービスに適用され、サービスの起動に長い時間がかかったり、以前のプローブによって強制終了されたりすることを防ぎます。
• 主に具体的な起動時刻が特定できないアプリケーションの場合、コンテナ内のアプリケーションが起動されているかどうかを判断します。 startupProbes プローブが一致した場合、startupProbes ステータスが Success になるまで他のすべてのプローブは非アクティブになり、成功するまで他のプローブは機能しません。
• startupProbe が失敗した場合、kubelet はコンテナを強制終了し、コンテナは restartPolicy に従って再起動されます。コンテナーが startupProbe で構成されていない場合、デフォルトのステータスは Success です。実際、一般的に言えば、上記の 2 つのタイプを設定するだけで済みます。

準備プローブと生存プローブの違い:

ReadinessProbe と livenessProbe は同じ検出方法を使用できますが、Pod の処理は異なります。

• livenessProbe が検出に失敗した場合、コンテナを強制終了し、Pod の再起動戦略に基づいて対応する対策を決定します。
• readinessProbe がテストに失敗すると、Pod の IP:ポートが対応する EndPoint リストから削除されます。

2) k8sにおける3つの検出方法

各検出メカニズムは、コマンド ライン exec、httpGet、tcpSocket という 3 つのヘルス チェック メソッドをサポートしています。 exec は最も汎用性が高く、ほとんどのシナリオに適用できます。 tcpSocket は TCP サービスに適しており、httpGet は Web サービスに適しています。

• exec (カスタム ヘルス チェック): コンテナー内で指定されたコマンドを実行します。実行が成功し、終了コードが 0 の場合、検出は成功です。
• httpGet: コンテナーの IP アドレス、ポート番号、パスを使用して HTTP Get メソッドを呼び出します。応答ステータス コードが 200 以上 400 未満の場合、コンテナーは正常であると見なされます。
• tcpSocket: コンテナの IP アドレスとポート番号を使用して TCP チェックを実行します。 TCP 接続を確立できる場合、コンテナは正常です。

プローブ結果の値は次のとおりです。

• 成功: テストが合格したことを示します。
• 失敗: テストが失敗したことを示します。
• 不明: テストが正常に実行されなかったことを示します。

2. 準備プローブ

• 準備プローブは、コンテナ内のプログラムが稼働中 (または正常) かどうかを判断するために使用されます。プログラム（サービス）が正常な場合にのみ、コンテナは外部へのネットワーク アクセスの提供を開始します（起動が完了し、準備完了）。
• コンテナが起動されると、準備プローブ構成に従ってプローブが実行されます。問題がなければ、結果は成功、つまりステータスは Success になります。
• ポッドの READY ステータスは true で、0/1 から 1/1 に変わります。失敗が 0/1 のまま続く場合、ステータスは false になります。
• 準備プローブが構成されていない場合、起動後のコンテナのデフォルトのステータスは「成功」になります。このポッド、このポッドに関連付けられたサービス リソース、およびエンドポイント間の関係も、ポッドの準備完了ステータスに基づいて設定されます。
• Pod の操作中に Ready ステータスが false に変わると、システムはサービス リソースに関連付けられた EndPoint リストからこの Pod を自動的に削除します。サービス リソースが GET リクエストを受信すると、kube-proxy はこの Pod にトラフィックを導入しません。このメカニズムにより、利用できない Pod にトラフィックが転送されるのを防ぐことができます。
• ポッドが準備完了状態に戻った場合。エンドポイント リストに再度追加されます。また、kube-proxy がロード メカニズムを通じてこのポッドにトラフィックを導入する可能性もあります。

3. ライブネスプローブ

• 活性プローブは、コンテナが正常かどうかを判断するために使用されます。ヘルス条件が満たされない場合、Kubelet は Pod に設定された restartPolicy に基づいて Pod を再起動する必要があるかどうかを判断します。
• LivenessProbe は、構成 (プロセス、ポート、コマンドが正常に実行されたかどうかなど) に応じて検出し、コンテナーが正常かどうかを判断します。
• 検出できない場合は、コンテナが正常でないことを意味します (正常でないと判断されるまでの連続した失敗回数を設定できます)。その後、kubelet はコンテナを強制終了し、コンテナ再起動ポリシーに基づいて対応するアクションを実行します。
• 活性プローブが構成されていない場合、デフォルトのコンテナの起動は成功ステータスになります。つまり、プローブによって返される値は常に Success になります。つまり、成功後、ポッドのステータスは RUNING になります。

4. 実践的なデモンストレーション

よく使用されるプローブのオプション パラメータ:

1) execメソッド

 cat > exec - liveness .yaml << EOF
 APIバージョン: v1
種類:ポッド
メタデータ:
 ラベル:
 テスト:活性
 名前:ライブネス- exec
仕様:
 # テストの便宜上、スケジューリングマシンを指定します
 ノード名:ローカル- 168-182-110
 コンテナ:
 -名前:ライブネス
 イメージ: registry .aliyuncs .com / google_containers / busybox
 引数:
 - / bin / sh
 - -う
-タッチ/ tmp /健康;睡眠30 ; rm - f / tmp /正常;睡眠600
 ライブネスプローブ:
 実行:
 指示：
 -猫
- / tmp /健康
 初期遅延秒数: 5
 期間秒数: 5
終了

説明する：

• initialDelaySeconds フィールドは、最初のプローブを実行する前に 5 秒間待機する必要があることを kubelet に指示します。
• periodSeconds フィールドは、kubelet が 5 秒ごとに活性プローブを実行することを指定します。
• Kubelet はコンテナ内で cat /tmp/healthy コマンドを実行して検出を実行します。
• コマンドが正常に実行され、戻り値が 0 の場合、kubelet はコンテナが正常で動作中であるとみなします。
• このコマンドがゼロ以外の値を返す場合、kubelet はコンテナを強制終了して再起動します。
• コンテナが起動したら、次のコマンドを実行します。

 / bin / sh -c "/tmp/healthy をタッチ; 30 スリープ; rm -f /tmp/healthy; 600 スリープ"

• コンテナの存続期間の最初の 30 秒間は、/tmp/healthy ファイルが存在します。したがって、最初の 30 秒間にコマンド cat /tmp/health を実行すると成功コードが返されます。 30 秒後に、コマンド cat /tmp/health を実行すると失敗コードが返されます。

ポッドを作成する:

 # 最初にイメージをプルするのが最善です。 docker を使用している場合は、docker に切り替えるだけです。
 crictl プルレジストリ.aliyuncs .com / google_containers / busybox

 kubectl 適用-f exec -ライブネス.yaml

[問題] ERRO[0000] イメージ API バージョンを判別できません: rpc エラー: code = 利用不可 desc = 接続エラー: desc = “トランスポート: ダイヤル中にエラーが発生しました ダイヤル unix /var/run/dockershim.sock: 接続: そのようなファイルまたはディレクトリはありません” [解決方法] 理由: エンドポイントが構成されていません

 crictl config ランタイム-エンドポイント unix : /// run / containerd / containerd .sock
 crictl config image -エンドポイント unix : /// run / containerd / containerd .sock

チェック

 kubectl ポッドの生存状態を記述- exec

【現象】30秒後にチェックが失敗した後、ポッドが再起動され、すべてが正常に戻ります。

2) httpGetメソッド

 cat > http - liveness .yaml << EOF
 APIバージョン: v1
種類:ポッド
メタデータ:
 名前: liveness - httpget
 名前空間:デフォルト
仕様:
 # テストの便宜上、スケジューリングマシンを指定します
 ノード名:ローカル- 168-182-110
 コンテナ:
 -名前: liveness - httpget -コンテナ
 画像: nginx
 imagePullPolicy : IfNotPresent
 ポート:
 -名前: nginx
 コンテナポート: 80
 ライブネスプローブ:
 httpGet :取得:
 ポート: nginx
 パス: /index.html
 初期遅延秒数: 1
 期間秒数: 3
 タイムアウト秒数: 10
終了

説明する：

• initialDelaySeconds フィールドは、最初のプローブを実行する前に 1 秒待機する必要があることを kubelet に指示します。
• periodSeconds フィールドは、kubelet が 3 秒ごとに活性プローブを実行することを指定します。
• kubelet は、コンテナ内で実行されているサービス (サービスはポート 80 でリッスンしています) に HTTP GET リクエストを送信してプローブを実行します。
• サーバーの /index.html パスにあるハンドラーが成功コードを返す場合、kubelet はコンテナが稼働中であり正常であるとみなします。
• ハンドラが失敗コードを返す場合、kubelet はコンテナを強制終了して再起動します。
• 戻りコードが 200 以上 400 未満の場合は成功を示し、それ以外の場合は失敗を示します。

実行して表示する

 crictl プル nginx
 kubectl apply -f http -ライブネス.yaml
 kubectl はポッドの有効性を説明します- httpget

Podのindex.htmlファイルを削除します

 kubectl exec - it ライブネス- httpget -- rm -rf /usr/share/nginx/html/index.html
 # もう一度確認
kubectl はポッドの有効性を説明します- httpget
 kubectl ポッドの活性を取得- httpget 

• 再起動の理由は、HTTP 検出によって取得されたステータス戻りコードが 404 であり、Liveness プローブが失敗しました: HTTP プローブがステータス コード 404 で失敗しました。
• 再起動が完了した後、再度取得されたイメージに index.html ファイルが含まれているため、再起動は行われません。

HTTP プローブを使用すると、httpGet に追加のフィールドを設定できます。

• ホスト: 接続に使用されるホスト名。デフォルトはポッドの IP です。代わりに、HTTP ヘッダーに「Host」を設定することもできます。
• スキーム: ホストへの接続方法 (HTTP または HTTPS) を設定するために使用されます。デフォルトは「HTTP」です。
• path: HTTP サービスにアクセスするためのパス。デフォルト値は「/」です。
• httpHeaders: リクエスト内のカスタマイズされた HTTP ヘッダー。 HTTP ヘッダー フィールドは繰り返すことができます。
• port: コンテナにアクセスするためのポート番号またはポート名。数値は 1 ～ 65535 の範囲でなければなりません。

プローブに .httpHeaders を設定することで、デフォルトのヘッダー フィールド値を上書きできます。例えば：

ライブネスプローブ:
 httpGet :取得:
 httpヘッダー:
 -名前:承諾
 値:アプリケーション/ json

スタートアッププローブ:
 httpGet :取得:
 httpヘッダー:
 -名前:ユーザー-エージェント
 値: MyUserAgent

3) tcpSocket方式

 cat > tcp -ライブネス-準備状況.yaml << EOF
 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:活性-準備- tcpsocket
 ラベル:
 アプリ:ライブネス-準備- tcpsocket
仕様:
 # テストの便宜上、スケジューリングマシンを指定します
 ノード名:ローカル- 168-182-110
 コンテナ:
 -名前:活性-準備状況- tcpsocket
 画像: nginx
 ポート:
 -コンテナポート: 80
 準備状況プローブ:
 tcpソケット:
 ポート: 80
 初期遅延秒数: 5
 期間秒数: 10
 ライブネスプローブ:
 tcpソケット:
 ポート: 80
 初期遅延秒数: 15
 期間秒数: 20
終了

説明する：

• kubelet はコンテナの起動後 5 秒で最初の livenessProbe を送信します。
• プローブは、goproxy コンテナのポート 80 に接続しようとします。プローブが成功すると、Pod は準備完了としてマークされ、kubelet は 10 秒ごとにプローブを実行し続けます。
• この構成には、準備プローブに加えて、livenessProbe が含まれます。
• kubelet は、コンテナが起動してから 15 秒後に最初の liveness probe を実行します。
• 準備プローブと同様に、生存プローブは goproxy コンテナのポート 80 への接続を試みます。活性プローブが失敗した場合、コンテナは再起動されます。埋め込む

 kubectl 適用- f tcp -ライブネス-準備.yaml
 kubectl ポッドの稼働状況-準備状況- tcpsocket を取得する
kubectl はポッドのライブネス-準備状況- tcpsocket を記述します

4) 名前付きポートの使用

HTTP または TCP キープアライブ検出には、名前付きポートを使用できます。

ポート:
 -名前: nginx
 コンテナポート: 80
 ホストポート: 80

ライブネスプローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx

フルバージョン構成

ポート:
 -名前: nginx
 コンテナポート: 80
 ホストポート: 80

 # readinessProbe、準備状況プローブ
ライブネスプローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx
 # 検出を開始するまでの遅延時間
 初期遅延秒数: 10
 # 実行検出頻度（秒） [1秒ごとに1回実行]
 期間秒数: 10
 ＃ タイムアウト
 タイムアウト秒数: 1
 # 成功状態の場合、連続して数回失敗すると検出は失敗したとみなされます。
 失敗しきい値: 3
 # 失敗状態の場合、数回連続して成功すると検出は成功したとみなされます。
 成功しきい値: 1

 # livenessProbe、生存プローブ
ライブネスプローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx
 # 検出を開始するまでの遅延時間
 初期遅延秒数: 10
 # 実行検出頻度（秒） [1秒ごとに1回実行]
 期間秒数: 10
 ＃ タイムアウト
 タイムアウト秒数: 1
 # 成功状態の場合、連続して数回失敗すると検出は失敗したとみなされます。
 失敗しきい値: 3
 # 失敗状態の場合、数回連続して成功すると検出は成功したとみなされます。
 成功しきい値: 1

 # startupProbe、スタートアッププローブ
スタートアッププローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx
 # 検出を開始するまでの遅延時間
 初期遅延秒数: 10
 # 実行検出頻度（秒） [1秒ごとに1回実行]
 期間秒数: 10
 ＃ タイムアウト
 タイムアウト秒数: 1
 # 成功状態の場合、連続して数回失敗すると検出は失敗したとみなされます。
 失敗しきい値: 3
 # 失敗状態の場合、数回連続して成功すると検出は成功したとみなされます。
 成功しきい値: 1

通常、コントローラーはポッドの作成と管理に使用されます。 k8s コントローラーについてよくわからない方は、前回の記事「Kubernetes (k8s) の 5 つのコントローラーの詳細説明: Deployment、StatefulSet、DaemonSet、Job、CronJob」を参照してください。

完全な例を以下に示します。

 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
 名前:展開-プローブ
仕様:
 レプリカ: 3
 セレクター:
 マッチラベル:
 アプリ:デプロイメント-プローブ
 テンプレート：
 メタデータ:
 ラベル:
 アプリ:デプロイメント-プローブ
 仕様:
 コンテナ:
 -名前: nginx
 イメージ: nginx : 1.17.1

 # readinessProbe、準備状況プローブ
 準備状況プローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx
 # 検出を開始するまでの遅延時間
 初期遅延秒数: 10
 # 実行検出頻度（秒） [1秒ごとに1回実行]
 期間秒数: 10
 ＃ タイムアウト
 タイムアウト秒数: 1
 # 成功状態の場合、連続して数回失敗すると検出は失敗したとみなされます。
 失敗しきい値: 3
 # 失敗状態の場合、数回連続して成功すると検出は成功したとみなされます。
 成功しきい値: 1

 # livenessProbe、生存プローブ
 ライブネスプローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx
 # 検出を開始するまでの遅延時間
 初期遅延秒数: 10
 # 実行検出頻度（秒） [1秒ごとに1回実行]
 期間秒数: 10
 ＃ タイムアウト
 タイムアウト秒数: 1
 # 成功状態の場合、連続して数回失敗すると検出は失敗したとみなされます。
 失敗しきい値: 3
 # 失敗状態の場合、数回連続して成功すると検出は成功したとみなされます。
 成功しきい値: 1

 # startupProbe、スタートアッププローブ
 スタートアッププローブ:
 httpGet :取得:
 パス: /index.html
 ポート: nginx
 # 検出を開始するまでの遅延時間
 初期遅延秒数: 10
 # 実行検出頻度（秒） [1秒ごとに1回実行]
 期間秒数: 10
 ＃ タイムアウト
 タイムアウト秒数: 1
 # 成功状態の場合、連続して数回失敗すると検出は失敗したとみなされます。
 失敗しきい値: 3
 # 失敗状態の場合、連続して数回成功すると検出は成功したとみなされます。
 成功しきい値: 1

実行ビュー

 crictl プルnginx : 1.17.1
 kubectl apply -fデプロイメント-プローブ.yaml
 kubectl ポッドを取得してデプロイする

Kubernetes (k8s) ヘルスチェックの詳しい説明と実践的なデモンストレーションをまずはここで紹介します。ヘルスチェックはすべての k8s オーケストレーション タスクに付随するため、非常に重要です。実際、それは難しいことではありません。ご質問がありましたらメッセージを残してください〜