Ingress ヘルスチェックのトラブルシューティング

このページでは、Google Kubernetes Engine（GKE）の 上り（内向き）ヘルスチェックに関連する問題を解決する方法について説明します。

上り（内向き）ヘルスチェックの仕組みを理解する

トラブルシューティングの手順に進む前に、GKE でのヘルスチェックの仕組みと、ヘルスチェックを成功させるために留意すべき考慮事項を理解しておくと役に立ちます。

デフォルトの Ingress コントローラを使用して Ingress によって 1 つ以上の Service を公開すると、GKE によって従来のアプリケーション ロードバランサまたは内部アプリケーション ロードバランサが作成されます。こうしたロードバランサでは、いずれも 1 つの URL マップで複数のバックエンド サービスがサポートされます。各バックエンド サービスは 1 つのKubernetes Service に対応し、各バックエンド サービスは Trusted Cloud ヘルスチェックを 1 つ参照する必要があります。このヘルスチェックはクラスタの外部で実装されるため、Kubernetes の liveness プローブまたは readiness プローブとは異なります。

ロードバランサのヘルスチェックは、バックエンド サービスごとに指定されます。ロードバランサのすべてのバックエンド サービスに同じヘルスチェックを実施できますが、ロードバランサ全体に対してはヘルスチェック リファレンスが（Ingress オブジェクト自体では）指定されません。

GKE は、次のいずれかの方法に基づいてヘルスチェックを作成します。

  • BackendConfig CRD: Service がロードバランサとやり取りする方法を正確に制御できるカスタム リソース定義（CRD）。BackendConfig CRD を使用すると、対応するバックエンド サービスに関連付けられたヘルスチェックのカスタム設定を指定できます。こうしたカスタム設定により、従来のアプリケーション ロードバランサと Ingress によって作成された内部アプリケーション ロードバランサの両方のヘルスチェックをより柔軟に制御できます。
  • readiness プローブ: Pod 内のコンテナがトラフィックを処理する準備ができているかどうかを判断する診断チェック。GKE Ingress コントローラは、その Service のサービング Pod で使用されている readiness プローブ に基づいて、Service のバックエンド サービスのヘルスチェックを作成します。パス、ポート、プロトコルなどのヘルスチェック パラメータは、readiness プローブの定義から導出できます。
  • デフォルト値: BackendConfig CRD を構成しない場合や、readiness プローブの属性を定義しない場合のパラメータ。
ベスト プラクティス:

BackendConfig CRD を使用して、ロードバランサのヘルスチェック設定を細かく制御します。

GKE は、次の手順を使用して、Kubernetes Service に対応する各バックエンド サービスのヘルスチェックを作成します。

  • Service が healthCheck 情報を使用して BackendConfig CRD を参照する場合、GKE はそれを使用してヘルスチェックを作成します。このヘルスチェックの作成方法は、GKE Enterprise Ingress コントローラと GKE Ingress コントローラの両方でサポートされます。

  • Service が BackendConfig CRD を参照していない場合:

    • サービング Pod が使用するPod テンプレートに、ヘルスチェック パラメータとして解釈できる属性がある readiness プローブを持つコンテナがある場合、GKE でヘルスチェックのパラメータの一部またはすべてを推定できます。実装の詳細については、readiness プローブからのパラメータ、ヘルスチェック パラメータの作成に使用できる属性のリストについては、デフォルト パラメータと推定パラメータをご覧ください。readiness プローブからのパラメータの推定は、GKE Ingress コントローラでのみサポートされています。

    • Service のサービング Pod の Pod テンプレートに、ヘルスチェック パラメータとして解釈できる属性がある readiness プローブを持つコンテナがない場合、デフォルト値を使用してヘルスチェックが作成されます。GKE Enterprise Ingress コントローラと GKE Ingress コントローラの両方で、デフォルト値のみを使用してヘルスチェックを作成できます。

考慮事項

このセクションでは、BackendConfig CRD を構成するときや、readiness プローブを使用するときに注意すべき考慮事項について説明します。

BackendConfig CRD

BackendConfig CRD を構成する際は、次の点を考慮してください。

  • コンテナ ネイティブのロード バランシングを使用している場合は、BackendConfig マニフェストのヘルスチェック ポートがサービスを提供する Pod の containerPort と一致していることを確認してください。
  • インスタンス グループのバックエンドでは、BackendConfig マニフェストのヘルスチェック ポートが Service によって公開される nodePort と一致していることを確認します。
  • 上り（内向き）は、カスタム ヘルスチェック構成に対する gRPC をサポートしていません。BackendConfig は、HTTP、HTTPS、または HTTP2 プロトコルを使用したヘルスチェックの作成のみをサポートします。BackendConfig CRD でプロトコルを使用する方法の例については、gke-networking-recipes をご覧ください。

詳細については、BackendConfig CRD を使用するタイミングをご覧ください。

readinessProbe

HTTP または HTTPS ロード バランシングで GKE 上り（内向き）を使用すると、GKE はヘルスチェック プローブを送信して、アプリケーションが正しく実行されているかどうかを判断します。次の条件が満たされている限り、これらのヘルスチェック プローブは、Pod の YAML 構成の spec.containers[].readinessProbe.httpGet.port セクションで定義した Pod の特定のポートに送信されます。

  • spec.containers[].readinessProbe.httpGet.port で指定された readiness プローブのポート番号は、コンテナ内でアプリケーションがリッスンしている実際のポートと一致する必要があります。このポートは、Pod 構成の containers[].spec.ports.containerPort フィールドで定義されています。
  • サービング Pod の containerPort は、Service の targetPort と一致する必要があります。これにより、トラフィックが Service から Pod の正しいポートに転送されます。
  • 上り（内向き）のサービス バックエンド ポートの仕様では、サービス構成の spec.ports[] セクションの有効なポートを参照する必要があります。これには、次の 2 つの方法があります。
    • 上り（内向き）の spec.rules[].http.paths[].backend.service.port.name が、対応する Service で定義された spec.ports[].name と一致する。
    • 上り（内向き）の spec.rules[].http.paths[].backend.service.port.number が、対応する Service で定義された spec.ports[].port と一致する。

一般的なヘルスチェックの問題のトラブルシューティング

次のトラブルシューティングのフローチャートを使用して、ヘルスチェックの問題を特定します。

上り（内向き）ヘルスチェックのトラブルシューティング。
図: ヘルスチェックのトラブルシューティング

このフローチャートでは、次のトラブルシューティングのガイダンスが問題の発生場所の特定に役立ちます。

  1. Pod の健全性を調査する: ヘルスチェックが失敗した場合は、Service の処理元の Pod のステータスを確認します。Pod が実行されておらず、正常でない場合は、次の手順を実行します。

    • Pod ログで、実行を妨げるエラーや問題がないか確認する。
    • readiness プローブと liveness プローブのステータスを確認する。

  2. ヘルスチェックのロギング: ヘルスチェックのロギングが有効になっていることを確認します。

  3. ファイアウォール構成を確認する: ファイアウォール ルールで、ヘルスチェック プローブが Pod に到達できることを確認します。入力されていない場合は、次の手順を実行します。

    • ファイアウォール ルールをチェックして、ヘルスチェック プローブの IP アドレス範囲からの上り（内向き）トラフィックが許可されていることを確認する。
    • これらの IP アドレス範囲に対応するように、必要に応じてファイアウォール ルールを調整する。

  4. パケット キャプチャを分析する: ファイアウォールが正しく構成されている場合は、パケット キャプチャを実行して、アプリケーションがヘルスチェックに応答しているかどうかを確認します。パケット キャプチャで成功のレスポンスが示されている場合は、Trusted Cloud by S3NS サポートにお問い合わせください。

  5. アプリケーションのトラブルシューティング: パケット キャプチャで成功したレスポンスが確認できない場合は、アプリケーションがヘルスチェック リクエストに正しく応答していない理由を調査します。ヘルスチェックが Pod の正しいパスとポートをターゲットにしていることを確認し、アプリケーション ログ、構成ファイル、依存関係を調べます。エラーが見つからない場合は、 Trusted Cloud by S3NS サポートにお問い合わせください。

アプリケーションがヘルスチェックに応答しない

アプリケーションが、構成されたパスとポートでのヘルスチェック中に、想定されるステータス コード（HTTP の場合は 200 OK、TCP の場合は SYN、ACK）で応答しません。

アプリケーションがヘルスチェックに正しく応答しない場合は、次のいずれかの理由が考えられます。

  • ネットワーク エンドポイント グループ（NEG）:
    • アプリケーションが Pod 内で正しく実行されていません。
    • アプリケーションが構成されたポートまたはパスでリッスンしていません。
    • ネットワーク接続性の問題により、ヘルスチェックが Pod に到達できません。
  • インスタンス グループ:
    • インスタンス グループ内のノードが正常でありません。
    • アプリケーションがノードで正しく実行されていません。
    • ヘルスチェック リクエストがノードに到達していません。

ヘルスチェックが失敗した場合は、設定に基づいて次のように問題をトラブルシューティングします。

NEG の場合:

  1. kubectl exec を使用して Pod にアクセスします。

    kubectl exec -it pod-name -- command

    フラグ -it は、インタラクティブ ターミナル セッションを提供します（i はインタラクティブ、t は TTY）。

    次のように置き換えます。

    • pod-name: Pod の名前。
    • command: Pod 内で実行するコマンド。最も一般的なコマンドは、対話型シェルを取得するための bash または sh です。

  2. curl コマンドを実行して、接続性とアプリケーションの応答性をテストします。

    • curl localhost:<Port>/<Path>
    • curl -v http://<POD_IP>/[Path configured in HC]
    • curl http://localhost/[Path configured in HC]

インスタンス グループの場合:

  1. ノードが正常で、デフォルトのヘルスチェック プローブに応答していることを確認します。
  2. ノードは正常だが、アプリケーション Pod が応答しない場合は、アプリケーションをさらに調査します。
  3. リクエストが Pod に到達しない場合は、GKE ネットワーキングの問題である可能性があります。詳しくは、 Trusted Cloud by S3NS サポートまでお問い合わせください。

Pod の readiness プローブの編集時にエラーが発生する

Pod の readiness プローブを編集してヘルスチェック パラメータを変更しようとすると、次のようなエラーが発生します。

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

上り（内向き）（および対応するロードバランサ）にすでにリンクされている Service に関連付けられた Pod の readiness プローブを変更した場合、GKE はロードバランサのヘルスチェック構成を自動的に更新しません。これにより、Pod の readiness チェックとロードバランサのヘルスチェックの間に不一致が生じ、ヘルスチェックが失敗します。

この問題を解決するには、Pod と 上り（内向き）リソースを再デプロイします。これにより、GKE はロードバランサとそのヘルスチェックを再作成し、新しい readiness プローブの設定を組み込みます。

デプロイとロードバランサが開始しない

デプロイが開始されず、上り（内向き）コントローラのロードバランサの背後にあるバックエンド サービスが異常とマークされている場合は、readiness プローブの失敗が原因である可能性があります。

readiness プローブの失敗を示す次のエラー メッセージが表示されることがあります。

Readiness probe failed: connection refused

Pod 内のアプリケーションが、Pod の YAML 構成で構成された readiness プローブに正しく応答しない。これは、アプリケーションが正しく起動しない、間違ったポートでリッスンしている、初期化中にエラーが発生したなど、さまざまな理由が考えられます。

この問題を解決するには、次の手順でアプリケーションの構成または動作の不一致を調査して修正します。

  • アプリケーションが正しく構成され、readiness プローブのパラメータで指定されたパスとポートで応答していることを確認します。
  • アプリケーション ログを確認し、起動に関する問題やエラーのトラブルシューティングを行います。
  • Pod 構成の containerPort が、Service の targetPort と上り（内向き）で指定されたバックエンド ポートと一致していることを確認します。

自動の上り（内向き）ファイアウォール ルールがない

上り（内向き）リソースを作成しましたが、トラフィックがバックエンド サービスに到達しません。

通常、上り（内向き）リソースの作成時に GKE が作成する自動の上り（内向き）ファイアウォール ルールがないか、誤って削除されています。

バックエンド サービスへの接続性を復元するには、次の操作を行います。

  • VPC ネットワークに自動の上り（内向き）ファイアウォール ルールが存在することを確認します。
  • ルールがない場合は、手動で再作成するか、上り（内向き）リソースを削除して再作成し、自動作成をトリガーできます。
  • ファイアウォール ルールで、上り（内向き）リソースで定義されている適切なポートとプロトコルのトラフィックが許可されていることを確認します。

BackendConfig マニフェストで使用されているプロトコルが正しくない

TCP タイプのプロトコルで BackendConfig CRD を構成すると、次のエラーが表示されます。

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

BackendConfig は、HTTP、HTTPS、または HTTP/2 プロトコルのみを使用したヘルスチェックの作成をサポートします。詳細については、HTTP、HTTPS、HTTP/2 での成功基準をご覧ください。

次のステップ