第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: HTTP GET テストを使用する場合、テストは 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
...

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

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 プローブ。