本頁列出 GKE 的已知問題。本頁面適用於管理底層技術基礎架構生命週期，以及在服務等級目標 (SLO) 未達成或應用程式失敗時，回應快訊和頁面的管理員和架構師。
本頁列出所有支援版本的已知問題，以及延長支援中最早版本的前兩個次要版本。 版本延長支援期限結束後，所有 N-2 問題都會移除。舉例來說，當 1.30 版的延長支援期結束時，系統會移除 1.28 版和更早版本特有的已知問題。
如果您是 Google 開發人員計畫成員，請儲存這個頁面，以便在發布與這個頁面相關的版本說明時收到通知。詳情請參閱「儲存的頁面」。
如要依產品版本或類別篩選已知問題，請從下列下拉式選單選取篩選條件。
選取 GKE 版本：
選取問題類別：
或者，搜尋您的問題：
| 類別 | 已識別版本 | 已修正的版本 | 問題和解決方法 |
|---|---|---|---|
| 作業 | 1.33.4-gke.1036000 之前的 1.33 版本 | 1.33.4-gke.1036000 以上版本 |
動態佈建的 Lustre 執行個體效能層級不正確動態佈建 Lustre 執行個體時，無論 API 要求中指定的 perUnitStorageThroughput 值為何，執行個體建立作業都會因 解決方法： 將 GKE 叢集升級至 1.33.4-gke.1036000 以上版本。如果使用穩定版，可能還無法取得較新版本。在這種情況下，您可以從「一般」或「快速」管道手動選取包含修正程式的版本。 |
| 作業 |
|
1.33.3-gke.1266000 以上版本 |
使用 Cloud Storage FUSE CSI 驅動程式重新命名或移動檔案時發生輸入/輸出錯誤使用受影響版本的 Cloud Storage FUSE CSI 驅動程式時，重新命名或移動 Cloud Storage bucket 中的檔案可能會失敗，並顯示 I/O 錯誤。 解決方法： 在 Pod 資訊清單中暫時新增特定 Sidecar 映像檔定義。在 Pod 資訊清單的 # 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 詳情請參閱「為 Sidecar 容器設定私人映像檔」中的 Pod 資訊清單。 將叢集升級至修正的 GKE 版本或更新版本後，您必須從資訊清單中移除整個 |
| 記錄和監控 | 所有版本 | 待定 |
|
| 升級 | 1.33 | 1.33.2-gke.1043000 |
使用 containerd 2.0 時，開啟檔案的限制較低對於執行 GKE 1.33 版的節點集區 (使用 containerd 2.0)，容器的開啟檔案數 ( 這是 containerd 本身的變更 (請參閱 containerd PR #8924)，其中 如果工作負載預期較高的預設軟性限制 (例如隱含依賴先前的較高預設值)，可能會發生失敗情形，例如 解決方法： 從 1.33 之前的修補程式版本升級至 1.33.2-gke.1043000 以上版本。 解決方法： 請使用下列任一方法，提高工作負載的開啟檔案數上限：
|
| 升級 | 1.31.5-gke.1169000、1.32.1-gke.1376000 | 1.31.7-gke.1164000、1.32.3-gke.1512000 |
Invalid CRD status.storedVersions for managed CRDs部分 GKE 管理的 CRD 可能有無效的 這個問題會影響符合下列條件的叢集：
解決方法： 建議您延後叢集升級，直到問題解決為止。 或者，如果您知道叢集含有不支援的 CRD 物件版本，可以使用 |
| 運作、記錄和監控 | 1.32.2-gke.1652000、1.31.6-gke.1221000、1.30.10-gke.1227000 |
|
缺少指標或工作負載自動調度器未調度資源叢集大小增加超過五個節點後，您可能會發現受影響版本的指標資料有缺漏。這個問題也可能影響自動調度資源作業。 只有升級至受影響版本的叢集會受到影響。新建立的叢集應可正常運作。 解決方法： 如果受到影響，可以降級一個修補程式版本，或升級至較新的修正版本。 |
| 作業 |
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 效能限制」。 解決方法： Hyperdisk 產品會在其他 VM 形態上觸發自動佈建。建議使用僅支援 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 |
TPU/GPU 節點上的 gke-metadata-server 遭到 OOMKilled在 GKE TPU 節點 (例如 解決方法： 如果 TPU 或 GPU 節點出現 |
|
| 作業 |
|
|
由於 PVC 上有懸而未決的 NodePendingResize 狀態，磁碟區大小調整作業可能會停滯。如果叢集版本為 1.32，且節點版本為 1.31 或更舊，則在調整大小期間，系統將無法更新 PersistentVolumeClaim 狀態。這個錯誤狀態會導致後續的調整大小作業無法開始，進而無法進一步調整大小。 處於這個狀態的 PVC 具有 如果叢集使用受影響的版本時建立了 PVC，即使叢集升級至已知修正版本，您可能仍會遇到這個問題。在這種情況下，您需要修補 PVC，以透過一次性解決方法移除 解決方法： 如果 PVC 處於懸而未決的狀態，可以修補 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}}' |
| 作業 |
|
|
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")
|
| 作業 |
|
|
如果 Pod 嘗試在先前已掛接唯讀 (RO) 磁碟區的 COS 節點上掛接 NFS 永久磁碟區，則只會以 RO 模式掛接如果是 GKE 1.27 以上版本，使用 Kubernetes 樹內 CSI 驅動程式的 NFS 磁碟區，只能在同一節點上先前 RO 掛接後，以 RO 模式掛接永久磁碟區。 解決方法： 將節點集區降級至受影響版本之前的版本 |
| 作業 |
|
|
嘗試在 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" 解決方法： 將節點集區降級至 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.1302000 |
|
使用 io_uring 相關系統呼叫的 Pod 可能會停留在「Terminating」狀態
由於 Linux 核心的錯誤，使用 io_uring 相關系統呼叫的 Pod 可能會進入 D (磁碟休眠) 狀態，也稱為 TASK_UNINTERRUPTIBLE。D 狀態的程序無法由信號喚醒，包括
如果 Pod 受到這個已知問題影響，容器可能無法正常終止。在 containerd 記錄中，您可能會看到類似下列內容的重複訊息：
或
這些症狀表示容器中的程序卡在無法中斷的休眠狀態 (D 狀態)，導致 Pod 無法正常終止。
直接使用 io_uring 的工作負載，或透過 NodeJS 等語言執行階段間接使用 io_uring 的工作負載，可能會受到這個已知問題影響。受影響的工作負載在 解決方法： 將叢集節點升級至修正版本或更新版本。 |
| 作業 | 1.28、1.29、1.30、1.31 |
|
使用影像串流的工作負載會因驗證錯誤而失敗如果容器在讀取檔案時符合一組特定條件，影像串流功能中的錯誤可能會導致工作負載失敗。您可能會在 gcfsd 記錄中看到與驗證失敗相關的錯誤訊息。
如要確認是否受到影響，請使用下列搜尋查詢搜尋記錄：
如果出現這些錯誤，表示節點受到影響。 如果受到這個問題影響，您可以 升級節點集區至已修正的 GKE 版本。 |
| 作業 |
|
|
GKE 1.30 和 1.31 版的 Pod 驅逐率提高
部分使用 COS 113 和 COS 117 的 GKE 1.30 和 GKE 1.31 版本，其核心是使用
在 cos-113-18244-151-96 和 cos-117-18613-0-76 中，設定選項 由於這個問題取決於工作負載的記憶體用量模式，因此您不一定會看到異常的 Pod 驅逐率。 如果工作負載未在資源欄位中設定記憶體限制，kubelet 撤銷 Pod 的風險就會提高。 這是因為工作負載要求的記憶體可能超出 kubelet 回報的可用記憶體。 如果您在升級至上述 GKE 版本後，發現應用程式的記憶體用量增加，但未進行任何其他變更，則可能受到核心選項影響。
如要檢查 Pod 驅逐率是否異常，請使用 Metrics Explorer 分析下列指標：
您可以使用下列 PromQL 查詢。將
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 停用 Multi-Gen LRU 選項。
DaemonSet 在所有選取的節點集區中執行後，變更會立即生效，kubelet 記憶體用量計算也會恢復正常。 |
| 作業 | 1.28、1.29、1.30、1.31 |
|
Pod 卡在「終止中」狀態容器執行階段 (containerd) 中的錯誤可能會導致 Pod 和容器停滯在「Terminating」狀態，並出現類似下列的錯誤： OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
如果受到這個問題影響，您可以 升級節點至 GKE 版本，其中包含已修正的 containerd 版本。 |
| 作業 | 1.28、1.29 |
|
符號連結導致圖片串流失敗映像檔串流功能中的錯誤可能會導致容器無法啟動。 在特定 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.27、1.28、1.29 |
|
缺少檔案，導致圖片串流失敗圖片串流功能中的錯誤可能會導致容器因缺少一或多個檔案而失敗。 如果節點上執行的容器啟用映像檔串流功能，且版本如下，則可能無法啟動或執行，並出現某些檔案不存在的錯誤訊息。這類錯誤的例子如下：
如果受到這個問題影響，可以停用圖片串流。 |
| 網路、升級與更新 | 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 裝置外掛程式 (
|
| 作業 | 1.27、1.28 |
|
停止所有工作負載的自動調度資源功能
如果叢集包含設定錯誤的 解決方法：
請確認
如要進一步瞭解如何設定 |
| 作業 | 1.28、1.29 |
|
Container Threat Detection 無法部署如果 Autopilot 叢集執行下列 GKE 版本，Container Threat Detection 可能無法部署：
|
| 網路、升級 | 1.27、1.28、1.29、1.30 |
|
升級控制層後，
|
| 網路 | 1.31、1.32 |
|
在同一節點上執行的 Pod 之間，UDP 流量中斷如果叢集啟用節點內瀏覽權限，在相同節點上執行的 Pod 之間，UDP 流量可能會中斷。 當 GKE 叢集節點升級至或建立於下列任一 GKE 版本時，就會觸發這個問題：
受影響的路徑是同一節點上透過 Hostport 或 Service 的 Pod 對 Pod UDP 流量。 解決方法 將叢集升級至下列其中一個修正版本：
|
| 作業 | 1.29、1.30、1.31 |
|
Ray 運算子與 Cloud KMS 資料庫加密不相容部分 Ray 運算子版本與 Cloud KMS 資料庫加密不相容。 解決方法： 將叢集控制層升級至固定版本或更新版本。 |
| 升級與更新 | 1.30、1.31 |
|
GPU 維護處理常式 Pod 停滯在 CrashLoopBackOff 狀態發生這個問題時，gpu-maintenance-handler Pod 會在各自的節點上處於 `CrashLoopBackOff` 狀態。這個狀態可防止系統將 `upcoming maintenance` 標籤套用至 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
在啟用映像檔串流的節點上，工作負載可能無法啟動，並出現以下錯誤簽章：
受影響節點的序列埠記錄也會包含下列錯誤簽章：
如果出現這兩個錯誤簽章，表示其中一個圖片串流元件發生死結。這個死結會導致 Pod 無法順利啟動。 降低威脅的方法： 重新啟動節點，即可快速解決問題。請注意，重新啟動的節點可能仍會再次遇到死結。如要採取更完善的防範措施，請執行下列指令，在節點集區中停用映像檔串流功能： gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
後續步驟
如果無法在說明文件中找到問題的解決方法，請參閱「取得支援」一文，尋求進一步的協助， 包括下列主題的建議：
- 與 Cloud 客戶服務聯絡，建立支援案件。
- 在 StackOverflow 上提問，並使用
google-kubernetes-engine標記搜尋類似問題，向社群尋求支援。你也可以加入#kubernetes-engineSlack 頻道，取得更多社群支援。 - 使用公開版 Issue Tracker 開啟錯誤或功能要求。