本頁列出 GKE 網路的已知問題。本頁面適用於管理底層技術基礎架構生命週期，以及在服務等級目標 (SLO) 未達成或應用程式失敗時，回應快訊和頁面的管理員和架構師。
如要依產品版本篩選已知問題，請從下列下拉式選單選取篩選條件。
選取 GKE 版本：
或者，搜尋您的問題：
| 已識別版本 | 已修正的版本 | 問題和解決方法 |
|---|---|---|
| 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 版本時，就會觸發這個問題：
發生這個問題時，排定在受影響節點上的新 Pod 無法啟動，並會傳回類似以下的錯誤訊息： 解決方法： 如要解決這個問題，請將緩解措施 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 |
|
使用舊版網路的叢集發生 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 |
|
新建立的節點不會新增至第 4 層內部負載平衡器為內部 LoadBalancer 服務建立的負載平衡器，可能會遺漏後端執行個體群組中新建立的節點。 Google Cloud 如果叢集縮放為零個節點，然後再縮放回一或多個節點，這個問題就會最為明顯。 解決方法：
|
| 1.31、1.32 |
|
因從 CRD 狀態移除 storedVersions 而導致 Gateway API 問題
GKE 中的 Kube-Addon-Manager 會從 Gateway API CRD (例如 如果叢集符合下列所有條件，可能就會面臨風險：
解決方法： 建議的解決方法是延後叢集升級，直到問題解決為止。
或者，如果需要升級叢集版本，您必須將所有受影響的 Gateway API CRD 的儲存空間版本更新為
|
| 1.32 |
|
新的 Pod 無法初始化，停滯在 ContainerCreating 狀態
無法建立新的 Pod，且 Pod 會停留在 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 ID 集合的記憶體內資料結構，未與 Kubernetes API 伺服器狀態正確同步。
如要確認用於建立叢集的 GKE 版本，請使用下列指令查詢 gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
如果 GKE 叢集已啟用記錄功能， 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 控制器設定為為 Service 建立獨立 NEG，且之後從 Service 移除其中一個設定的通訊埠，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.6-gke.1900 以上的叢集，可能會間歇性發生連線建立失敗的情況。 失敗的機率很低，而且不會影響所有叢集。症狀出現後幾天，故障情形應會完全停止。 |
| 1.27、1.28、1.29 |
|
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 資訊清單中將 |
| 1.27、1.28 |
|
髮夾連線流程的封包捨棄如果叢集已啟用 GKE Dataplane V2，當 Pod 使用服務建立與自身的 TCP 連線時 (也就是 Pod 同時是連線的來源和目的地)，GKE Dataplane V2 eBPF 連線追蹤功能會錯誤追蹤連線狀態，導致 conntrack 項目洩漏。 如果連線元組 (通訊協定、來源/目的地 IP 和來源/目的地通訊埠) 遭到洩漏，使用相同連線元組的新連線可能會導致回傳封包遭到捨棄。 解決方法： 請使用下列其中一種解決方法：
|
| 1.31.0-gke.1506000 之前的版本 | 1.31.0-gke.1506000 以上版本 |
GKE 多重網路中裝置輸入的網路名稱過長，導致作業失敗建立叢集失敗，並顯示下列錯誤：
解決方法： 裝置輸入的網路物件名稱長度不得超過 41 個字元。每個 UNIX 網域通訊端的完整路徑都會組成，包括對應的網路名稱。Linux 對通訊端路徑長度設有限制 (小於 107 個位元組)。扣除目錄、檔案名稱前置字串和 |
| 1.27、1.28、1.29、1.30 |
|
升級控制層後，
|
| 1.31、1.32 |
|
在同一節點上執行的 Pod 之間，UDP 流量中斷如果叢集啟用節點內瀏覽權限，在相同節點上執行的 Pod 之間，UDP 流量可能會中斷。 當 GKE 叢集節點升級至或建立於下列任一 GKE 版本時，就會觸發這個問題：
受影響的路徑是同一節點上透過 Hostport 或 Service 的 Pod 對 Pod UDP 流量。 解決方法 將叢集升級至下列其中一個修正版本：
|
| 1.28、1.29、1.30、1.31 |
在節點總數少於 3 個且 vCPU 不足的叢集上，Calico Pod 狀態不佳如果叢集符合下列所有條件，就無法排定 Calico-typha 和 calico-node Pod：總節點數少於 3 個、每個節點的可分配 vCPU 數為 1 個或更少，以及已啟用網路政策。這是因為 CPU 資源不足。 解決方法：
|
|
控制層升級期間，可用區叢集的多叢集閘道 (MCG) 中斷在 GKE 區域叢集上使用多叢集閘道 (MCG) 進行部署時，如果發生導致控制層重新啟動的事件 (例如叢集升級)，可能會發生服務中斷情形，並出現 `503` 錯誤。這是因為 MCG 依賴舊版機制來探索網路端點群組 (NEG)，當區域叢集中的節點在控制層重新啟動期間暫時無法使用時，就會錯誤地回報零個後端。這會導致負載平衡器移除所有後端，造成流量流失。 解決方法：
|