第7章 ヘルスチェックの使用によるアプリケーションの正常性の監視
ソフトウェアのシステムでは、コンポーネントは一時的な問題 (一時的に接続が失われるなど)、設定エラー、または外部の依存関係に関する問題などにより正常でなくなることがあります。OpenShift Container Platform アプリケーションには、正常でないコンテナーを検出し、これに対応するための数多くのオプションがあります。
7.1. ヘルスチェックについて
ヘルスチェックは、readiness および liveness ヘルスチェックの組み合わせを使用して、実行中のコンテナーで診断を定期的に実行します。
ヘルスチェックを実行するコンテナーが含まれる Pod の仕様に、1 つ以上のプローブを含めることができます。
既存の Pod でヘルスチェックを追加または編集する必要がある場合、Pod の DeploymentConfig オブジェクトを編集するか、または Web コンソールで Developer パースペクティブを使用する必要があります。CLI を使用して既存の Pod のヘルスチェックを追加したり、編集したりすることはできません。
- readiness プローブ
readiness プローブ はコンテナーがサービス要求を受け入れることができるかどうかを判別します。コンテナーの readiness プローブが失敗すると、kubelet は利用可能なサービスエンドポイントの一覧から Pod を削除します。
失敗後、プローブは Pod の検証を継続します。Pod が利用可能になると、kubelet は Pod を利用可能なサービスエンドポイントの一覧に追加します。
- liveness ヘルスチェック
liveness プローブ は、コンテナーが実行中かどうかを判別します。デッドロックなどの状態のために liveness プローブが失敗する場合、kubelet はコンテナーを強制終了します。その後、Pod は再起動ポリシーに基づいて応答します。
たとえば、
restartPolicyとしてAlwaysまたはOnFailureが設定されている Pod での liveness プローブは、コンテナーを強制終了してから再起動します。
以下のテストのタイプのいずれかを使用して、liveness および readiness プローブを設定できます。
HTTP
GET: HTTPGETテストを使用する場合、テストは Web hook を使用してコンテナーの正常性を判別します。このテストは、HTTP の応答コードが200から399までの値の場合に正常と見なされます。完全に初期化されている場合に、HTTP ステータスコードを返すアプリケーションで HTTP
GETテストを使用できます。-
コンテナーコマンド: コンテナーコマンドテストを使用すると、プローブはコンテナー内でコマンドを実行します。テストが
0のステータスで終了すると、プローブは成功します。 - TCP ソケット: TCP ソケットテストを使用する場合、プローブはコンテナーに対してソケットを開こうとします。コンテナーはプローブで接続を確立できる場合にのみ正常であるとみなされます。TCP ソケットテストは、初期化が完了するまでリスニングを開始しないアプリケーションで使用できます。
複数のフィールドを設定して、プローブの動作を制御できます。
-
initialDelaySeconds: コンテナーが起動してからプローブがスケジュールされるまでの時間 (秒単位)。デフォルトは 0 です。 -
periodSeconds: プローブの実行間の遅延 (秒単位)。デフォルトは10です。 -
timeoutSeconds: プローブがタイムアウトし、コンテナーが失敗した想定されてから非アクティブになるまでの時間 (秒数)。デフォルトは1です。 -
successThreshold: コンテナーのステータスを successful にリセットするために、プローブが失敗後に成功を報告する必要のある回数。liveness プローブの場合は、値は1である必要があります。デフォルトは1です。 failureThreshold: プローブが失敗できる回数。デフォルトは 3 です。指定される試行の後に、以下を実行します。- liveness プローブの場合、コンテナーが再起動します。
readiness プローブの場合、Pod には
Unreadyというマークが付けられます。注記timeoutSecondsパラメーターは、OpenShift Container Platform はコンテナーへの実行呼び出しでタイムアウトできないため、コンテナーコマンドプローブの readiness および liveness プローブには影響を与えません。コンテナーコマンドプローブでタイムアウトを実装する 1 つの方法として、例にあるようにexec-timeoutコマンドを使用して liveness または readiness プローブを実行する方法があります。
プローブの例
以下は、オブジェクト仕様に表示されるさまざまなプローブの例です。
Pod 仕様のコンテナーコマンド readiness プローブを含む readiness プローブの例
apiVersion: v1
kind: Pod
metadata:
labels:
test: health-check
name: my-application
...
spec:
containers:
- name: goproxy-app 1
args:
image: k8s.gcr.io/goproxy:0.1 2
readinessProbe: 3
exec: 4
command: 5
- cat
- /tmp/healthy
...
Pod 仕様でタイムアウトを使用するコンテナーコマンドテストを使用した liveness プローブの例
apiVersion: v1
kind: Pod
metadata:
labels:
test: health-check
name: my-application
...
spec:
containers:
- name: goproxy-app 1
args:
image: k8s.gcr.io/goproxy:0.1 2
livenessProbe: 3
exec: 4
command: 5
- /bin/bash
- '-c'
- timeout 60 /opt/eap/bin/livenessProbe.sh
periodSeconds: 10 6
successThreshold: 1 7
failureThreshold: 3 8
...
デプロイメントでの TCP ソケットテストを含む readiness プローブおよび liveness プローブの例
kind: Deployment
apiVersion: apps/v1
...
spec:
...
template:
spec:
containers:
- resources: {}
readinessProbe: 1
tcpSocket:
port: 8080
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
terminationMessagePath: /dev/termination-log
name: ruby-ex
livenessProbe: 2
tcpSocket:
port: 8080
initialDelaySeconds: 15
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
...
