GKE ネットワーキングの既知の問題

このページでは、GKE ネットワーキングの既知の問題について説明します。このページは、基盤となるテクノロジー インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する管理者とアーキテクトを対象としています。

既知の問題をプロダクト バージョンでフィルタするには、次のプルダウン メニューからフィルタを選択します。

GKE バージョンを選択します。

または、問題を検索します。

識別されたバージョン 修正済みのバージョン 問題と回避策
1.30、1.31、1.32

新しく作成されたノードがレイヤ 4 内部ロードバランサに追加されない

内部 LoadBalancer Service 用に作成された Google Cloud ロードバランサで、バックエンド インスタンス グループに新しく作成されたノードが欠落することがあります。

この問題は、ノード数がゼロにスケーリングされた後、1 つ以上のノードにスケールバックされたクラスタで最も顕著になります。

回避策:

  • GKE のサブセット化を有効にして、Service を再作成します。

    注: GKE のサブセット化を有効にした後、無効にすることはできません。

  • 別の内部 LoadBalancing Service を作成します。同期すると、影響を受ける Service のインスタンス グループも修正されます。新しい Service は同期後に削除できます。
  • いずれかのノードから node.kubernetes.io/exclude-from-external-load-balancers ラベルを追加してから削除します。
  • クラスタにノードを追加します。Service が機能し始めたら、ノードを削除できます。
1.27、1.28、1.29、1.30、1.31

Service からポートが削除されると NEG コントローラがエンドポイントの管理を停止する

Service のスタンドアロン NEG を作成するように NEG コントローラが構成され、構成されたポートのいずれかが後で Service から削除されると、NEG コントローラは最終的に NEG のエンドポイントの管理を停止します。これは、ユーザーがスタンドアロン NEG アノテーションを作成する Service に加えて、GKE Gateway、MCI、GKE マルチクラスタ Gateway によって参照される Service にも影響します。

回避策:

スタンドアロン NEG アノテーションを使用して Service からポートを削除する場合は、該当するポートを削除するようにアノテーションも更新する必要があります。
1.28

Gateway TLS 構成エラー

GKE バージョン 1.28.4-gke.1083000 を実行するクラスタで Gateway の TLS を構成する際に問題が確認されました。これは、SSLCertificate または CertificateMap を使用する TLS 構成に影響します。既存の Gateway を使用してクラスタをアップグレードする場合、Gateway への更新は失敗します。新しい Gateway の場合、ロードバランサはプロビジョニングされません。この問題は、今後の GKE 1.28 パッチ バージョンで修正される予定です。
1.27、1.28、1.29
  • 1.26.13-gke.1052000 以降
  • 1.27.10-gke.1055000 以降
  • 1.28.6-gke.1095000 以降
  • 1.29.1-gke.1016000 以降

断続的に接続を確立できない

コントロール プレーン バージョン 1.26.6-gke.1900 以降のクラスタで、接続の確立が断続的に失敗することがあります。

障害が発生する可能性は低く、すべてのクラスタに影響するわけではありません。障害は、症状が現れてから数日後に完全に停止します。
1.27、1.28、1.29
  • 1.27.11-gke.1118000 以降
  • 1.28.7-gke.1100000 以降
  • 1.29.2-gke.1217000 以降

Container-Optimized OS での DNS 解決に関する問題

Container-Optimized OS ベースのノードを使用する GKE クラスタで実行されているワークロードで、DNS 解決の問題が発生することがあります。
1.28 1.28.3-gke.1090000 以降

接続トラッキング ルックアップが正しくないため、ネットワーク ポリシーによって接続が切断される

GKE Dataplane V2 が有効になっているクラスタの場合、クライアント Pod が Service または内部パススルー ネットワーク ロードバランサの仮想 IP アドレスを使用して自身に接続すると、データプレーンでの conntrack ルックアップが正しく行われず、応答パケットが既存の接続の一部として識別されません。つまり、Pod の上り（内向き）トラフィックを制限するネットワーク ポリシーが、誤ってパケットに適用されます。

この問題の影響は、Service に構成された Pod の数によって異なります。たとえば、Service にバックエンド Pod が 1 つある場合、接続は常に失敗します。Service にバックエンド Pod が 2 つある場合、接続は 50% の確率で失敗します。

回避策:

この問題は、Service マニフェストの port と containerPort を同じ値に構成すると軽減できます。
1.27、1.28
  • 1.28.3-gke.1090000 以降
  • 1.27.11-gke.1097000 以降

ヘアピン接続フローのパケット ドロップ

GKE Dataplane V2 が有効になっているクラスタで、Pod が Service を使用して自身との TCP 接続を作成し、Pod が接続の送信元と宛先の両方である場合、GKE Dataplane V2 eBPF 接続トラッキングは接続状態を誤って追跡し、conntrack エントリがリークします。

接続タプル（プロトコル、送信元/宛先 IP、送信元/宛先ポート）がリークすると、同じ接続タプルを使用する新しい接続で、戻りパケットがドロップされる可能性があります。

回避策:

以下のいずれかの回避策をお試しください。

  • Pod 内で実行され、Service を使用して自身と通信する可能性があるアプリケーションに対して TCP 再利用（キープアライブ）を有効にします。これにより、TCP FIN フラグが発行されなくなり、conntrack エントリのリークを回避できます。
  • 短時間の接続を使用する場合は、Gateway などのプロキシ ロードバランサを使用して Pod を公開して、Service を公開します。これにより、接続リクエストの宛先がロードバランサの IP アドレスに設定され、GKE Dataplane V2 がループバック IP アドレスに対して SNAT を実行できなくなります。
1.31.0-gke.1506000 より前 1.31.0-gke.1506000 以降

GKE マルチネットワークのデバイス型ネットワークが、長いネットワーク名で失敗する

クラスタの作成が次のエラーで失敗します。

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

回避策:

デバイスタイプのネットワーク オブジェクト名の長さを 41 文字以下に制限します。各 UNIX ドメイン ソケットの完全パス（対応するネットワーク名を含む）が構成されます。Linux では、ソケットパスの長さに制限があります（107 バイト以下）。ディレクトリ、ファイル名の接頭辞、.sock 拡張子を考慮すると、ネットワーク名の上限は 41 文字になります。
1.27、1.28、1.29、1.30
  • 1.30.4-gke.1282000 以降
  • 1.29.8-gke.1157000 以降
  • 1.28.13-gke.1078000 以降
  • 1.27.16-gke.1342000 以降

コントロール プレーンのアップグレード後の hostPort Pod の接続の問題

ネットワーク ポリシーが有効になっているクラスタでは、hostPort Pod との接続の問題が発生する可能性があります。また、新しく作成された Pod の準備が完了するまでに 30 ～ 60 秒かかることがあります。

この問題は、クラスタの GKE コントロール プレーンが次のいずれかの GKE バージョンにアップグレードされたときにトリガーされます。

  • 1.30 ～ 1.30.4-gke.1281999
  • 1.29.1-gke.1545000 ～ 1.29.8-gke.1156999
  • 1.28.7-gke.1042000 ～ 1.28.13-gke.1077999
  • 1.27.12-gke.1107000 ～ 1.27.16-gke.1341999

回避策:

GKE コントロール プレーンのアップグレード直後にノードをアップグレードまたは再作成します。
1.28、1.29、1.30、1.31

合計ノード数が 3 未満で vCPU が不足しているクラスタで Calico Pod が正常でない

Calico-typha Pod と calico-node Pod は、合計ノード数が 3 未満で、各ノードに割り当て可能な vCPU が 1 つ未満で、ネットワーク ポリシーが有効になっているクラスタではスケジューリングできません。これは、CPU リソースが不足していることが原因です。

回避策:

  • 割り当て可能な vCPU を 1 つ使用するノードが 1 つあるノードプールを 3 つ以上にスケールします。
  • 単一ノードプールのサイズを、割り当て可能な vCPU が 1 つのノード 3 つ以上に変更します。
  • 単一ノードのノードプールでは、割り当て可能な vCPU が 2 つ以上あるマシンタイプを使用します。