ヘルスチェックは良いポッドにとって不可欠

Kubernetes 内の各サービスの可用性を高めたい場合は、Pod のヘルスチェックが不可欠です。ポッドのライフサイクルとヘルスチェックは、私たちが最も頻繁に触れる基本的な知識です。基礎ではありますが、よく理解しておかないと、問題が起こったときに頭を悩ませたり、髪の毛を引っ張ったりしてしまいがちです。

この記事では、主にK8Sを使っているときに困ること、Podのライフサイクル、再起動戦略、ヘルスチェック、プローブの選択方法、実際の戦闘の6つの側面からPodのヘルスチェックを紹介し、最後にナレッジポイントのまとめとPodの問題のトラブルシューティングのまとめがあります。

1. K8Sと初めて出会ったときの恥ずかしいこと

Kubernetesを使い始めた2019年を振り返ると、Podが起動できないという事態に遭遇し、途方に暮れていました。その後、いくつかのトラブルシューティング方法を徐々に習得し、この状況は緩和されました。

時間が経つにつれて、再び問題が発生しました。ある日、Springboot マイクロサービスをデプロイする際に、開発環境とテスト環境に何度もデプロイしましたが、正常に起動したのは数回だけで、ほとんどのデプロイは正常に起動しませんでした。ただし、実稼働環境は毎回正常にデプロイできます。当時、この問題は長い間私を悩ませていました。今考えてみると、かなり興味深いですね。

皆さんの多くはすでに答えを推測していると思います。はい、それは今日お話する健康診断に関係しています。

ポッドのライフサイクル

ヘルスチェックについて説明する前に、まず Pod のライフサイクルまたは Pod のステータスを確認しましょう。

Pod のライフサイクルは Pending 状態から始まります。 Pod 内の少なくとも 1 つのアプリケーション コンテナが正常に起動すると、実行状態になります。その後、Pod 内のコンテナが正常に終了すると、Succeeded 状態になります。 Pod 内のコンテナが異常終了すると、Failed 状態になります。

• 保留状態: 現時点では、Pod は K8S によって受け入れられ、作成されていますが、Pod 内にコンテナは作成されていません。このプロセスには、ポッドがスケジュールされるまでの待機時間とイメージのダウンロード時間が含まれます。
• 実行状態: この時点では、ポッドはすでにノード上で実行されており、ポッド内のすべてのコンテナが作成されており、一部のコンテナは実行中、開始中、または再起動中の状態になっています。
• 成功状態: この時点で、Pod 内のすべてのコンテナが正常に実行され、終了します。
• 失敗状態: この時点で、Pod 内のすべてのコンテナは終了していますが、一部のコンテナは異常終了しています。
• 不明なステータス: ポッドのステータスを取得できません。通常は、ポッドがホストと通信できないためですが、その他の理由により取得できない場合もあります。

3. 再開戦略

Pod の再起動は、Pod が配置されているノード上の kubelet によって決定および制御されます。 Kubelet は再起動戦略に応じて対応するアクションを実行します。

Pod 再起動ポリシーには、Always、OnFailure、Never の 3 つがあります。デフォルトは「常に」です。

• Always: 再起動ポリシーが Always の場合、コンテナが非アクティブなときに kubelet はコンテナを自動的に再起動します。たとえば、生存プローブがアプリケーションの異常を検出すると、Pod が自動的に再起動されます。
• OnFailure: 再起動戦略が OnFailure の場合、コンテナが Failed 状態になると、kubelet は自動的にコンテナを再起動します。
• Never: コンテナの実行状態に関係なく、Kubelet はコンテナを再起動しません。

4. 健康チェック

ヘルスチェック機能により、アプリケーションの可用性を確保し、外部からアクセスできるタイミングを制御できます。

K8S には、LivenessProbe 生存プローブ、ReadinessProbe 準備プローブ、StartupProbe 起動プローブの 3 種類の検査プローブがあります。

• LivenessProbe 生存プローブは、コンテナが生存しているかどうか (実行状態) を判断します。サバイバルプローブがコンテナが正常でないことを検知すると、kubelet はコンテナを強制終了し、コンテナの再起動ポリシーに従って対応するアクションを実行します。
• ReadinessProbe 準備プローブは、コンテナーが使用可能かどうか (準備完了状態) を判断します。準備完了状態に達したポッドのみがリクエストを受信できます。 kubelet は準備プローブを使用して、コンテナがリクエストを受け入れる準備が整ったかどうかを検出します。
• StartupProbe スタートアップ プローブ 一部のアプリケーションの起動が遅くなります。たとえば、単一の大きなアプリケーションの起動には最大 3 分かかります。この時点で、生存プローブまたは準備プローブのみが使用されている場合、アプリケーションは起動する前に強制終了される可能性があります。この状況はプローブを有効にすることで解決できます。起動プローブが設定されている場合、生存プローブと準備プローブの両方が成功するまでコンテナは再起動されません。簡単に言えば、起動プローブが構成されている限り、アプリケーションが正常に起動されるまで、生存プローブと準備プローブは有効になりません。

上記の 3 つのプローブをそれぞれ実装するには、次の 3 つの方法があります。

• ExecAction: コンテナ内でコマンドを実行します。コマンドの戻りコードが 0 の場合、コンテナは正常です。
• TCPSocketAction: コンテナの IP アドレスとポート番号に基づいて TCP チェックを実行します。 TCP 接続を確立できる場合、コンテナは正常です。
• HTTPGetAction: コンテナの IP アドレス、ポート番号、パスを使用して HTTP 要求を開始します。 HTTP 応答ステータス コードが 200 以上 400 未満の場合、コンテナーは正常です。

Java マイクロサービス アプリケーションをデプロイする場合、通常は HTTPGetAction メソッドを使用します。

5. プローブの選び方

プローブには3種類ありますが、どのように選択すればよいでしょうか？

• 障害が検出されたときにコンテナを強制終了して自動的に再起動する場合は、活性プローブを選択します。
• 検出が成功した場合にのみ Pod がリクエストを受け入れるようにしたい場合は、準備プローブが必要です。アプリケーション A がリクエストを受け入れる前にアプリケーション B が起動されている必要がある場合は、準備状況プローブも必要です。
• アプリケーションの起動に時間がかかる場合は、起動プローブを追加する必要があります。

大人の世界には多肢選択式の質問はありません。必要なのはたった 3 つの単語だけですが、そのすべてが必要です。たとえば、アプリケーション シナリオが Spring マイクロサービスの場合、実際には 3 種類のプローブすべてが使用されます。

アプリケーションの起動は、起動開始→起動成功（生存）→外部アクセスの3段階に分かれます。

対応するプローブの使用順序は、起動プローブ → 生存プローブ → 準備プローブです。以下のように表示されます。

生存プローブのみを選択すると、扱いにくくなります。

• 設定された生存検出時間が短すぎると、起動が遅いアプリケーションは起動する前に強制終了されるため、まったく起動できなくなります。
• 設定された生存検出時間が長すぎると、アプリケーションで問題が発生した場合に、時間内に再起動できず、全体的な可用性に影響します。

準備プローブを設定しないと、扱いにくくなります。

• たとえば、一部のシナリオでは、アプリケーション自体は稼働しているが、依存するアプリケーションは稼働していないため、現時点では外部へのアクセスを提供できず、要求トラフィックの受信が許可されません。

したがって、複数選択の質問を行う必要はなく、すべての質問に回答し、各段階で対応するプローブを使用する必要があります。

6. 実際の戦闘

1. 不健全なアプリケーションシナリオをシミュレートする

（１）YAMLをアレンジする

たとえば、ポッドの生存チェックを実行します。 30 秒経過しても生き残れない場合は、強制終了して再起動します。

 apiVersion: v1 kind: Pod metadata: name: pod-lifecycle namespace: demo labels: app: pod-lifecycle spec: containers: - name: pod-lifecycle image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy # 等待5秒执行第一次探测initialDelaySeconds: 5 # 探针连续失败了3 次之后，K8S认为检查已失败，然后触发重启failureThreshold: 3 # 每5秒执行一次存活探测periodSeconds: 5

ポッドが複数回再起動されたことがわかります

（２）トラブルシューティング

問題が発生しても慌てないでください。トラブルシューティングには、kubectl get pods -n demo -o wide と kubectl describe pod pod-lifecycle -n demo を使用できます。例外の原因は明らかに、生存チェックの失敗です。

2. 起動が遅いアプリケーションをシミュレートする

（１）YAMLをアレンジする

たとえば、ポッドの生存チェックを実行します。 30 秒経過しても生き残れない場合は、強制終了して再起動します。シミュレートされた起動には時間がかかるため、コンテナは正常に起動する前に強制終了され、その後繰り返し強制終了されます。

 apiVersion: v1 kind: Pod metadata: name: pod-lifecycle-2 namespace: demo labels: app: pod-lifecycle-2 spec: containers: - name: pod-lifecycle-2 image: busybox args: - /bin/sh - -c - sleep 20; touch /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy # 等待5秒执行第一次探测initialDelaySeconds: 5 # 探针连续失败了2 次之后，K8S认为检查已失败，然后触发重启failureThreshold: 2 # 每5秒执行一次存活探测periodSeconds: 5

yaml ファイルを実行すると、Pod が次のアクションを繰り返していることがわかります。ヘルスチェックが失敗した後に再起動されます。

（２）この問題を解決するためにstartupProbeを導入する

apiVersion: v1 kind: Pod metadata: name: pod-lifecycle-3 namespace: demo labels: app: pod-lifecycle-3 spec: containers: - name: pod-lifecycle-3 image: busybox args: - /bin/sh - -c - sleep 20; touch /tmp/healthy; sleep 600 startupProbe: exec: command: - cat - /tmp/healthy # 等待5秒执行第一次探测initialDelaySeconds: 5 # 探针连续失败了10 次之后，K8S认为检查已失败，然后触发重启failureThreshold: 5 # 每5秒执行一次存活探测periodSeconds: 5 livenessProbe: exec: command: - cat - /tmp/healthy # 等待5秒执行第一次探测initialDelaySeconds: 5 # 探针连续失败了2 次之后，K8S认为检查已失败，然后触发重启failureThreshold: 2 # 每5秒执行一次存活探测periodSeconds: 5

七。結論

Kubernetes 内の各サービスの可用性を高めたい場合は、Pod のヘルスチェックが不可欠です。この記事の要点は次のとおりです。

• ポッドのライフ サイクル: 保留中、実行中、成功または失敗、不明。
• ポッド再起動ポリシー: Always、OnFailure、Never。
• プローブには、起動プローブ、生存プローブ、準備プローブの 3 種類があります。
• プローブの選択方法: 通常は、すべてのプローブが必要です。
• Pod の問題のトラブルシューティング: kubectl get pods -n demo -o wide と kubectl describe pods webapp -n demo を一緒に使用します。

そうは言っても、この記事の冒頭で私が提起した質問の答えはご存知のはずです。アプリケーションの起動時間は長いですが、生存プローブのみが構成されており、起動プローブは構成されていません。また、生存プローブの全体的な構成時間が短すぎるため、各マシンのパフォーマンスが異なるため、正常に起動できる場合もあれば、失敗する場合もあります。