GKE 已知問題

Autopilot Standard

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

本頁列出所有支援版本的已知問題，以及延長支援中最早版本之前的兩個子版本。版本結束延長支援後，所有 N-2 問題都會移除。舉例來說，當 1.30 版的延長支援期結束時，系統會移除 1.28 版和更早版本特有的已知問題。

如果您是 Google 開發人員計畫的成員，請儲存這個頁面，以便在發布與這個頁面相關的版本說明時收到通知。詳情請參閱「儲存的網頁」。

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

選取 GKE 版本：

1.35 1.34 1.33 1.32 1.31 1.30 1.29 1.28 1.27

選取問題類別：

設定 安裝 升級與更新 作業 記錄和監控 安全性 重設/刪除 效能

或者，搜尋你的問題：

類別	辨識出的版本	已修正的版本	問題和解決方法
作業	1.35 1.36 1.37	1.35.6-gke.1250001 以上版本 1.36.4-gke.1391002 以上版本 1.37.1-gke.1187000 以上版本	從中繼資料伺服器取得權杖的 HTTP POST 要求失敗，並出現 400 Bad Request 錯誤 工作負載使用 Workload Identity Federation for GKE，向 GKE 中繼資料伺服器 (例如 /computeMetadata/v1/instance/service-accounts/default/token 或 /computeMetadata/v1/instance/service-accounts/default/identity) 要求服務帳戶存取權杖或身分權杖，藉此向 Google Cloud API 進行驗證時，可能會失敗並顯示 HTTP 400 Bad Request (INVALID_ARGUMENT) 錯誤。 如果應用程式、用戶端程式庫或 API 閘道傳送 HTTP POST 要求，但要求主體中沒有有效的憑證鏈結，就會發生這個問題。在受影響的 GKE 版本中，對這些權杖端點的 POST 要求僅限用於繫結存取權和 ID 權杖。因此，如果要求的酬載為空白、採用表單編碼或 JSON 無效，就會遭到拒絕。 如要修正問題，請升級至任何發布管道子版本中的最新修補程式版本。 解決方法： 如要解決這個問題，請設定應用程式、用戶端程式庫或 API 閘道，在向中繼資料伺服器要求存取權或 ID 權杖時，使用 GET 方法，而非 POST，如以下範例所示： curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" 如果工作負載使用第三方 SDK 或閘道 (例如 MuleSoft Flex Gateway、IBM App Connect 或自訂 HTTP 指令碼)，預設會將 POST 要求傳送至中繼資料伺服器端點，請更新設定或用戶端程式庫，改為傳送 GET 要求。
升級與更新	1.33 以上版本	待定	控制層進行兩階段微幅升級時，Pod 未排定時間，且配額用盡。 在 Autopilot 叢集中，如果控制層使用延長時間長度的 Pod，在兩步驟子版本升級期間，系統可能會使用先前的節點版本佈建新的節點集區。叢集自動配置器會根據升級後的控制層版本評估新佈建的節點，偵測版本不符的情況，並套用 cloud.google.com/not-target-gke-version:true 污點。叢集自動配置器也會禁止擴充現有或新建立的延長期限 Pod 節點集區，前提是這些集區使用舊版節點。 這項行為會導致 Pod 無法排程，並觸發無限擴充迴圈。自動佈建節點功能不會擴充現有節點集區，而是在每次擴充疊代時建立新的單一節點集區，以容納待處理的工作負載。這個迴圈會產生數百個獨立的空白節點集區，最終可能會耗盡區域性代管執行個體群組配額。 解決方法： 如要解決縮放迴圈問題，請執行下列指令，手動完成控制層升級： gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION] 或者，將下列容許度套用至受影響的工作負載，以便在舊版節點上排定工作負載： tolerations: - key: "cloud.google.com/not-target-gke-version" operator: "Equal" value: "true" effect: "NoSchedule"
作業	1.37.0-gke.2941000 以上版本	1.37.1-gke.1131000	掛接 NFS 磁碟區的節點會累積掛接項目，並停止建立容器 在執行受影響版本的節點上，掛接 NFS 磁碟區會在節點的掛接資料表中留下額外項目。此外，當使用 NFS 磁碟區的 Pod 終止時，卸載嘗試會失敗，導致 kubelet 重複嘗試卸載。每次重試都會在掛接資料表中新增項目，導致掛接資料表持續增加，即使未排定新的工作負載也一樣。 掛接表達到核心限制後，容器執行階段就無法再於該節點上建立容器。節點會停止執行新的 Pod、可能回報 NotReady 狀態，以及可能反覆重新啟動。使用 NFS 磁碟區的 Pod 可能會維持在 Terminating 狀態，因為磁碟區無法卸載。 在 Pod 事件和 kubelet 記錄中，處於這種狀態的節點會回報類似下列的錯誤： MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1 mount: /etc: mount(2) system call failed: No space left on device 這個問題會影響使用 Kubernetes 樹狀結構內 NFS 驅動程式掛接 NFS 磁碟區的節點集區。如果節點未使用樹狀結構內 NFS 驅動程式掛接 NFS 磁碟區，就不會受到影響。 解決方法： 如要復原受影響的節點，請重新啟動或重新建立節點。額外掛接項目只存在於節點的執行狀態，因此節點重新啟動時會清除這些項目。如果 Pod 在重新啟動後卡在 Terminating 狀態，可以使用下列指令移除： kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0 如要避免 Standard 叢集再次發生這個問題，請將掛接 NFS 磁碟區的節點集區降級至 1.36 版本。設定維護作業排除時段，讓 GKE 不會自動將節點集區升級回受影響的版本。 如果 Autopilot 叢集執行受影響的版本，請改用下列任一選項： 如果 NFS 磁碟區是由 Filestore 支援，請使用 Filestore CSI 驅動程式掛接，而非樹狀結構內 NFS 驅動程式。CSI 驅動程式會從自己的容器掛接磁碟區，不會使用受影響的節點元件。 如果必須繼續使用樹狀結構內 NFS 驅動程式，請讓節點自動修復功能復原受影響的節點。Autopilot 叢集會自動修復節點，如果節點回報 NotReady 狀態約 10 分鐘，系統就會清空並重新建立節點，清除其掛接資料表。
升級	1.34.9-gke.1065000 以上版本、1.35.6-gke.1049000 以上版本，以及所有 1.36 修補程式版本	1.34.10-gke.1328000 以上版本、1.35.8-gke.1026000 以上版本、1.36.4-gke.1058000 以上版本 (1.37 版尚無修正程式)	A4X Max (GB300) GPU 工作負載失敗 建立或升級 GKE A4X Max 節點集區 (a4x-maxgpu-4g-metal) 至特定修補程式版本 (請參閱「Identified version(s)」欄) 時，會導致 GPU 工作負載失敗，並附加 NVIDIA GB300 Grace Blackwell Ultra Superchip。由於 GB300 硬體搭配這個裸機機型時，高頻寬記憶體 (HBM) 啟動時間較長，nvidia-persistenced 啟動服務會逾時。這項逾時設定會導致 GPU 保持未初始化狀態，並在 Pod 嘗試要求 CUDA 資源時，產生 cudaErrorDeviceUnavailable(46) 錯誤訊息。 解決方法： 將每個受影響的叢集和節點集區升級至修正版本。GKE 會禁止建立受影響版本的 A4X Max 節點集區，也不會自動將節點集區升級至受影響的版本。GKE 不會禁止手動升級至受影響的版本。不過，為避免發生故障，建議您不要升級至受影響的版本。 解決方法： 如果無法升級，請刪除所有執行受影響版本的 A4X Max 節點集區，並使用不受影響的舊版本重新建立節點集區。請注意，A4X Max 運算資源必須透過預留項目取得，因此刪除節點集區不會導致運算資源減少。
作業	1.33 版 (1.33.5-gke.2469000 之前的版本)、1.34 版 (1.34.1-gke.2037001 之前的版本)	1.33.5-gke.2469000 以上版本、1.34.1-gke.2037001 以上版本、1.35 以上版本	主機維護後，GPU 或 TPU 節點卡在 impending-node-termination 汙點 在執行受影響版本的 GKE 叢集上，如果節點含有加速器 (GPU 或 TPU)，在 Compute Engine 主機維護或修復完成後，節點可能會停滯，並出現 cloud.google.com/impending-node-termination 或 cloud.google.com/maintenance-window-started 汙點。VM 執行個體再次啟動時，如果節點已排定其他維護事件，GKE 維護控制器可能會過早重新套用這些污點，導致新的工作負載無法排定在健康狀態良好的節點上。 解決方法： 如要解決卡住狀態，您必須手動從受影響的節點中，移除 GKE 代管的主動維護標籤和污點。如果只移除污點，GKE 維護控制器會自動重新套用。 如要清除標籤和汙點，請執行下列指令： kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest- kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination- kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started- 將 NODE_NAME 替換為受影響節點的名稱。
作業	1.33 1.34	1.34.1-gke.1829001 以上版本	回報的晶片數量有誤，導致 TPU v7 工作負載的 Pod 准入失敗。 GKE 誤將 TPU v7 (tpu7x) 加速器標示為有八個可分配的 TPU 晶片，但該加速器採用 2x2x1 拓撲，實際只有四個晶片。這項回報不一致的問題會導致 TPU v7 工作負載無法排定 Pod。 舊版無法正確處理 TPU v7 的雙晶片架構，導致 Pod 准入失敗。視要求的 TPU 資源而定，可能會發生下列錯誤： 要求四個 TPU (google.com/tpu: 4) 時，`kubelet` 會傳回 UnexpectedAdmissionError：「invalid TPU chip count request, you must request all 4 chips on this node together」(無效的 TPU 晶片計數要求，您必須一併要求這個節點上的所有 4 個晶片)。 要求八個 TPU (google.com/tpu: 8) 時，tpu-accelerator-topology-constraints 許可 Webhook 會拒絕要求，並顯示下列錯誤："Invalid resource requests for google.com/tpu. 如果是加速器 tpu7x 和拓撲 2x2x1，則應等於 [4] 的其中一個值。 解決方法： 如要解決這個問題，請將 GKE 叢集升級至 1.34.1-gke.1829001 以上版本。
作業	1.35.3-gke.1234000 以上版本	待定	Lustre 用戶端不會使用多 NIC 節點上的次要 NIC 在具有多個網路介面卡 (NIC) 的 GKE 節點上，系統預設會啟用 Managed Lustre CSI 驅動程式，使用所有可用的 NIC 將 TCP 儲存空間流量分散到各個網路介面，藉此彙整頻寬。不過，由於已知問題，從 2.14.0_p249 版開始，Lustre 用戶端可能無法使用次要 NIC。相反地，所有傳送至 Managed Lustre 執行個體的 TCP 儲存空間流量，都會透過主要 NIC 轉送，因此無法匯總頻寬，儲存空間處理量也會受限。 解決方法： 如果工作負載需要 Managed Lustre 的多 NIC 頻寬匯總功能，請將節點集區降級至 1.35.3-gke.1234000 之前的 GKE 版本，例如 1.35.2-gke.1842000。
作業	1.35 以上版本	待定	重新導向至 GKE 中繼資料伺服器的流程發生連線逾時或連線遭拒 在 GKE 1.35 以上版本中，如果工作負載使用 Workload Identity 向 Google Cloud API 進行驗證，可能會在節點啟動後，立即發生暫時性連線逾時或連線遭拒的情況。 解決方法： 如需建議和解決方法，請參閱「排解 Pod 啟動時的逾時錯誤」。
作業	1.33.8-gke.1026000 以上版本	1.35.1 以上版本	gVisor shim 無法清除，記錄 "runsc: executable file not found in $PATH" 錯誤 每當 gVisor Pod 退出或因記憶體不足而終止時，containerd 都會嘗試拆除沙箱。不過，有時清理程序會失敗，並記錄 exec: "runsc": executable file not found in $PATH 錯誤。這項錯誤可能會導致資源耗盡、網路效能降低、NodeLocalDNS 恐慌、DNS 逾時，或是在建立 Pod 時發生高延遲等問題。 解決方法： 將 GKE 節點升級至 1.35.1 以上版本。如果是 Standard 叢集，請升級含有受影響節點的節點集區。如果是 Autopilot 叢集，請手動將叢集升級至 1.35.1 以上版本，GKE 會自動盡快升級節點，使其與控制層版本相符。 解決方法： 如果無法升級叢集，請採取下列任一做法： 查看並提高 gVisor Pod 的記憶體要求和限制。 部署下列具特殊權限的 DaemonSet，將 runsc 二進位檔從 /home/containerd/usr/local/sbin 複製到 /home/kubernetes/bin： apiVersion: apps/v1 kind: DaemonSet metadata: name: runsc-path namespace: kube-system spec: selector: matchLabels: app: runsc-path updateStrategy: type: RollingUpdate template: metadata: labels: app: runsc-path spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: sandbox.gke.io/runtime operator: In values: - gvisor tolerations: - effect: NoSchedule key: sandbox.gke.io/runtime operator: Equal value: gvisor volumes: - name: host hostPath: path: / initContainers: - name: copy-runsc image: bash command: - /usr/local/bin/bash - -c - | set -euo pipefail cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin chmod a+rx /host/home/kubernetes/bin/runsc volumeMounts: - name: host mountPath: /host resources: requests: memory: 5Mi cpu: 5m securityContext: privileged: true containers: - image: gcr.io/google-containers/pause:3.2 name: pause
作業	1.35.0-gke.2232000 以上版本	1.35.3-gke.1.35.3-gke.1290000 以上版本	動態磁碟區會改用預設磁碟類型 在 GKE 1.35.0-gke.2232000 以上版本中，使用動態磁碟區的工作負載可能無法排程或附加。即使節點不支援 Hyperdisk，這個問題也可能導致系統使用備援 hd-type (例如 hyperdisk-balanced) 而非 pd-type 佈建磁碟區。 這是因為 PDCSI 節點伺服器無法使用支援的磁碟類型拓撲填入 CSINode 物件。因此，控制器缺少必要的拓撲資訊，無法將磁碟區與相容節點配對。 解決方法： 升級至 1.35.3-gke.1290000 以上版本。
升級與更新	GKE 1.34 的所有修補程式版本 (1.34.3-gke.1208000 之前的版本) GKE 1.35 1.35.0-gke.2232000 以前的所有修補程式版本	1.34.3-gke.1208000 (適用於 GKE 1.34) 1.35.0-gke.2232000 (適用於 GKE 1.35)	GKE Dataplane V2 叢集升級至 GKE 1.35 時，Pod 啟動發生問題 如果叢集要將控制層從 1.35.0-gke.2232000 以上版本升級至以下版本， GKE 1.34：早於 1.34.3-gke.1208000 GKE 1.35 1.35.0-gke.2232000 之前版本 在 anetd DaemonSet 推出期間建立的新工作負載，可能會遇到 Pod 啟動問題。 在 anetd 推出期間，如果新的工作負載排定在 anetd 過時的節點上，就會無法啟動。推出期間，您可能會看到下列錯誤訊息： Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded 這是因為 GKE 使用運算子 identity-management-mode，這需要所有代理程式和運算子都具有身分相關標籤的同步檢視。從 GKE 1.35.0-gke.2232000 topology.kubernetes.io 開始，系統會從身分相關的集合中排除標籤，避免身分重複。這項變更會導致升級後的控制層與過時的 anetd 代理程式之間，在推出期間出現暫時的設定不符情況。詳情請參閱 Cilium PR。 解決方法： GKE 1.34 (1.34.3-gke.1208000 之前版本)：先升級至 1.34.3-gke.1208000 以上版本，再升級至 1.35.0-gke.2232000 以上版本 GKE 1.35 (1.35.0-gke.2232000 之前版本)：升級後，請等待 anetd 推出作業完成。如要手動加快推出速度，請刪除過時的 anetd Pod。這可確保運算子和 anetd 節點代理程式對身分相關標籤的檢視畫面保持同步。
升級與更新	1.32 1.33 1.34 1.35	1.32.11-gke.1153001 以上版本 1.33.5-gke.2326000 以上版本 1.34.3-gke.1214000 以上版本 1.35.0-gke.2180000 以上版本	啟用 Calico 網路政策的新節點上，Pod 排程延遲 在已啟用 Calico 網路政策的 GKE 叢集上，受影響版本的迴歸可能會導致新節點或重新建立的節點上的 Pod 排程大幅延遲。這些延遲可能會導致節點長時間處於 NotReady 狀態。 這個問題是由於 Calico CNI 開機指令碼會以方括號 ([]) 括住 IPv4 位址，導致 Kubernetes API 伺服器網址格式不正確。建立新的 Pod 沙箱時，這種做法會導致網址剖析錯誤，並顯示在 `kubelet` 記錄中： Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443" 解決方法： Calico 元件版本取決於叢集的控制層版本。如要緩解這個問題，請將叢集的控制層升級至其中一個修正版本。升級控制層後，您必須重新建立節點集區中的節點，確保節點使用正確的 Kubernetes API 伺服器網址格式。如要這麼做，請將節點集區就地升級至相同或更新的版本，或手動重新建立節點集區。
效能	GKE 1.32：1.32.8-gke.1134000 以上版本 GKE 1.33 的 1.33.3-gke.1392000 以上版本 GKE 1.34 和 1.35 的所有修補程式版本	1.32.11-gke.1075000 以上版本 (適用於 GKE 1.32) GKE 1.33：1.33.5-gke.2392000 以上版本 1.34.3-gke.1318000 以上版本 (適用於 GKE 1.34) GKE 1.35：1.35.0-gke.2398000 以上版本	A 系列和 G4 GPU 機型的一般用途網路效能下降 在 GKE 1.32.8-gke.1134000 以上版本 (適用於 GKE 1.32) 和 GKE 1.33.3-gke.1392000 以上版本中，搭載 A 系列和 G4 GPU 節點的 GKE 叢集一般用途網路效能會降低。一般用途網路效能下降會影響 GPU 機型，包括 A3、A4、A4X 和 G4 系列機型。請注意，A3 Mega 的 GPUDirect-TCPXO，以及 A3 Ultra、A4 和 A4X 的 GPUDirect-RDMA 不受影響。 這是因為設定中斷親和性的節點層級指令碼 (/usr/bin/google_set_multiqueue) 設定有誤。 解決方法： 將每個受影響的節點集區升級至已修正的版本。
效能	GKE 1.32：1.32.8-gke.1134000 以上版本 1.33.3-gke.1392000 以上版本 (適用於 GKE 1.33 以上版本)	GKE 1.32 的 1.32.11-gke.1075000 以上版本 GKE 1.33 的 1.33.5-gke.2392000 以上版本	GPUDirect-TCPX 在 A3 High 的效能下降 在 GKE 1.32.8-gke.1134000 以上版本 (適用於 GKE 1.32) 和 GKE 1.33.3-gke.1392000 以上版本，使用 GPUDirect-TCPX 時，搭載 A3 High (a3-highgpu-8g) 節點的 GKE 叢集效能會降低。 這是因為設定中斷親和性的節點層級指令碼 (/usr/bin/google_set_multiqueue) 設定有誤。 解決方法： 如果是 GKE 1.32 節點集區，請將 GKE 節點集區版本升級至 1.32.11-gke.1075000 以上版本。如果是 GKE 1.33 以上版本的節點集區，請將 GKE 節點集區版本升級至 1.33.5-gke.2392000 以上版本。如果是 GKE 1.34 節點集區，請參閱「GPUDirect-TCPX 不適用於 GKE 1.34 以上版本的 A3 High」。
升級	1.35	1.35.0-gke.2232000 以上版本。	GKE Dataplane V2 叢集中的 Cilium 身分重複 如果 GKE 叢集執行 1.35 版並啟用 GKE Dataplane V2，ciliumidentities.cilium.io 自訂資源數量可能會增加。這個問題是由於 Kubernetes 1.35 中新增至 Pod 的 topology.kubernetes.io 標籤所造成，這會為排定工作負載 Pod 的每個可用區產生額外的 Cilium 身分。 在區域和可用區叢集中，排定新工作負載時，可能會暫時發生 Cilium 身分重複的情況。Pod 在建立時會根據初始標籤取得一個身分，在排定至節點並新增拓撲標籤後，又會取得另一個身分，因此會出現重複。在區域叢集中，身分數量可能會額外增加，增幅與叢集涵蓋的可用區數量成正比。 影響： 如果身分總數超過 65,535 個，系統可能無法排定新的工作負載。 解決方法： 如要限制身分識別總數，請避免在 Pod 中加入含有大量不重複值的標籤。 詳情請參閱下列 Cilium 說明文件： 以身分為基礎的安全性 安全性身分 手動升級應從 1.34.3-gke.1208000 以上版本執行。如果從 1.34.3-gke.1208000 之前的版本開始升級，升級程序可能會導致 Pod 排程暫時發生問題。
升級	1.34.5-gke.1153000 之前的 1.34 修補程式版本 1.35.2-gke.1485000 之前的 1.35 修補程式版本	1.34.5-gke.1153000 以上版本 1.35.2-gke.1485000 以上版本 1.36 以上版本 此外，您必須使用 GPUDirect-TCPX 安裝程式 3.1.9 以上版本，以及 sidecar 2.0.12 以上版本。安裝程式和 Sidecar 版本會一一對應，且必須相符。例如，GPUDirect-TCPX 安裝程式 3.1.12 版對應至 Sidecar 2.0.15 版。如要進一步瞭解安裝程式和 Sidecar 版本，請參閱 GPUDirect-TCPX 版本資訊。	特定 GKE 版本的 A3 High 不支援 GPUDirect-TCPX 具備 A3 High (a3-highgpu-8g) 節點的 GKE 叢集會使用 GPUDirect-TCPX，盡可能提高 GPU 網路頻寬。如果節點使用 TCPX 和 A3 High，升級至受影響的 GKE 版本可能會導致 TCPX 發生功能或效能問題。這是因為 TCPX 與 Container-Optimized OS 125 以上版本使用的更新版 Linux 核心 6.12 不相容。GKE 1.34 版使用里程碑 125。 其他 A3 High (a3-highgpu-1g、a3-highgpu-2g、a3-highgpu-4g) GPU 機型和其他 GPU 機器系列不支援 GPUDirect-TCPX，因此不受影響。 解決方法： 請升級至已修正的 GKE 版本修補程式，解決這個問題。如要瞭解如何設定及升級採用 GPUDirect-TCPX 的節點集區，請參閱「盡可能提高 Standard 叢集的 GPU 網路頻寬」或「盡可能提高 Autopilot 叢集的 GPU 網路頻寬」。 在固定版本上執行 NCCL 測試時，您可能會看到下列警告，但這不會影響效能或功能： Rx Ctrl Timeouts 的 NCCL WARN 記錄：如果工作負載在目標上發布 Recv 通訊作業的時間，遠早於在發起端上發布 Send 通訊作業的時間，就可能顯示這則訊息。預期不會對成效造成任何影響。 NCCL WARN 記錄 (No free space for recv task)：這則訊息會警告要處理作業的網路工作總數偏低，導致所有工作暫時遭到占用。預期不會影響成效。
作業	1.34.0-gke.2285000 之前的所有版本	1.34.0-gke.2285000 以上版本	更新執行個體容量下限 Managed Lustre 執行個體的容量下限已更新為 9000 GiB。如果叢集執行的版本早於 1.34.0-gke.2285000，就無法透過 Managed Lustre CSI 驅動程式，以這個最低容量建立執行個體。 解決方法： 將叢集版本升級至 1.34.0-gke.2285000 以上版本，即可建立容量下限為 9000 GiB 的 Managed Lustre 執行個體。
作業	所有版本	待定	節點自動修復期間，Google Cloud 控制台 UI 無法編輯 GKE 節點進行自動修復時，由於作業正在進行，因此無法透過 Google Cloud 控制台編輯節點集區。 解決方法： 您仍可使用 gcloud CLI 指令編輯節點集區設定。
作業	1.33.4-gke.1036000 之前的 1.33 版本	1.33.4-gke.1036000 以上版本	動態佈建的 Lustre 執行個體效能層級不正確 動態佈建 Lustre 執行個體時，無論 API 要求中指定的 perUnitStorageThroughput 值為何，執行個體建立作業都會失敗，並顯示 PerUnitStorageThroughput 的 InvalidArgument 錯誤。 解決方法： 將 GKE 叢集升級至 1.33.4-gke.1036000 以上版本。如果使用穩定版，可能還沒有新版本。在這種情況下，您可以從「一般」或「搶鮮版」管道手動選取包含修正程式的版本。
作業	1.32.3-gke.1099000 以上版本 1.33	1.33.3-gke.1266000 以上版本	使用 Cloud Storage FUSE CSI 驅動程式重新命名或移動檔案時發生輸入/輸出錯誤 使用受影響版本的 Cloud Storage FUSE CSI 驅動程式時，重新命名或移動 Cloud Storage bucket 中的檔案可能會失敗，並顯示 I/O 錯誤。 解決方法： 暫時在 Pod 資訊清單中新增特定 sidecar 映像檔定義。在 Pod 資訊清單的 spec.containers 區段中，加入下列容器定義和映像檔：gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2。 # Add the following block to use the fixed sidecar image - name: gke-gcsfuse-sidecar image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 詳情請參閱「為邊車容器設定私人映像檔」中的 Pod 資訊清單。 將叢集升級至修正後的 GKE 版本或更新版本後，您必須從資訊清單中移除整個 gke-gcsfuse-sidecar 區塊。移除這個區塊後，GKE 會恢復自動插入及管理正確的 Sidecar 映像檔，用於升級後的叢集版本。
記錄和監控	所有版本	待定	gke-metrics-agent DaemonSet 中的競爭狀況 當您將 cloud.google.com/gke-metrics-agent-scaling-level 標籤新增至節點集區，以手動增加 gke-metrics-agent DaemonSet 的記憶體配置時，DaemonSet 會在建立新節點時發生競爭狀況。這種競爭狀況會導致間歇性重新啟動，並可能導致指標遺失。 發生這個問題的原因是，標籤要過一段時間才會新增至節點集區中的新節點。在這段延遲期間，DaemonSet 會在該節點上建立具有原始記憶體配置的 Pod。套用標籤後，DaemonSet 會建立具有新記憶體配置的 Pod。更新後的 Pod 啟動時，現有 Pod 不會完全刪除。這兩個 Pod 都會嘗試繫結至同一個通訊埠編號。 解決方法： 將 cloud.google.com/gke-metrics-agent-scaling-level 標籤新增至節點集區後，請重新啟動 gke-metrics-agent DaemonSet： kubectl -n kube-system rollout restart daemonset gke-metrics-agent
升級	1.33	1.33.2-gke.1043000	containerd 2.0 降低開啟檔案數量上限 如果節點集區執行的 GKE 版本為 1.33 (使用 containerd 2.0)，容器開啟檔案 (ulimit -n) 的預設軟限制會降至 1024。 這是 containerd 本身的變更 (請參閱 containerd PR #8924)，其中 LimitNOFILE 已從 containerd.service 移除，做為最佳做法，因此會套用預設系統軟限制。 如果工作負載預期預設軟限制較高 (例如隱含依賴先前較高的預設值)，可能會發生失敗，例如 Too many open files 錯誤。 解決方法： 從 1.33 之前的修補程式版本升級至 1.33.2-gke.1043000 以上版本。 解決方法： 請使用下列任一方法，提高工作負載的開啟檔案數量上限： 應用程式層級調整：修改應用程式程式碼或設定，明確設定 ulimit -n 或 prlimit --nofile=524288。 Containerd NRI Ulimit Adjuster 外掛程式 ：使用 containerd/nri ulimit-adjuster 外掛程式調整 ulimit。 降級節點集區 (僅限 Standard)：如果是 Standard GKE 叢集，您可以暫時將節點集區降級至 1.32 版，避免發生這個問題，直到有永久解決方案為止。 如要進一步瞭解如何遷移至 containerd 2，請參閱「將節點遷移至 containerd 2」。
升級	1.31.5-gke.1169000、1.32.1-gke.1376000	1.31.7-gke.1164000、1.32.3-gke.1512000	代管 CRD 的 CRD status.storedVersions 無效 部分 GKE 代管的 CRD 可能含有無效的 status.storedVersions 欄位，因此升級後可能無法存取 CRD 物件。 這個問題會影響符合下列兩項條件的叢集： 在某個時間點使用受影響 GKE 版本的叢集。 叢集在 etcd 中儲存了不支援的 CRD 物件版本 (served=false)。 解決方法： 建議的解決方法是延遲叢集升級，直到問題解決為止。 或者，如果您知道叢集包含不支援的 CRD 物件版本，可以使用 kubectl patch 指令將這些版本新增至 status.storedVersions 欄位。
作業、記錄和監控	1.32.2-gke.1652000、1.31.6-gke.1221000、1.30.10-gke.1227000	1.32.2-gke.1652003 以上版本 1.31.6-gke.1221001 以上版本 1.30.10-gke.1227001 以上版本	缺少指標或工作負載自動配置器未調整資源配置 如果叢集大小增加超過五個節點，您可能會發現受影響版本的指標資料有缺漏。這項問題也可能影響自動調度資源作業。 只有升級至受影響版本的叢集會發生這個問題。新建立的叢集應可正常運作。 解決方法： 如果受到影響，可以降級一個修補程式版本，或升級至較新的修正版本。
作業			Google Cloud Hyperdisk 大小和附加限制 一般來說，如果 Pod 因節點的磁碟區連結限制而無法成功排程，就會觸發新節點的自動佈建。如果使用 Hyperdisk 產品的工作負載排定在執行 C3 VM 的節點上執行，系統不會自動佈建節點，而是將 Pod 排定在已滿的節點上。 即使沒有可用的磁碟附件，工作負載仍會排定到節點上。由於發生下列錯誤，工作負載也無法啟動： AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17] C3 機器上的所有 Hyperdisk 產品都有這個問題。 Hyperdisk 附加限制會因 VM vCPU 數量和 Hyperdisk 產品而異。詳情請參閱「Hyperdisk 效能限制」。 解決方法： Google Cloud Hyperdisk 產品會觸發其他 VM 類型的自動佈建功能。建議您選用僅支援 Google Cloud Hyperdisk 的機型。
作業	1.32.3-gke.1927000、1.32.3-gke.1785000、1.32.3-gke.1717000、1.32.3-gke.1440000、1.32.3-gke.1170000、1.32.3-gke.1250000、1.32.3-gke.1671000、1.32.3-gke.1596000、1.32.3-gke.1298000		gke-metadata-server 在 TPU/GPU 節點上因記憶體不足而終止 在 GKE TPU 節點 (例如 ct4p-hightpu-4t) 和 GPU 節點 (例如 a3-highgpu-8g) 上，如果伺服器的記憶體用量超過 100 MB，核心可能會以 OOMKilled 終止 gke-metadata-server。 解決方法： 如果您在 TPU 或 GPU 節點上觀察到 gke-metadata-server 的 OOMKilled 事件，請與 GKE Identity 值班團隊聯絡 (元件 ID：395450)，瞭解緩解措施。
作業	1.32.0-gke.1358000 至 1.32.4-gke.1106006、1.32.4-gke.1236007、1.32.4-gke.1353001、1.32.4-gke.1415001、1.32.4-gke.1533000 1.33.0-gke.0 至 1.33.0-gke.1552000	1.32.4-gke.1353003 以上版本 1.33.0-gke.1552000 以上版本	PVC 上的 NodePendingResize 狀態懸而未決，可能導致磁碟區大小調整作業停滯。 如果叢集使用 1.32 版，且節點使用 1.31 版或更舊版本，則在調整大小期間，系統將無法更新 PersistentVolumeClaim 狀態。這個錯誤狀態會導致後續的調整大小作業無法開始，進而阻止進一步調整大小。 處於這種狀態的 PVC 具有 status.allocatedResourceStatuses 欄位，其中包含 NodePendingResize 或 status.allocatedResources 欄位和 status.conditions.type: FileSystemResizePending。 如果 PVC 是在叢集使用受影響版本時建立，即使叢集升級至已知修正版本，問題可能仍會持續發生。在這種情況下，您需要修補 PVC，以透過一次性解決方法移除 status.allocatedResources 欄位。 解決方法： 如果 PVC 因懸空狀態而卡住，可以透過修補移除該狀態。您可以使用下列修補程式指令移除懸而未決的狀態： kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}' kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'
作業	1.32.4-gke.1236007、1.32.4-gke.1353001	1.32.4-gke.1353003 以上版本	PDCSI 驅動程式可能會過度記錄 特定 1.32 版本的 GKE 叢集可能會從 PDCSI 驅動程式發出過多記錄訊息。這類過多的記錄會耗用 Cloud Logging Write API 配額。 解決方法： 您可以新增排除篩選器，減少過多的記錄。如要排除記錄訊息，不擷取至 Cloud Logging，請使用下列查詢： resource.type="k8s_container" resource.labels.container_name="gce-pd-driver" (sourceLocation.file="cache.go" OR "Cannot process volume group")
作業	1.27.16-gke.2440000 以上版本 1.28.15-gke.1673000 以上版本 1.29.13-gke.1038000 以上版本 1.30.9 以上版本 1.31.7 以上版本 1.32.1-gke.1357001 以上版本	1.27.16-gke.2691000 以上版本 1.28.15-gke.2152000 以上版本 1.29.15-gke.1218000 以上版本 1.30.11-gke.1190000 以上版本 1.31.7-gke.1363000 以上版本 1.32.4-gke.1106000 以上版本 1.33.0-gke.1552000 以上版本	如果 Pod 嘗試在先前具有唯讀 (RO) 掛接的 COS 節點上掛接 NFS 永久磁碟區，則只會以 RO 模式掛接 如果是 GKE 1.27 以上版本，使用 Kubernetes 樹內 CSI 驅動程式的 NFS 磁碟區，只能在同一個節點上先前 RO 掛接後，以 RO 模式掛接永久磁碟區。 解決方法： 將節點集區降級至受影響版本之前的版本
作業	1.32.1-gke.1357001 至 1.32.4-gke.1106000 (不含) 的 1.32 版本 1.33.0-gke.1552000 之前的 1.33 版本 1.32 版：1.32.4-gke.1106000 以上版本 1.33 版本：1.33.0-gke.1552000 以上版本	嘗試在 Ubuntu 節點上掛接 NFS 永久磁碟區的 Pod 將無法執行。 在 GKE 1.32 以上版本中，使用 Kubernetes 樹狀結構內 CSI 驅動程式的 NFS 磁碟區，無法在 Ubuntu 節點上掛接永久磁碟區。發生這種情況時，您可能會看到下列錯誤訊息： "MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1" Output: Mount failed: mount failed: exit status 127 "Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes" 除了看到這些錯誤訊息外，使用這些磁碟區的 Pod 也無法啟動。 解決方法： 將節點集區降級至 1.31 版。
作業	>= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1369000	1.28.15-gke.1668000 以上版本 1.29.13-gke.1028000 以上版本 1.30.8-gke.1287000 以上版本 1.31.6-gke.1020000 以上版本 1.32.1-gke.1369000 以上版本	使用 io_uring 相關系統呼叫的 Pod 可能會卡在「Terminating」(終止中) 狀態 由於 Linux 核心中的錯誤，使用 io_uring 相關 syscall 的 Pod 可能會進入 D (磁碟休眠) 狀態，也稱為 TASK_UNINTERRUPTIBLE。D 狀態的程序無法由信號喚醒，包括 SIGKILL。 如果 Pod 受到這個已知問題影響，容器可能無法正常終止。在 containerd 記錄中，您可能會看到類似下列內容的重複訊息：Kill container [container-id]，表示系統正在重複嘗試停止容器。 同時，kubelet 記錄會顯示錯誤訊息，例如： "Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded" 或 "Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid" 這些徵狀表示容器內的程序處於無法中斷的休眠狀態 (D 狀態)，導致 Pod 無法正常終止。 直接使用 io_uring 的工作負載，或透過 NodeJS 等語言執行階段間接使用 io_uring 的工作負載，可能會受到這個已知問題影響。受影響的工作負載在 /proc/<pid>/state 檔案中，會有處於 D (磁碟休眠) 狀態的程序，並在 /proc/<pid>/stack 的內容中顯示 io_uring 字串。NodeJS 工作負載或許可以透過 UV_USE_IO_URING=0 停用 io_uring。 解決方法： 將叢集節點升級至修正版本或更新版本。
作業	1.28、1.29、1.30、1.31	1.30.8-gke.1261000 以上版本 1.31.4-gke.1183000 以上版本 1.32.0-gke.1448000 以上版本	使用影像串流的工作負載因驗證錯誤而失敗 映像檔串流功能中的錯誤，可能會導致容器讀取檔案時，在符合一組特定條件的情況下，工作負載失敗。與驗證失敗相關的錯誤訊息可能會顯示在 gcfsd 記錄中。 如要確認是否受到影響，請使用以下搜尋查詢來搜尋記錄： resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential." 如果出現這些錯誤，表示節點受到影響。 如果受到這個問題影響，您可以 將節點集區升級至已修正的 GKE 版本。
作業	1.30.0 至 1.30.5-gke.1443001 1.31.0 至 1.31.1-gke.1678000	1.30.5-gke.1628000 以上版本 1.31.1-gke.1846000 以上版本	GKE 1.30 和 1.31 版的 Pod 驅逐率提高 部分 GKE 1.30 和 GKE 1.31 版本分別使用 COS 113 和 COS 117，其核心是以 CONFIG_LRU_GEN_ENABLED=y 選項建構。這個選項會啟用核心功能「Multi-Gen LRU」，導致 Kubelet 誤算記憶體用量，進而驅逐 Pod。 cos-113-18244-151-96 和 cos-117-18613-0-76 已停用設定選項 CONFIG_LRU_GEN_ENABLED。 您不一定會看到異常的 Pod 驅逐率，因為這個問題取決於工作負載的記憶體用量模式。 如果工作負載未在資源欄位中設定記憶體限制，kubelet 剔除 Pod 的風險就會提高。 這是因為工作負載要求的記憶體可能超過 kubelet 回報的可用記憶體。 如果您在升級至上述 GKE 版本後，發現應用程式的記憶體用量增加，但未進行任何其他變更，則可能受到核心選項影響。 如要檢查 Pod 驅逐率是否異常，請使用 Metrics Explorer 分析下列指標： kubernetes.io/container_memory_used_bytes 和 kubernetes.io/container_memory_request_bytes 您可以使用下列 PromQL 查詢。將 cluster_name、namespace_name、metadata_system_top_level_controller_type 和 metadata_system_top_level_controller_name 的值替換為要分析的工作負載名稱和類型： max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) 如果記憶體用量出現異常高峰，超過要求的記憶體，工作負載可能會更常遭到淘汰。 解決方法 如果您無法升級至已修正的版本，且在可部署具特殊權限 Pod 的 GKE 環境中執行，則可使用 DaemonSet 停用多代 LRU 選項。 更新要執行 DaemonSet 的 GKE 節點集區，並加上註解，停用多代 LRU 選項。例如 disable-mglru: "true"。 使用您在上一個步驟中使用的相同註解，更新 DaemonSet 資訊清單中的 nodeSelector 參數。舉例來說，請參閱 GoogleCloudPlatform/k8s-node-tools 存放區中的 disable-mglru.yaml 檔案。 將 DaemonSet 部署至叢集。 DaemonSet 在所有選取的節點集區中執行後，變更會立即生效，kubelet 記憶體用量計算也會恢復正常。
作業	1.28、1.29、1.30、1.31	1.28.14-gke.1175000 以上版本 1.29.9-gke.1341000 以上版本 1.30.5-gke.1355000 以上版本 1.31.1-gke.1621000 以上版本	Pod 卡在「終止中」狀態 容器執行階段 (containerd) 的錯誤可能會導致 Pod 和容器停滯在 Terminating 狀態，並出現類似下列的錯誤： OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown 如果這個問題對您造成影響，可以 將節點升級至 GKE 版本，其中包含已修正的 containerd 版本。
作業	1.34 以下版本 1.35.6-gke.1005000 之前的 1.35 版本 1.36 版本 (1.36.0-gke.2459000 之前的版本)	1.35.6-gke.1005000 以上版本 1.36.0-gke.2459000 以上版本	符號連結導致圖片串流失敗 映像檔串流功能中的錯誤可能會導致容器無法啟動。 在特定 GKE 版本中，如果節點已啟用映像檔串流功能，在該節點上執行的容器可能無法建立，並顯示下列錯誤： "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links" 解決方法： 如要解決這個問題，請將節點集區升級至修正版本 (1.35.6-gke.1005000 以上版本，或 1.36.0-gke.2459000 以上版本)。 如果無法升級，請 檢查是否有空白或重複的圖層。如果無法移除空白層或重複層，請停用映像檔串流。
作業	1.27,1.28,1.29	1.28.9-gke.1103000 以上版本 1.29.4-gke.1202000 以上版本 1.30：所有版本	缺少檔案，因此無法串流映像檔 映像檔串流功能中的錯誤可能會導致容器因缺少一或多個檔案而失敗。 在下列版本中，如果節點啟用了映像檔串流功能，在該節點上執行的容器可能無法啟動或執行，並會顯示錯誤訊息，指出特定檔案不存在。以下是這類錯誤的範例： No such file or directory Executable file not found in $PATH 如果受到這個問題影響，可以停用映像檔串流。
網路、升級和更新	1.28		閘道 TLS 設定錯誤 我們發現，在執行 GKE 1.28.4-gke.1083000 版的叢集中，設定閘道 TLS 時會發生問題。這會影響使用 SSLCertificate 或 CertificateMap 的 TLS 設定。如果升級的叢集含有現有閘道，對閘道所做的更新將會失敗。對於新的閘道，系統不會佈建負載平衡器。日後推出的 GKE 1.28 修補程式版本將會修正這個問題。
升級與更新	1.27	1.27.8 以上版本	GPU 裝置外掛程式問題 如果叢集執行 GPU，且從 1.26 升級至 1.27 修補程式版本 (早於 1.27.8)，節點的 GPU 裝置外掛程式 (nvidia-gpu-device-plugin) 可能會發生問題。請視叢集狀態執行下列步驟： 如果叢集執行 1.26 版且有 GPU，請等到叢集的發布管道提供 1.27.8 版後，再手動升級叢集。 如果叢集執行的是較早的 1.27 修補程式版本，且節點受到影響，請重新啟動節點，或手動刪除節點上的 nvidia-gpu-device-plugin Pod (外掛程式管理員會建立新的工作外掛程式)。 如果叢集使用自動升級功能，這項異動不會影響您，因為自動升級只會將叢集移至含有修正程式的修補程式版本。
作業	1.27、1.28	1.27.5-gke.1300 以上版本 1.28.1-gke.1400 以上版本	所有工作負載都會停止自動調度資源 如果叢集包含設定錯誤的 autoscaling/v2 HPA 物件，HorizontalPodAutoscaler (HPA) 和 VerticalPodAutoscaler (VPA) 可能會停止自動調度叢集中所有工作負載的資源。這個問題會影響執行舊版 GKE 1.27 和 1.28 修補程式版本的叢集 (例如 1.27.3-gke.100)。 解決方法： 請確認 spec.metrics.resource.target 中的欄位是否相符，修正設定錯誤的 autoscaling/v2 HPA 物件，例如： 如果 spec.metrics.resource.target.type 為 Utilization，則目標應為 averageUtilization 如果 spec.metrics.resource.target.type 為 AverageValue，則目標應為 averageValue 如要進一步瞭解如何設定 autoscaling/v2 HPA 物件，請參閱 HorizontalPodAutoscaler Kubernetes 說明文件。
作業	1.28、1.29	1.28.7-gke.1026000 1.29.2-gke.1060000	無法部署 Container Threat Detection 如果 Autopilot 叢集執行下列 GKE 版本，Container Threat Detection 可能無法部署： 1.28.6-gke.1095000 至 1.28.7-gke.1025000 1.29.1-gke.1016000 至 1.29.1-gke.1781000
網路、升級	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 或服務的 Pod 對 Pod UDP 流量。 解決方法 將叢集升級至下列其中一個修正版本： 1.32.3-gke.1927000 以上版本 1.31.7-gke.1390000 以上版本
作業	1.29,1.30,1.31	1.29.10-gke.1071000 以上版本 1.30.5-gke.1723000 以上版本 1.31.2-gke.1115000 以上版本	Ray Operator 與 Cloud KMS 資料庫加密不相容 部分 Ray Operator 版本與 Cloud KMS 資料庫加密不相容。 解決方法： 將叢集控制層升級至修正版本或更新版本。
升級與更新	1.30、1.31	1.30.8-gke.1051000 以上版本 1.31.1-gke.2008000 以上版本	GPU 維護處理常式 Pod 停滯在 CrashLoopBackOff 狀態 發生這個問題時，gpu-maintenance-handler Pod 會在各自的節點上卡在「CrashLoopBackOff」狀態。這個狀態會導致 GKE 節點無法套用「即將進行維護」標籤，進而影響工作負載的節點排除和 Pod 淘汰程序。 "Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')" 如果受到這個問題影響，請將控制層升級至包含修正程式的 GKE 版本，即可解決問題。
作業	1.33.1-gke.1522000 以上版本	1.33.4-gke.1142000 以上版本	在已啟用映像檔串流的節點上，Pod 無法啟動 在啟用映像檔串流的節點上，工作負載可能無法啟動，並顯示下列錯誤簽章：Failed to create pod sandbox ... context deadline exceeded 受影響節點的序列埠記錄也包含下列錯誤簽章： task gcfsd ... blocked for more than X seconds 如果出現這兩個錯誤簽章，表示其中一個影像串流元件發生死結。這個死結會導致 Pod 無法順利啟動。 緩解措施： 重新啟動節點，即可快速緩解問題。請注意，重新啟動的節點可能仍會再次遇到死結。如要採取更強大的緩解措施，請執行下列指令，停用節點集區的映像檔串流功能： gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming 注意：停用映像檔串流功能後，系統會重新建立節點集區中的所有節點。
作業	1.32.4-gke.1198000 以上版本 1.33.5-gke.1862000 之前的 1.33 版本 1.34 版本 (1.34.1-gke.2541000 之前的版本)	1.33.5-gke.1862000 以上版本 1.34.1-gke.2541000 以上版本	自訂 ComputeClass，ImageType 不使用現有的 GKE 節點集區。 使用定義 ImageType 欄位的自訂 ComputeClass 時，叢集自動配置器會重複建立及擴充新節點集區，而不是擴充現有節點集區。ComputeClass 狀態不正常。 解決方法： 將叢集升級至下列其中一個修正版本： 1.33.5-gke.1862000 以上版本 1.34.1-gke.2541000 以上版本 或者，您也可以不在自訂 ComputeClass 中定義特定欄位，藉此緩解這個問題。 如果您未使用 Autopilot 自訂 ComputeClass，請勿定義 ImageType 欄位。在這種情況下，系統會使用預設的叢集層級設定，也就是 cos_containerd。 如果您使用 Autopilot 自訂 ComputeClass，請勿定義 nodePoolConfig 欄位，該欄位為 ImageType 層級。

後續步驟

• 如果無法在文件中找到問題的解決方案，請參閱「取得支援」一文，取得進一步協助，包括下列主題的建議：

  • 與 Cloud Customer Care 聯絡，建立客服案件。
  • 在 StackOverflow 提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。您也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
  • 使用公開 Issue Tracker 提出問題或功能要求。