このページでは、Service、Ingress、Gateway リソースを使用して Google Kubernetes Engine（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 が非マネージド インスタンス グループのバックエンドを使用しているかどうかを判断するには、次の操作を行います。
Trusted Cloud コンソールの [Ingress] ページに移動します。
外部 Ingress の名前をクリックします。
ロードバランサの名前をクリックします。ロード バランシングの詳細ページが表示されます。
[バックエンド サービス] セクションの表で、外部 Ingress が NEG またはインスタンス グループのどちらを使用しているかを確認します。
この問題を解決するには、次のいずれかの解決策を使用します。
- VPC ネイティブ クラスタを使用します。
- 外部 Ingress が参照する Service ごとに
externalTrafficPolicy: Clusterを使用します。この解決策では、パケットの送信元で元のクライアント IP アドレスが失われます。 node.kubernetes.io/exclude-from-external-load-balancers=trueアノテーションを使用します。クラスタ内の外部 Ingress またはLoadBalancerService によって参照される Service の処理 Pod を実行していないノードまたはノードプールに、アノテーションを追加します。
ロードバランサのログを使用してトラブルシューティングを行う
内部パススルー ネットワーク ロードバランサのログと外部パススルー ネットワーク ロードバランサのログを使用して、ロードバランサに関する問題のトラブルシューティングを行い、ロードバランサから 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 プラグインとして使用します。