GKE 網路已知問題

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

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

選取 GKE 版本：

或者，搜尋您的問題：

已識別版本 已修正的版本 問題和解決方法
1.31、1.32、1.33
  • 1.33.1-gke.1107000 以上版本

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

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

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

如要找出使用舊版網路的 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 服務建立的負載平衡器，可能會遺漏後端執行個體群組中新建立的節點。 Trusted Cloud by S3NS

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

解決方法：

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

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

  • 建立另一個內部負載平衡服務。同步處理後，受影響的服務也會修正執行個體群組。同步完成後，即可移除新服務。
  • 從其中一個節點新增並移除 node.kubernetes.io/exclude-from-external-load-balancers 標籤。
  • 將節點新增至叢集。服務開始運作後，即可移除節點。
1.27、1.28、1.29、1.30、1.31

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

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

解決方法：

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

閘道 TLS 設定錯誤

我們發現，在執行 GKE 1.28.4-gke.1083000 版的叢集中，設定閘道傳輸層安全標準 (TLS) 時會發生問題。這會影響使用 SSLCertificate 或 CertificateMap 的 TLS 設定。如果您要升級的叢集已有閘道，則對閘道所做的更新會失敗。如果是新的 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 使用服務或內部直通式網路負載平衡器的虛擬 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 的機器類型。