ワーカープールのコンテナのヘルスチェックを構成する

HTTP、TCP、gRPC の起動プローブと、新規および既存の Cloud Run ワーカープールに対する HTTP と gRPC のライブネス プローブを構成できます。構成は、プローブの種類によって異なります。

ユースケース

構成できるヘルスチェック プローブには次の 2 種類があります。

• ライブネス プローブは、コンテナを再起動するかどうかを判断します。

  • この場合にコンテナを再起動すると、バグの発生時におけるワーカープールの可用性を高めることができます。
  • ライブネス プローブは、他の方法では復元できない個々のインスタンスを再起動することを目的としています。主に、回復不能なインスタンス障害に使用します。たとえば、ワーカープールは実行されていものの処理が進まないデッドロックを捕捉する場合などです。カスタムの組織のポリシーを使用して、すべてのコンテナで Liveness Probe を必須にできます。

• 起動プローブは、コンテナが起動したかどうかを判断します。

  • 起動プローブを構成すると、コンテナが起動したと起動プローブが判断するまで、ライブネス チェックは無効になります。これにより、ワーカープール起動時の干渉が防止されます。
  • 起動プローブは、開始が遅いコンテナでライブネス チェックを行う場合に特に役立ちます。これは、コンテナが起動して動作する前にシャットダウンされることを防ぐためです。

ワーカープールで起動またはライブネス プローブの失敗が繰り返し発生すると、Cloud Run はインスタンスの再起動を制限して、制御不能なクラッシュ ループを防ぎます。

CPU の割り当て

• プローブの実行時に CPU が常に割り振られます。
• すべてのプローブは CPU 使用率とメモリ使用量に対して課金されます。

プローブの要件と動作

プローブを構成する

構成を変更すると、新しいリビジョンが作成されます。明示的に更新しない限り、以降のリビジョンでも、この構成が自動的に設定されます。

HTTP、TCP、gRPC のプローブは、Cloud Run REST API を使用して構成できます。

HTTP ヘルスチェック エンドポイントを作成する

HTTP 起動プローブまたはライブネス プローブ用に Cloud Run ワーカープールを構成する場合、プローブに応答するため、ワーカープール コードにエンドポイントを追加する必要があります。エンドポイントには任意の名前（/startup、/ready など）を使用できますが、名前はプローブ構成で path に指定した値と一致する必要があります。たとえば、HTTP 起動プローブに /ready を指定する場合は、次のようにプローブ構成で path を指定します。

startupProbe:
  httpGet:
    path: /ready

HTTP ヘルスチェック エンドポイントは外部からアクセスでき、外部に公開される他の HTTP エンドポイントと同じ原則に従います。