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

GKE Dataplane V2 を使用するノードでの Pod IP アドレスのリーク

クラスタで GKE Dataplane V2 が有効になっていると、ノードで Pod IP アドレスが使い果たされる可能性があります。この問題は、Pod の作成中に一時的な CNI エラーが発生したときに、コンテナ ランタイムのバグ（割り当てられた IP アドレスがリークする可能性）が原因で発生します。

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

• 1.33 以降
• 1.32 以降
• 1.31.2-gke.1115000 以降
• 1.30.8-gke.1051001 以降
• 1.29.10-gke.1059000 以降
• 1.28.15-gke.1024000 以降

この問題が発生すると、影響を受けるノードでスケジュールされた新しい Pod が起動に失敗し、エラー メッセージ failed to assign an IP address to container が返されます。

回避策:

この問題を回避するには、緩和策の DaemonSet をクラスタに適用して、リークした IP リソースをクリーンアップします。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cleanup-ipam-dir
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: cleanup-ipam
  template:
    metadata:
      labels:
        name: cleanup-ipam
    spec:
      hostNetwork: true
      securityContext:
        runAsUser: 0
        runAsGroup: 0
        seccompProfile:
          type: RuntimeDefault
      automountServiceAccountToken: false
      containers:
      - name: cleanup-ipam
        image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e
        command:
        - /bin/bash
        - -c
        - |
          while true; do
          for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do
          hash="${hash%%[[:space:]]}"
          if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then
          grep -ilr $hash /hostipam
          fi
          done | xargs -r rm
          echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)"
          sleep 120s
          done
        volumeMounts:
        - name: host-ipam
          mountPath: /hostipam
        - name: host-ctr
          mountPath: /run/containerd
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
      volumes:
      - name: host-ipam
        hostPath:
          path: /var/lib/cni/networks/gke-pod-network
      - name: host-ctr
        hostPath:
          path: /run/containerd

• 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.10-gke.1070000 以降
• 1.31.5-gke.1068000 以降
• 1.32.1-gke.1002000 以降

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

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

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

回避策

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

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

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

• 1.31.7-gke.1158000 以降
• 1.32.3-gke.1499000 以降

CRD ステータスから storedVersions が削除されたことが原因で発生する Gateway API の問題

GKE の Kube-Addon-Manager が、gateway、httpRoute、gatewayClass、referenceGrant などの Gateway API CRD のステータスから v1alpha2 storedVersion を誤って削除します。この問題は、クラスタに v1alpha2 形式で保存されたこれらの CRD のインスタンスがまだ存在する場合でも発生します。storedVersions なしで GKE クラスタのバージョンをアップグレードすると、Gateway API 呼び出しが失敗します。呼び出しが失敗すると、Gateway API を実装するコントローラが破損する可能性もあります。

次のすべての条件を満たす場合、クラスタがリスクにさらされる可能性があります。

• クラスタで Gateway API が有効になっている。
• 過去に v1alpha2 バージョンの Gateway API CRD をインストールしたことがある。
• クラスタが影響を受ける GKE バージョンで実行されている。

回避策:

推奨される回避策は、問題が解決するまでクラスタのアップグレードを遅らせることです。

また、クラスタのバージョンをアップグレードする必要がある場合は、影響を受けるすべての Gateway API CRD のストレージ バージョンを v1beta1 に更新する必要があります。次の例では、gatewayClass CRD を更新します。

1. v1alpha2 ストレージ バージョンの有無を確認します。

   kubectl get crd gatewayclasses.gateway.networking.k8s.io -ojsonpath="{.status.storedVersions}"

2. クラスタに存在するすべての GatewayClass リソースで次のコマンドを実行して、ストレージ バージョンを v1beta1 に調整します。

   kubectl annotate gatewayclass gateway-class-name bump-storage-version="yes"

3. v1alpha2 ストレージ バージョンを削除し、ストレージ バージョンを v1beta1 に設定します。

   kubectl patch customresourcedefinitions gatewayclasses.gateway.networking.k8s.io --subresource='status' --type='merge' -p '{"status":{"storedVersions":["v1beta1"]}}'

4. 通常どおりにアップグレードを実行します。

• 1.32.3-gke.1170000 以降

ContainerCreating で新しい Pod の初期化が失敗する

新しい Pod を作成できず、ContainerCreating 状態のままになります。この問題が発生すると、サービス コンテナは次のログを記録します。

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded

この問題は、GKE バージョン 1.31 または 1.32 で作成された、1.32～1.32.3-gke.1170000 より前のバージョンの GKE クラスタに影響します。根本原因は、割り当てられた Cilium ID のコレクションを保持するインメモリ データ構造が、Kubernetes API サーバーの状態と正しく同期されていないことです。

クラスタの作成に使用された GKE のバージョンを確認するには、次のコマンドを使用して initialClusterVersion リソースをクエリします。

  gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
  

GKE クラスタでロギングが有効になっている場合、cilium-agent コンテナは次のクエリを使用して、ログ エクスプローラに unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key メッセージを記録します。

   resource.type="k8s_container"
   resource.labels.container_name="cilium-agent"
  

回避策:

一時的な回避策は、コントロール プレーンの再起動です。これを行うには、すでに実行中のバージョンにコントロール プレーンをアップグレードします。

  gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master
  

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

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

回避策:

スタンドアロン NEG アノテーションを含む Service からポートを削除する場合は、問題のポートを削除するようにアノテーションも更新する必要があります。

Gateway TLS 構成エラー

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

• 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.11-gke.1118000 以降
• 1.28.7-gke.1100000 以降
• 1.29.2-gke.1217000 以降

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

Container-Optimized OS ベースのノードを使用する GKE クラスタで実行されているワークロードで、DNS 解決の問題が発生する可能性があります。

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

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

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

回避策:

この問題は、Service マニフェストの port と containerPort を同じ値に構成すると軽減できます。

• 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 を実行できなくなります。

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.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.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 以降

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

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

回避策

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

コントロール プレーンのアップグレード中にゾーンクラスタで Multi-Cluster Gateway（MCG）が停止する

GKE ゾーンクラスタでマルチクラスタ Gateway（MCG）を使用するデプロイでは、クラスタのアップグレードなど、コントロール プレーンの再起動を引き起こすイベントの発生中に 503 エラーが発生し、停止することがあります。これは、MCG がネットワーク エンドポイント グループ（NEG）検出に以前のメカニズムを使用していることが原因で発生します。このメカニズムでは、コントロール プレーンの再起動中にゾーンクラスタ内のノードが一時的に使用できなくなると、誤ってバックエンドがゼロと報告されます。これにより、ロードバランサがすべてのバックエンドを削除し、トラフィックが失われます。

回避策

• 推奨される解決策は、ゾーン GKE クラスタからリージョン GKE クラスタへの移行です。リージョン クラスタには高可用性のコントロール プレーンがあるため、アップグレードや再起動中にこの問題を引き起こす単一障害点がなくなります。