This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第6章 アプリケーションの正常性のモニタリング
ソフトウェアのシステムでは、コンポーネントは一時的な問題 (一時的に接続が失われるなど)、設定エラー、または外部の依存関係に関する問題などにより正常でなくなることがあります。OpenShift Container Platform アプリケーションには、正常でないコンテナーを検出し、これに対応するための数多くのオプションがあります。
6.1. ヘルスチェックについて リンクのコピーリンクがクリップボードにコピーされました!
プローブは実行中のコンテナーで定期的に実行する Kubernetes の動作です。現時点では、2 つのタイプのプローブがあり、それぞれが目的別に使用されています。
- readiness プローブ
- readiness チェックは、スケジュールの対象になるコンテナーでサービス要求に対応する準備が整っているかどうかを判別します。readiness プローブがコンテナーで失敗する場合、エンドポイントコントローラーはコンテナーの IP アドレスがすべてのエンドポイントから削除されるようにします。readiness プローブを使用すると、コンテナーが実行されていても、それがプロキシーからトラフィックを受信しないようエンドポイントコントローラーに信号を送ることができます。
たとえば、readiness チェックでは、どの Pod を使用するかを制御することができます。Pod の準備ができない場合、削除されます。
- liveness プローブ
- liveness チェックは、スケジュールされているコンテナーがまだ実行中であるかどうかを判断します。デッドロックなどの状態のために liveness プローブが失敗する場合、kubelet はコンテナーを強制終了します。 その後に、コンテナーは再起動ポリシーに基づいて応答します。
たとえば、restartPolicy
として Always
または OnFailure
が設定されているノードでの liveness プローブは、ノード上のコンテナーを強制終了してから、これを再起動します。
liveness チェックの例
正常ではないコンテナーについての liveness チェック出力の例
6.1.1. ヘルスチェックのタイプについて リンクのコピーリンクがクリップボードにコピーされました!
liveness チェックと readiness チェックは 3 つの方法で設定できます。
- HTTP チェック
- kubelet は web hook を使用してコンテナーの正常性を判別します。このチェックは HTTP の応答コードが 200 から 399 までの値の場合に正常とみなされます。
HTTP チェックは、これが完全に初期化されている場合は HTTP ステータスコードを返すアプリケーションに適しています。
- コンテナー実行チェック
- kubeletは、コンテナー内でコマンドを実行します。ステータス 0 でチェックを終了すると、成功とみなされます。
- TCP ソケットチェック
- kubelet はコンテナーに対してソケットを開くことを試行します。コンテナーはチェックで接続を確立できる場合にのみ正常であるとみなされます。TCP ソケットチェック は、初期化が完了するまでリスニングを開始しないアプリケーションに適しています。