第8章 ヘルスチェックの使用によるアプリケーションの正常性の監視

ソフトウェアのシステムでは、コンポーネントは一時的な問題 (一時的に接続が失われるなど)、設定エラー、または外部の依存関係に関する問題などにより正常でなくなることがあります。OpenShift Container Platform アプリケーションには、正常でないコンテナーを検出し、これに対応するための数多くのオプションがあります。

8.1. ヘルスチェックについて

ヘルスチェックは、readiness、liveness、および startup ヘルスチェックの組み合わせを使用して、実行中のコンテナーで診断を定期的に実行します。

ヘルスチェックを実行するコンテナーが含まれる 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 プローブは、コンテナーを強制終了してから再起動します。

スタートアッププローブ

スタートアッププローブ は、コンテナー内のアプリケーションが起動しているかどうかを示します。その他のプローブはすべて、起動に成功するまで無効にされます。スタートアッププローブが指定の期間内に成功しない場合、kubelet はコンテナーを強制終了し、コンテナーは Pod の restartPolicy の対象となります。

一部のアプリケーションでは、最初の初期化時に追加の起動時間が必要になる場合があります。liveness または readiness プローブで startup プローブを使用して、failureThreshold および periodSeconds パラメーターを使用し、長い起動時間に十分に対応できるようにプローブを遅延させることができます。

たとえば、failureThreshold が 30 回 (30 failure) で、periodSeconds が 10 秒の最大 5 分 (30 * 10s = 300s) を指定して startup プローブを liveness プローブに追加できます。startup プローブが初回に成功すると、liveness プローブがこれを引き継ぎます。

以下のテストのタイプのいずれかを使用して、liveness、readiness、および startup プローブを設定できます。

  • HTTP GET: HTTP GET テストを使用する場合、テストは Web hook を使用してコンテナーの正常性を判別します。このテストは、HTTP の応答コードが 200 から 399 までの値の場合に正常と見なされます。

    完全に初期化されている場合に、HTTP ステータスコードを返すアプリケーションで HTTP GET テストを使用できます。

  • コンテナーコマンド: コンテナーコマンドテストを使用すると、プローブはコンテナー内でコマンドを実行します。テストが 0 のステータスで終了すると、プローブは成功します。
  • TCP ソケット: TCP ソケットテストを使用する場合、プローブはコンテナーに対してソケットを開こうとします。コンテナーはプローブで接続を確立できる場合にのみ正常であるとみなされます。TCP ソケットテストは、初期化が完了するまでリスニングを開始しないアプリケーションで使用できます。

複数のフィールドを設定して、プローブの動作を制御できます。

  • initialDelaySeconds: コンテナーが起動してからプローブがスケジュールされるまでの時間 (秒単位)。デフォルトは 0 です。
  • periodSeconds: プローブの実行間の遅延 (秒単位)。デフォルトは 10 です。この値は timeoutSeconds よりも大きくなければなりません。
  • timeoutSeconds: プローブがタイムアウトし、コンテナーが失敗した想定されてから非アクティブになるまでの時間 (秒数)。デフォルトは 1 です。この値は periodSeconds 未満である必要があります。
  • successThreshold: コンテナーのステータスを successful にリセットするために、プローブが失敗後に成功を報告する必要のある回数。liveness プローブの場合は、値は 1 である必要があります。デフォルトは 1 です。

  • failureThreshold: プローブが失敗できる回数。デフォルトは 3 です。指定される試行の後に、以下を実行します。

    • liveness プローブの場合、コンテナーが再起動します。
    • readiness プローブの場合、Pod には Unready というマークが付けられます。
    • startup プローブの場合、コンテナーは強制終了され、Pod の restartPolicy の対象となります。

プローブの例

以下は、オブジェクト仕様に表示されるさまざまなプローブの例です。

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
...

1
コンテナー名。
2
デプロイするコンテナーイメージ。
3
readiness プローブ
4
コンテナーコマンドのテスト。
5
コンテナーで実行するコマンド。

Pod 仕様のコンテナーコマンドテストを含むコンテナーコマンドの startup プローブおよび 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
      httpGet: 4
        scheme: HTTPS 5
        path: /healthz
        port: 8080 6
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
    startupProbe: 7
      httpGet: 8
        path: /healthz
        port: 8080 9
      failureThreshold: 30 10
      periodSeconds: 10 11
...

1
コンテナー名。
2
デプロイするコンテナーイメージを指定します。
3
liveness プローブ
4
HTTP GET テスト。
5
インターネットスキーム: HTTP または HTTPSデフォルト値は HTTP です。
6
コンテナーがリッスンしているポート。
7
スタートアッププローブ。
8
HTTP GET テスト。
9
コンテナーがリッスンしているポート。
10
失敗後にプローブを試行する回数。
11
プローブを実行する秒数。

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
...

1
コンテナー名。
2
デプロイするコンテナーイメージを指定します。
3
liveness プローブ。
4
プローブのタイプ。この場合はコンテナーコマンドプローブです。
5
コンテナー内で実行するコマンドライン。
6
プローブを実行する頻度 (秒単位)。
7
失敗後の成功を示すために必要な連続する成功の数。
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
...

1
readiness プローブ。
2
liveness プローブ。