Google Kubernetes Engine（GKE）でのロード バランシングの問題により、HTTP 502 エラーなどのサービスの中断が発生したり、アプリケーションへのアクセスが妨げられたりすることがあります。
このドキュメントでは、外部 Ingress からの 502 エラーのトラブルシューティング方法と、ロードバランサ ログや check-gke-ingress などの診断ツールを使用して問題を特定する方法について説明します。
この情報は、GKE でロード バランシングされたサービスを構成して維持するプラットフォーム管理者、運用担当者、アプリケーション デベロッパーにとって重要です。 Cloud de Confiance by S3NS のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。
外部 Ingress により HTTP 502 エラーが発生する
外部 Ingress リソースの HTTP 502 エラーのトラブルシューティングを行うには、次のガイダンスに従ってください。
- Ingress によって参照される各 GKE Service に関連付けられている各バックエンド サービスのログを有効にします。
- ステータスの詳細を使用して、HTTP 502 レスポンスの原因を特定します。バックエンドからの HTTP 502 レスポンスを示すステータスの詳細には、ロードバランサではなく、処理 Pod 内でのトラブルシューティングが必要です。
非マネージド インスタンス グループ
外部 Ingress が非マネージド インスタンス グループ バックエンドを使用している場合、外部 Ingress リソースで HTTP 502 エラーが発生することがあります。この問題は、次のすべての条件が満たされている場合に発生します。
- クラスターでは、すべてのノードプール内に多数のノードが含まれています。
- Ingress によって参照される 1 つ以上の Service の処理 Pod が、少数のノードにのみ配置されています。
- Ingress が参照する Service が
externalTrafficPolicy: Localを使用します。
外部 Ingress が非マネージド インスタンス グループのバックエンドを使用しているかどうかを判断するには、次の操作を行います。
Cloud de Confiance コンソールの [Ingress] ページに移動します。
外部 Ingress の名前をクリックします。
ロードバランサの名前をクリックします。ロード バランシングの詳細ページが表示されます。
[バックエンド サービス] セクションの表で、外部 Ingress が NEG またはインスタンス グループのどちらを使用しているかを確認します。
この問題を解決するには、次のいずれかの解決策を使用します。
- VPC ネイティブ クラスタを使用します。
- 外部 Ingress が参照する Service ごとに
externalTrafficPolicy: Clusterを使用します。この解決策では、パケットの送信元で元のクライアント IP アドレスが失われます。 node.kubernetes.io/exclude-from-external-load-balancers=trueアノテーションを使用します。クラスタ内の外部 Ingress またはLoadBalancerService によって参照される Service の処理 Pod を実行していないノードまたはノードプールに、アノテーションを追加します。
L4 ロードバランサのロギング構成
このセクションでは、外部パススルー ネットワーク ロードバランサまたは内部パススルー ネットワーク ロードバランサのロギングを有効にした場合のトラブルシューティング情報を提供します。
ロギング構成のステータスをモニタリングする
GKE L4LB コントローラは、Service の status.conditions タイプを介してロギングの調整ステータスに関するフィードバックを提供します。このステータスは、次のコマンドを実行して確認できます。
kubectl get svc SERVICE_NAME -o yaml
次のように置き換えます。
SERVICE_NAME: クラスタの名前。
出力で LoggingConfigManaged 条件タイプを探します。次の表に、この条件の考えられる理由を示します。
| 条件のステータス | 理由 | 説明 |
|---|---|---|
| 正しい | 調整済み | コントローラは、L4LBConfig CRD で定義されたロギング構成をアクティブに適用しています。 |
| False | 管理対象外 | logging セクションが L4LBConfig CRD にないか、アノテーションが削除されました。コントローラが管理を停止し、バックエンド サービスが最後の既知の状態のままになっています。 |
| False | 見つからない | Service アノテーションで参照されている L4LBConfig リソースが見つかりません。 |
| False | 無効 | L4LBConfig リソースが optionalFields パラメータのクロス検証に失敗しました。 |
| False | エラー | バックエンド サービスの調整中にエラーが発生しました。 |
コーストの動作について
Service マニフェストから networking.gke.io/l4lb-config アノテーションが削除された場合、または参照されている L4LBConfig リソースが削除された場合、構成は Coast 状態になります。
この状態では、GKE コントローラはロギング設定の管理を停止しますが、 Cloud de Confiance by S3NS バックエンド サービスをデフォルト設定にリセットしません。代わりに、バックエンド サービスは最後の既知の正常な状態にとどまります。通常、警告イベントは、Kubernetes が構成を制御しなくなったことを通知するために発行されます。
ロードバランサのログを使用してトラブルシューティングを行う
内部パススルー ネットワーク ロードバランサのログと外部パススルー ネットワーク ロードバランサのログを使用して、ロードバランサに関する問題のトラブルシューティングを行い、ロードバランサから GKE リソースへのトラフィックを関連付けることができます。
ログは接続ごとに集約され、ほぼリアルタイムでエクスポートされます。ログは、LoadBalancer Service のデータパスに関連する GKE ノードごとに、上り（内向き）トラフィックと下り（外向き）トラフィックの両方に対して生成されます。ログエントリには、次のような GKE リソースの追加フィールドが含まれます。
- クラスタ名
- クラスタのロケーション
- サービス名
- サービスの Namespace
- Pod 名
- Pod の Namespace
診断ツールを使用してトラブルシューティングを行う
check-gke-ingress 診断ツールは、一般的な構成の間違いについて Ingress リソースを検査します。check-gke-ingress ツールは次の方法で使用できます。
- クラスタで
gcpdiagコマンドライン ツールを実行します。Ingress の結果がチェックルールgke/ERR/2023_004セクションに表示されます。 check-gke-ingressツールを単独で使用するか、または check-gke-ingress の手順に沿って kubectl プラグインとして使用します。