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

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

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

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

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

該当するバージョン 解決済みのバージョン 問題と回避策
1.31、1.32、1.33
  • 1.33.1-gke.1107000 以降

以前のネットワークを使用するクラスタでの上り（内向き）ロードバランサとサービス ロードバランサの停止

以前のネットワークとの互換性がないため、上り（内向き）または Service を使用してデプロイされた GKE マネジドのロードバランサのバックエンドが切り離されます。これにより、ロードバランサにアクティブなバックエンドがなくなり、これらのロードバランサへのすべての受信リクエストがドロップされます。

この問題は、以前のネットワークを使用し、バージョン 1.31 以降の GKE クラスタに影響します。

以前のネットワークを使用している GKE クラスタを特定するには、次のコマンドを実行します。

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"

以前のネットワークを使用するクラスタの場合、このコマンドの出力は空になります。

回避策:

以前のネットワークはしばらく前に非推奨になったため、推奨される解決策はレガシー ネットワークを VPC ネットワークに移行することです。これを行うには、GKE クラスタを含む以前のネットワークを変換します。現時点でこの移行を実行できない場合は、Cloud カスタマーケアにお問い合わせください。
1.30、1.31、1.32
  • 1.30.10-gke.1070000 以降
  • 1.31.5-gke.1068000 以降
  • 1.32.1-gke.1002000 以降

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

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

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

回避策

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

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

  • 別の内部ロード バランシング 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 コントローラが構成されており、構成されたポートの 1 つが後で Service から削除されると、NEG コントローラは最終的に NEG のエンドポイントの管理を停止します。ユーザーがスタンドアロン NEG アノテーションを作成する Service に加えて、GKE Gateway、MCI、GKE Multi Cluster 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、送信元 / 宛先ポート）がリークすると、同じ接続タプルを使用する新しい接続で、戻りパケットがドロップされる可能性があります。

回避策:

以下のいずれかの回避策を使用します。

  • Service を使用して自身と通信する可能性がある Pod で実行されているアプリケーションに対して 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.31、1.32
  • 1.32.1-gke.1729000 以降
  • 1.31.6-gke.1020000 以降

同じノードで実行されている Pod 間の UDP トラフィックが中断される

ノード内の可視化が有効になっているクラスタでは、同じノードで実行されている Pod 間の UDP トラフィックが中断されることがあります。

この問題は、GKE クラスタノードが次のいずれかの GKE バージョンにアップグレードされた場合、または次のいずれかの GKE バージョンで作成された場合に発生します。

  • 1.32.1-gke.1729000 以降
  • 1.31.6-gke.1020000 以降

影響を受けるパスは、Hostport または Service を介した同じノード上の Pod 間 UDP トラフィックです。

解決策

クラスタを次のいずれかの修正バージョンにアップグレードします。

  • 1.32.3-gke.1927000 以降
  • 1.31.7-gke.1390000 以降
1.28、1.29、1.30、1.31

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

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

回避策

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