5.4. Node.js のヘルスチェック例
以下の例は、実稼働環境で実行することは意図されていません。
実験レベルの例: Foundational。
アプリケーションをデプロイする場合、利用可能かどうか、および受信リクエストの処理を開始できるかどうかを確認することが重要になります。ヘルスチェックパターンを実装 すると、アプリケーションの正常 性を監視できます。これには、アプリケーションが利用可能かどうかや、要求に対応するかどうかが含まれます。
ヘルスチェックの用語に精通していない場合には、まず 「ヘルスチェックの概念」 セクションを参照してください。
このユースケースの目的は、プローブを使用してヘルスチェックパターンを実証することです。プローブは、アプリケーションの liveness および readiness を報告するために使用されます。このユースケースでは、HTTP ヘルスエンドポイント
を公開するアプリケーションを設定し、HTTP リクエストを発行します。コンテナーが正常であれば、ヘルス
HTTP エンドポイントの liveness プローブにより、管理プラットフォームは 200
をリターンコードとして受け取り、これ以外のアクションは必要ありません。正常
HTTP エンドポイントが(スレッドがブロックされた場合など)応答を返しない場合、アプリケーションは liveness プローブに従って有効であるとみなされません。この場合、プラットフォームはそのアプリケーションに対応する Pod を強制終了し、新しい Pod を再作成し、アプリケーションを再起動します。
このユースケースでは、readiness プローブを実証し、使用することもできます。アプリケーションが稼働中で、再起動時にアプリケーションが HTTP 503
応答コードを返す場合などにリクエストを処理できない場合、このアプリケーションは readiness プローブに従って準備状態にあると見なされません。アプリケーションが readiness プローブによって準備状態とみなされない場合、要求はそのアプリケーションにルーティングされず、readiness プローブにより ready と見なされます。
5.4.1. ヘルスチェックの概念 リンクのコピーリンクがクリップボードにコピーされました!
ヘルスチェックパターンを理解するには、まず以下の概念を理解する必要があります。
- Liveness
- liveness は、アプリケーションが実行中かどうかを定義します。実行中のアプリケーションが応答しない状態または停止状態に移行する場合があり、再起動が必要になる場合があります。liveness の確認は、アプリケーションを再起動する必要があります。
- 準備状態 (Readines)
- readiness は、実行中のアプリケーションが要求を提供できるかどうかを定義します。実行中のアプリケーションがエラーや破損状態に遷移する場合があり、要求に対応できなくなった可能性があります。readiness チェックは、要求がアプリケーションにルーティングされるかどうかを判断するのに役立ちます。
- fail-over
- フェイルオーバーにより、要求の処理の失敗を適切に処理できます。アプリケーションがリクエストのサービスを提供できない場合、その要求と今後のリクエストは 失敗したり、別の アプリケーションにルーティングしたりすることができます。これは通常、同じアプリケーションの冗長コピーです。
- 回復性と安定性
- 回復性と安定性により、要求への対応の失敗が適切に処理できるようになります。接続損失によるアプリケーションによるリクエストのサービス拒否に失敗した場合、接続の再確立後に要求を再試行できる回復性のあるシステムで、接続が失われてしまいます。
- probe
- プローブは実行中のコンテナーで定期的に実行する Kubernetes の動作です。