このページは Cloud Translation API によって翻訳されました。

ヘルスチェックを構成する

Google Distributed Cloud（GDC）エアギャップには、バックエンドインスタンスがトラフィックに適切に応答しているかどうかを判断するヘルスチェックメカニズムが用意されています。このドキュメントでは、ロードバランサのヘルスチェックを作成して使用する方法について説明します。

特に明記されていない限り、 Google Cloud ヘルスチェックは、ヘルスチェックリソースで指定されたパラメータに従ってバックエンドに接続する専用のソフトウェアタスクによって実装されます。接続を試みることをプローブと言います。 Google Cloud は、各プローブの成功または失敗を記録します。

各バックエンドの健全性ステータスは、プローブが連続して成功または失敗した回数（この数字は構成可能）によって決まります。つまり、バックエンドを正常とマークするために必要なプローブの連続成功回数と、異常とマークするために必要な連続失敗回数を構成します。

このヘルスステータスは、バックエンドが新しいリクエストまたは接続を受け取ることができるかどうかを決定します。ヘルスチェックで異常と判断されたバックエンドは、ロードバランサを介してトラフィックを受信しません。プローブの成功基準を定義します。詳細については、ヘルスチェックの仕組みをご覧ください。

ヘルスチェックプロトコル

ヘルスチェックは次のプロトコルをサポートしています。

TCP
HTTP
HTTPS

ヘルスチェックを選択する

ヘルスチェックは、ロードバランサの種類とバックエンドの種類に対応している必要があります。ヘルスチェックを選択する際は、次の要素を考慮してください。

プロトコル: GDC がバックエンドのプローブに使用するプロトコル。サポートされているプロトコルは、TCP、HTTP、HTTPS です。TCP プロトコルは、バックエンドへの接続を検証する基本的なヘルスチェックに役立ちます。一方、HTTP プロトコルと HTTPS プロトコルは、HTTP ワークロードまたは HTTPS ワークロードをすでに実行している VM に対して、より詳細なヘルスチェックメカニズムを提供します。
ポート指定: GDC がプロトコルで使用してバックエンドの健全性をプローブするポート。ヘルスチェック用のポートを指定する必要があります。
カテゴリ: ヘルスチェックはグローバルまたはゾーンにできます。グローバルヘルスチェックは GDC デプロイのすべてのゾーンに及びますが、ゾーンヘルスチェックは 1 つのゾーンに対応します。

ヘルスチェックの仕組み

以降のセクションでは、ヘルスチェックの仕組みについて説明します。

プローブ

ヘルスチェックを確立するときに、関連付けられたエンドポイントの健全性を各プローブが評価する頻度を制御するデフォルト設定を定義するか、デフォルト設定を受け入れます。これらの設定は、構成した基準を使用して、ロードバランサが異常と見なされたバックエンドへのリクエストのルーティングを停止するため、非常に重要です。プローブは評価を継続し、バックエンドが再び正常と判断されると、バックエンドへのトラフィックの送信を再開します。

ヘルスチェックの設定は、バックエンドサービスまたはターゲットプール内のすべてのバックエンドに均一に適用され、バックエンドごとに構成することはできません。

構成フラグ	説明	デフォルト値
チェック間隔 `check-interval`	同じプローバーによる 1 回のプローブの開始から次のプローブの開始までの時間（秒単位）。	`5s`（5 秒）
timeoutSec `timeoutSec`	障害を宣言する前にプローブを待機する時間（秒単位）。	`5s`（5 秒）
healthyThreshold `healthyThreshold`	エンドポイントが正常とみなされるために連続して成功しなければならないプローブの数。	2
unhealthyThreshold `unhealthyThreshold`	エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。	2

HTTP と HTTPS のヘルスチェックの成功基準

HTTP ヘルスチェックと HTTPS ヘルスチェックでは、ヘルスチェックがタイムアウトする前に、HTTP 200 (OK) ステータスコードが正常なレスポンスとして必要です。リダイレクト（301、302 など）を含む他の HTTP レスポンスコードは異常と見なされます。

HTTP 200 (OK) レスポンスコードを必須にすることに加え、次のことも可能です。

デフォルトのリクエストパス / ではなく、特定のリクエストパスに HTTP リクエストを送信するように、各ヘルスチェックプローバーを構成する。
HTTP レスポンス本文に想定されるレスポンス文字列が存在するかどうかを確認するように、各ヘルスチェックプローバーを構成する。レスポンス文字列は、HTTP レスポンス本文の最初の 1,024 バイト内に存在する、印刷可能なシングルバイト ASCII 文字のみで構成されている必要があります。

次の表に、HTTP と HTTPS のヘルスチェックで使用できる requestPath フィールドと response フィールドの有効な組み合わせを示します。

構成フラグ	プローバーの動作	成功基準
RequestPath も Response も指定されていない	プローバーは、リクエストパスとして `/` を使用します。	HTTP `200 (OK)` レスポンスコードのみ。
RequestPath と Response の両方が指定されている	プローバーは、構成されたリクエストパスを使用します。	HTTP `200 (OK)` レスポンスコードと、HTTP レスポンス本文の最初の 1,024 バイトまでの ASCII 文字は、想定されるレスポンス文字列と一致する必要があります。
レスポンスのみが指定されている	プローバーは、リクエストパスとして `/` を使用します。	HTTP `200 (OK)` レスポンスコードと、HTTP レスポンス本文の最初の 1,024 バイトまでの ASCII 文字は、想定されるレスポンス文字列と一致する必要があります。
RequestPath のみが指定されている	プローバーは、構成されたリクエストパスを使用します。	HTTP `200 (OK)` レスポンスコードのみ。

TCP ヘルスチェックの成功基準

TCP ヘルスチェックの基本的な成功基準は次のとおりです。

TCP ヘルスチェックの場合、ヘルスチェックプローバーは、ヘルスチェックのタイムアウト前にバックエンドへの TCP 接続を正常に開く必要があります。
TCP ヘルスチェックの場合、TCP 接続は次のいずれかの方法で終了する必要があります。
- ヘルスチェックプローバーが FIN パケットまたは RST（リセット）パケットを送信する。
- バックエンドが FIN パケットを送信する。
- バックエンドが TCP RST パケットを送信した場合、ヘルスチェックプローバーが FIN パケットをすでに送信していると、プローブが正常に完了したとはみなされない可能性があります。

始める前に

ヘルスチェックプローブを構成するには、次のものが必要です。

ロードバランサを構成するプロジェクトを所有している。詳細については、プロジェクトを作成するをご覧ください。
必要な ID とアクセスロール:
- 組織の IAM 管理者に、ロードバランサ管理者（load-balancer-admin）ロールを付与するよう依頼します。
- グローバル ILB の場合は、組織の IAM 管理者にグローバルロードバランサ管理者（global-load-balancer-admin）ロールの付与を依頼します。詳細については、事前定義ロールの説明をご覧ください。

ヘルスチェックを作成して管理する

GDC は、グローバルヘルスチェックとゾーンヘルスチェックをサポートしています。

HealthCheck API

HealthCheck オブジェクトは、グローバルまたはゾーンとして構成できます。グローバル HealthCheck オブジェクトはグローバルロードバランサ構成に使用され、ゾーン HealthCheck オブジェクトはゾーンロードバランサ構成に使用されます。どちらのタイプも名前と仕様は同じです。ただし、apiVersion 値と API サーバーは異なります。

Zonal apiVersion: networking.gdc.goog
グローバル apiVersion: networking.global.gdc.goog

gdcloud CLI を使用して、ヘルスチェックを作成して管理することもできます。

グローバル `HealthCheck` を作成する

次の例は、API を使用して HealthCheck を作成する方法を示しています。

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

ゾーン `HealthCheck` を作成する

次の例は、API を使用して HealthCheck を作成する方法を示しています。

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF

ヘルスチェックをロードバランサにリンクするには、以下をご覧ください。

構成の検証

構成が正しいことを確認するには、HealthCheck オブジェクトの Ready 条件を確認します。この条件は、構成エラーを示します。また、フィールドに必須の HealthCheck 設定が正確に反映されていることを確認します。

その他の使用上の注意

以降のセクションでは、 Google Cloudでヘルスチェックを使用する際の注意事項について説明します。

証明書とヘルスチェック

バックエンドで証明書を必要とする HTTPS などのプロトコルでは、

証明書は自己署名することも、任意の認証局（CA）から取得することもできます。
有効期限が切れている証明書や将来の日付の証明書も許可されます。

ヘッダー

HTTP または HTTPS プロトコルのヘルスチェックを構成するときに、--host フラグを使用して HTTP Host ヘッダーを指定できます。

ロードバランサは、構成したカスタムリクエストヘッダーをヘルスチェックプローブではなく、クライアントリクエストにのみ追加します。そのため、バックエンドで認可に特定のヘッダーが必要であり、ヘルスチェックパケットにヘッダーが含まれていない場合、ヘルスチェックが失敗する可能性があります。

ヘルスチェックの例

次のパラメータでヘルスチェックが構成されている場合:

間隔: 30 秒
タイムアウト: 5 秒
プロトコル: HTTP
異常しきい値: 2（デフォルト）
正常しきい値: 2（デフォルト）

ヘルスチェックは次のように機能します。

各ヘルスチェックプローバーは次の処理を行います。
1. ソース IP アドレスからバックエンドインスタンスへの HTTP 接続を 30 秒ごとに開始します。
2. HTTP 200 (OK) ステータスコードが返されるまで最大 5 秒間待ちます（HTTP および HTTPS プロトコルの指定された成功基準）。
少なくとも 1 つのヘルスチェックプローブシステムが次の処理を行う場合、バックエンドは異常とみなされます。
1. 接続の拒否、接続のタイムアウト、ソケットのタイムアウトが原因で、連続する 2 つのプローブで HTTP 200 (OK) レスポンスを受信しない。
2. プロトコル固有の成功基準に一致しないレスポンスを連続で 2 つ受信する。
少なくとも 1 つのヘルスチェックプローブシステムが、プロトコル固有の成功基準を満たすレスポンスを連続で 2 つ受信した場合、バックエンドは正常とみなされます。

この例では、各プローバーは 30 秒ごとに接続を開始します。タイムアウトの時間にかかわらず（接続がタイムアウトしたかどうかにかかわらず）、プローバーの接続試行の間隔は 30 秒です。つまり、タイムアウトは常にその間隔以下であることが必要で、タイムアウトにより間隔が引き延ばされることはありません。

制限事項

GDC ヘルスチェックは VM エンドポイントのみを処理します。
ヘルスチェックを使用するロードバランサは、Pod と VM を混合バックエンドとして構成できません。ロードバランサのエンドポイントは、Pod のみまたは VM のみで構成されている必要があります。現時点では、ロードバランサのエンドポイントは Pod のみまたは VM のみで構成する必要があります。
ロードバランサと関連するヘルスチェックの変更はまだサポートされていません。