GKE 網路已知問題

本頁列出 GKE 網路的已知問題。本頁內容適用於管理基礎技術基礎架構生命週期，以及在服務等級目標 (SLO) 未達成或應用程式失敗時，回應快訊和頁面的管理員和架構師。

如要依產品版本篩選已知問題，請從下列下拉式選單選取篩選條件。

選取 GKE 版本：

或者，搜尋您的問題：

已識別版本 已修正的版本 問題和解決方法
1.29、1.30、1.31、1.32、1.33 1.34

刪除 FQDN 網路政策後，anetd Pod 中的 cilium-agent 容器會停止運作

啟用 GKE Dataplane V2 的叢集可能會發生 cilium-agent 容器暫時當機的情況，導致必須在資料層中編程的事件，協調時間會較長。這個問題是由於刪除 FQDN 網路政策時，發生空指標取消參照所致。

刪除 FQDN 網路政策會觸發這個問題。發生問題時，anetd Pod 中的 Cilium 代理程式容器會傳回類似以下的錯誤訊息： panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x33e237d]


解決方法：

如要解決這個問題，請修補 FQDN 政策，確保沒有任何 Pod 受到影響，藉此避免刪除政策：

      kubectl patch fqdnnetpol -n namespace policy-name --patch '
      spec:
        podSelector:
          matchLabels:
            miss: me
      '

解決方法

將叢集版本升級至 1.34 版
1.28、1.29、1.30、1.31、1.32、1.33

使用 GKE Dataplane V2 的節點發生 Pod IP 位址洩漏問題

啟用 GKE Dataplane V2 的叢集可能會發生節點上的 Pod IP 位址耗盡問題。這個問題是由容器執行階段錯誤所導致，當 Pod 在建立期間發生暫時性 CNI 錯誤時，可能會洩漏已分配的 IP 位址。

當 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.31、1.32、1.33
  • 1.33.1-gke.1107000 以上版本
  • 1.32.8-gke.1108000 以上版本

使用舊版網路的叢集發生 Ingress 和服務負載平衡器中斷問題

與舊版網路不相容，導致使用 Ingress 或 Service 部署的 GKE 管理負載平衡器後端遭到分離。這會導致負載平衡器沒有任何作用中的後端，進而導致所有傳入這些負載平衡器的要求遭到捨棄。

這個問題會影響使用舊版網路且版本為 1.31 以上的 GKE 叢集。

如要找出使用舊版網路的 GKE 叢集，請執行下列指令： 

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

如果叢集使用舊版網路，這個指令會產生空白輸出內容。

解決方法：

舊版網路已停用一段時間，因此建議您將舊版網路遷移至虛擬私有雲網路。方法是轉換含有 GKE 叢集的舊版網路。如果您目前無法執行這項遷移作業，請與 Cloud Customer Care 聯絡。

1.30、1.31、1.32
  • 1.30.10-gke.1070000 以上版本
  • 1.31.5-gke.1068000 以上版本
  • 1.32.1-gke.1002000 以上版本

新建立的節點不會新增至第 4 層內部負載平衡器

為內部 LoadBalancer 服務建立的負載平衡器，可能會遺漏後端執行個體群組中新建立的節點。 Google Cloud

如果叢集縮放為零個節點，然後再縮放回一或多個節點，這個問題就會最為明顯。

解決方法：

  • 開啟 GKE 子集，然後重新建立 Service。

    注意：GKE 子網路設定啟用後就無法關閉。

  • 建立另一個內部 LoadBalancing 服務。同步處理後，受影響的服務也會修正執行個體群組。同步完成後，即可移除新服務。
  • 從其中一個節點新增，然後移除 node.kubernetes.io/exclude-from-external-load-balancers 標籤。
  • 將節點新增至叢集。服務開始運作後，即可移除節點。
1.31、1.32
  • 1.31.7-gke.1158000 以上版本
  • 1.32.3-gke.1499000 以上版本

因從 CRD 狀態移除 storedVersions 而導致 Gateway API 問題

GKE 中的 Kube-Addon-Manager 會從 Gateway API CRD (例如 gateway、httpRoute、gatewayClass 和 referenceGrant) 的狀態中，錯誤地移除 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
  • 1.32.3-gke.1170000 以上版本

新的 Pod 無法初始化，停滯在 ContainerCreating 狀態

無法建立新 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 版本建立的 GKE 叢集，且版本介於 1.32 和 1.32.3-gke.1170000 之間。根本原因是，維護已分配 Cilium 身分集合的記憶體內資料結構，未與 Kubernetes API 伺服器狀態正確同步。

如要確認用於建立叢集的 GKE 版本，請使用下列指令查詢 initialClusterVersion 資源： 

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

如果 GKE 叢集已啟用記錄功能，cilium-agent 容器會使用下列查詢，在 Logs Explorer 中記錄 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
1.27、1.28、1.29、1.30、1.31

從服務中移除連接埠後，NEG 控制器會停止管理端點

如果 NEG 控制器設定為為服務建立獨立 NEG，且後來從服務中移除其中一個設定的通訊埠，NEG 控制器最終會停止管理 NEG 的端點。除了使用者建立獨立 NEG 註解的服務外，這也會影響 GKE 閘道、MCI 和 GKE 多叢集閘道參照的服務。

解決方法：

從具有獨立 NEG 註解的服務中移除通訊埠時，也必須更新註解，移除相關通訊埠。
1.28

閘道 TLS 設定錯誤

我們發現，在執行 GKE 1.28.4-gke.1083000 版的叢集中，設定閘道 TLS 時會發生問題。這會影響使用 SSLCertificate 或 CertificateMap 的 TLS 設定。如果升級的叢集已有閘道，更新閘道會失敗。對於新的閘道，系統不會佈建負載平衡器。我們將在日後推出的 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 使用服務或內部直通式網路負載平衡器的虛擬 IP 位址連線至自身時，由於資料平面中的 conntrack 查閱作業不正確，回覆封包不會識別為現有連線的一部分。這表示系統對封包強制執行網路政策，但該政策會限制 Pod 的傳入流量，因此不適用於封包。

這個問題的影響取決於服務設定的 Pod 數量。舉例來說，如果服務有 1 個後端 Pod，連線一律會失敗。如果服務有 2 個後端 Pod，連線失敗的機率為 50%。

解決方法：

如要解決這個問題，請在 Service 資訊清單中將 port 和 containerPort 設為相同的值。
1.27、1.28
  • 1.28.3-gke.1090000 以上版本
  • 1.27.11-gke.1097000 以上版本

髮夾連線流程的封包捨棄

如果叢集已啟用 GKE Dataplane V2，當 Pod 使用服務建立與自身的 TCP 連線時 (也就是 Pod 同時是連線的來源和目的地)，GKE Dataplane V2 eBPF 連線追蹤功能會錯誤追蹤連線狀態，導致 conntrack 項目洩漏。

如果連線元組 (通訊協定、來源/目的地 IP 和來源/目的地通訊埠) 遭到洩漏，使用相同連線元組的新連線可能會導致傳回封包遭到捨棄。

解決方法：

請使用下列其中一種解決方法：

  • 為在 Pod 中執行的應用程式啟用 TCP 重複使用 (保持連線)，該應用程式可能會使用 Service 與自身通訊。這樣就不會發出 TCP FIN 旗標，避免洩漏 conntrack 項目。
  • 使用存續時間較短的連線時，請使用 Proxy 負載平衡器 (例如 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 版本時，就會觸發這個問題：

  • 1.32.1-gke.1729000 以上版本
  • 1.31.6-gke.1020000 以上版本

受影響的路徑是同一節點上透過 Hostport 或 Service 的 Pod 對 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 和 calico-node Pod：總節點數少於 3 個、每個節點的可分配 vCPU 數為 1 個或更少，以及已啟用網路政策。這是因為 CPU 資源不足。

解決方法：

  • 將節點集區擴充至至少 3 個，每個集區有 1 個節點，並使用 1 個可分配的 vCPU。
  • 將單一節點集區的大小調整為至少 3 個節點，且每個節點有 1 個可分配的 vCPU。
  • 在單一節點的節點集區中，使用至少有 2 個可分配 vCPU 的機器類型。

控制層升級期間，可用區叢集的多叢集閘道 (MCG) 中斷

在 GKE 區域叢集上使用多叢集閘道 (MCG) 進行部署時，如果發生導致控制層重新啟動的事件 (例如叢集升級)，可能會發生服務中斷情形，並出現 `503` 錯誤。這是因為 MCG 依賴舊版機制來探索網路端點群組 (NEG)，當區域叢集中的節點在控制層重新啟動期間暫時無法使用時，就會錯誤地回報零個後端。這會導致負載平衡器移除所有後端，造成流量損失。

解決方法：

  • 建議的解決方案是從可用區 GKE 叢集遷移至區域 GKE 叢集。區域叢集具有高可用性控制層，可避免升級或重新啟動時發生單一故障點，進而觸發這個問題。

在特定情況下，就緒閘道可能會在 Ingress 健康狀態檢查回報健康狀態之前，傳回「誤判為真」的就緒狀態，在 Ingress 物件上產生類似下列的錯誤事件：

NEG is not attached to any BackendService with health checking. Marking condition "cloud.google.com/load-balancer-neg-ready" to True.

這個問題會導致 GKE 對部署工作負載執行滾動式更新時，負載平衡器向流量回報 503 錯誤 (failed_to_pick_backend)。

如果 Pod 數量相對較少 (例如 2 個)，與 NEG 數量相比，發生這種競爭情況的風險就會增加。系統會為每個區域建立 NEG，每個區域一個 NEG，通常會產生三個 NEG。如果 Pod 數量相對較多，以致於每個 NEG 在滾動式更新開始前一律有多個 Pod，則不太可能觸發這個競爭條件。

解決方法：

如要避免這種競爭情況，最好的方法是在網路端點群組中加入更多後端。請確認已設定滾動更新策略，確保至少有 1 個 Pod 隨時處於執行狀態。舉例來說，如果只有 2 個 Pod 正常執行，設定範例可能如下所示：

strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 0
     maxSurge: 1

上一個範例是建議。您必須根據多項因素 (例如副本數量) 更新策略。

GKE 每兩分鐘就會對容器原生負載平衡器進行垃圾收集。如果叢集在負載平衡器完全移除前就遭到刪除，就必須手動刪除負載平衡器的 NEG。

解決方法：

請執行下列指令來查看專案裡的 NEG：

gcloud compute network-endpoint-groups list

在指令輸出中，找出相關的 NEG。

如要刪除 NEG，請執行下列指令，並將 <var>NEG_NAME</var> 替換為 NEG 的名稱：

gcloud compute network-endpoint-groups delete <var>NEG_NAME</var>

使用 Pod 完備性回饋來管理工作負載發布作業的叢集，並不會發生這個問題。將工作負載部署到叢集時，或更新現有工作負載時，容器原生負載平衡器傳播新端點的所需時間可能會超過工作負載發布完成的所需時間。


解決方法：

將工作負載的 minReadySeconds 和 terminationGracePeriodSeconds 值設為 60 秒以上，確保服務不會因工作負載發布而中斷。

  • terminationGracePeriodSeconds 允許 Pod 安全關閉，方法是等待連線在 Pod 預定刪除後終止。
  • minReadySeconds 會在 Pod 建立後新增延遲期間。

您可能會認為 Pod 的 readinessProbe 中的 initialDelaySeconds 設定會受到容器原生負載平衡器尊重，但 readinessProbe 是由 kubelet 實作，而 initialDelaySeconds 設定控制的是 kubelet 健康狀態檢查，而非容器原生負載平衡器。容器原生負載平衡有自己的負載平衡健康狀態檢查。