GKE 已知問題

• 1.36.3-gke.1767000 以上版本

叢集升級後，Agent Sandbox 工作負載失敗

自 GKE 1.36.3-gke.1767000 版起，Agent Sandbox (agentsandbox) 外掛程式已將自訂資源定義和 API 從 v1alpha1 升級至 v1beta1。如果叢集執行 Agent Sandbox，且版本早於 1.36.3-gke.1767000，在未遷移自訂資源的情況下升級叢集，會導致現有的 v1alpha1 工作負載無法正常運作。

解決方法：

將叢集控制層升級至 1.36.3-gke.1767000 以上版本之前，請按照 Agent Sandbox v1alpha1 至 v1beta1 遷移指南，將 Agent Sandbox 資訊清單和工作負載從 v1alpha1 遷移至 v1beta1。

• 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) 要求服務帳戶存取權杖或身分權杖，藉此向 Cloud de Confiance 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"

掛接 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 分鐘，系統就會清空並重新建立節點，清除其掛接資料表。

A4X Max (GB300) GPU 工作負載故障

建立或升級 GKE A4X Max 節點集區 (a4x-maxgpu-4g-metal) 至特定修補程式版本 (請參閱「Identified version(s)」欄) 時，會導致附加的 NVIDIA GB300 Grace Blackwell Ultra Superchip 發生 GPU 工作負載失敗。由於 GB300 硬體搭配這個裸機機型時，高頻寬記憶體 (HBM) 啟動時間較長，nvidia-persistenced 啟動服務會逾時。這項逾時設定會導致 GPU 保持未初始化狀態，並在 Pod 嘗試宣告 CUDA 資源時，產生 cudaErrorDeviceUnavailable(46) 錯誤訊息。

解決方法：

將每個受影響的叢集和節點集區升級至修正版本。GKE 會禁止建立受影響版本的 A4X Max 節點集區，也不會自動將節點集區升級至受影響的版本。GKE 不會阻止手動升級至受影響的版本。不過，為避免發生錯誤，建議您不要升級至受影響的版本。

解決方法：

如果無法升級，請刪除所有執行受影響版本的 A4X Max 節點集區，並使用不受影響的舊版本重新建立節點集區。請注意，A4X Max 容量必須透過預留項目取得，因此刪除節點集區不會導致容量減少。

主機維護後，GPU 或 TPU 節點卡在 impending-node-termination 汙點

在具有加速器節點 (GPU 或 TPU) 且執行受影響版本的 GKE 叢集上，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

回報的晶片數量有誤，導致 TPU v7 工作負載的 Pod 准入失敗。

GKE 錯誤地將 2x2x1 拓撲的 TPU v7 (tpu7x) 加速器，宣傳為有八個可分配的 TPU 晶片，但實際上只有四個晶片。這項回報不一致的問題會導致 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 以上版本。

Lustre 用戶端不會在多 NIC 節點上使用次要 NIC

在具有多個網路介面卡 (NIC) 的 GKE 節點上，Managed Lustre CSI 驅動程式預設會啟用，使用所有可用的 NIC，將 TCP 儲存空間流量分散到各個網路介面，藉此匯總頻寬。不過，由於已知問題，2.14.0_p249 以上版本的 Lustre 用戶端可能不會使用次要 NIC。相反地，所有傳送至 Managed Lustre 執行個體的 TCP 儲存空間流量，都會透過主要 NIC 轉送，因此無法匯總頻寬，儲存空間處理量也會受限。

解決方法：

如果工作負載需要多 NIC 頻寬匯總功能，才能使用 Managed Lustre，請將節點集區降級至 1.35.3-gke.1234000 之前的 GKE 版本，例如 1.35.2-gke.1842000。

重新導向至 GKE 中繼資料伺服器的流量連線逾時或連線遭拒

在 GKE 1.35 以上版本中，如果工作負載使用 Workload Identity 向 Google Cloud API 進行驗證，可能會在節點啟動後，立即發生暫時性連線逾時或連線遭拒的情況。

解決方法：

如需建議和解決方法，請參閱「排解 Pod 啟動時的逾時錯誤」。

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
    

動態磁碟區會改用預設磁碟類型

在 GKE 1.35.0-gke.2232000 以上版本中，使用動態磁碟區的工作負載可能無法排程或附加。這項問題也可能導致系統使用備用 hd-type (例如 hyperdisk-balanced) 而非 pd-type 來佈建磁碟區，即使節點不支援 Hyperdisk 也是如此。

這是因為 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 之前的版本升級至 1.35.0-gke.2232000 以上版本

• GKE 1.34：早於 1.34.3-gke.1208000
• GKE 1.35：1.35.0-gke.2232000 之前版本

在 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 以上版本
• 如果是 1.35.0-gke.2232000 之前的 GKE 1.35 版本：升級後，請等待 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 以上版本
• 1.33.3-gke.1392000 以上版本 (適用於 GKE 1.33)
• GKE 1.34 和 1.35 的所有修補程式版本

• GKE 1.32：1.32.11-gke.1075000 以上版本
• 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.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 通訊作業的時間，就可能顯示這則訊息。預期不會對成效造成任何影響。
• No free space for recv task 的 NCCL WARN 記錄：這則訊息警告處理作業的網路工作總數偏低，導致所有工作暫時遭到占用。預期不會影響成效。

更新執行個體容量下限

Managed Lustre 執行個體的容量下限已更新為 9000 GiB。如果叢集執行的版本早於 1.34.0-gke.2285000，就無法透過 Managed Lustre CSI 驅動程式，建立容量下限為 10 TiB 的執行個體。

解決方法：

將叢集升級至 1.34.0-gke.2285000 以上版本，即可建立容量至少 9000 GiB 的 Managed Lustre 執行個體。

節點自動修復期間，Cloud de Confiance 控制台 UI 無法編輯

GKE 節點自動修復期間，由於作業正在進行，因此無法透過 Cloud de Confiance 控制台編輯節點集區。

解決方法：

您仍可使用 gcloud CLI 指令編輯節點集區設定。

動態佈建 Lustre 執行個體的效能級別不正確

動態佈建 Lustre 執行個體時，無論 API 要求中指定的 perUnitStorageThroughput 值為何，執行個體建立作業都會失敗，並顯示 PerUnitStorageThroughput 的 InvalidArgument 錯誤。

解決方法：

將 GKE 叢集升級至 1.33.4-gke.1036000 以上版本。如果使用穩定版，可能還沒有新版本。在這種情況下，您可以從一般版或搶鮮版，手動選取包含修正程式的版本。

• 1.32.3-gke.1099000 以上版本
• 1.33

使用 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

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 版，避免發生這個問題，直到有永久解決方案為止。

代管 CRD 的 CRD status.storedVersions 無效

部分 GKE 代管的 CRD 可能含有無效的 status.storedVersions 欄位，升級後可能無法存取 CRD 物件。

這個問題會影響同時符合下列條件的叢集：

• 在某個時間點使用受影響 GKE 版本的叢集。
• 叢集儲存在 etcd 中的 CRD 物件版本不受支援 (served=false)。

解決方法：

建議您延後叢集升級，直到問題解決為止。

或者，如果您知道叢集包含不支援的 CRD 物件版本，可以使用 kubectl patch 指令將這些版本新增至 status.storedVersions 欄位。

• 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 的機型。

gke-metadata-server 在 TPU/GPU 節點上因記憶體不足而終止

在 GKE TPU 節點 (例如 ct4p-hightpu-4t) 和 GPU 節點 (例如 a3-highgpu-8g) 上，如果伺服器的記憶體用量超過 100 MB，核心可能會終止 gke-metadata-server 並顯示 OOMKilled。

解決方法：

如果您在 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 以上版本

如果 Pod 嘗試在 Ubuntu 節點上掛接 NFS 永久磁碟區，將無法執行。

在 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.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 相關系統呼叫的 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.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 選項建構。這個選項會啟用核心功能多代 LRU，導致 kubelet 誤算記憶體用量，並可能導致 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 的值替換為要分析的工作負載名稱和類型：

如果記憶體用量出現異常高峰，超過要求的記憶體，工作負載可能會更常遭到淘汰。

解決方法

如果您無法升級至已修正的版本，且在可部署具特殊權限 Pod 的 GKE 環境中執行，則可使用 DaemonSet 停用多代 LRU 選項。

1. 更新要執行 DaemonSet 的 GKE 節點集區，並加上註解，停用多代 LRU 選項。例如 disable-mglru: "true"。
2. 使用您在上一個步驟中使用的相同註解，更新 DaemonSet 資訊清單中的 nodeSelector 參數。舉例來說，請參閱 GoogleCloudPlatform/k8s-node-tools 存放區中的 disable-mglru.yaml 檔案。
3. 將 DaemonSet 部署至叢集。

DaemonSet 在所有選取的節點集區中執行後，變更會立即生效，kubelet 記憶體用量計算也會恢復正常。

• 1.28.14-gke.1175000 以上版本
• 1.29.9-gke.1341000 以上版本
• 1.30.5-gke.1355000 以上版本
• 1.31.1-gke.1621000 以上版本

Pod 卡在「終止中」狀態

容器執行階段 (containerd) 中的錯誤可能會導致 Pod 和容器卡在「Terminating」狀態，並出現類似下列的錯誤：

如果受到這個問題影響，可以 將節點升級至 GKE 版本，其中包含已修正的 containerd 版本。

• 1.34 以下版本
• 1.35.6-gke.1005000 之前的 1.35 版本
• 1.36.0-gke.2459000 之前的 1.36 版本

• 1.35.6-gke.1005000 以上版本
• 1.36.0-gke.2459000 以上版本

因符號連結而無法串流映像檔

映像檔串流功能中的錯誤可能會導致容器無法啟動。

在特定 GKE 版本中，如果節點已啟用映像檔串流功能，在該節點上執行的容器可能無法建立，並顯示下列錯誤：

解決方法：

如要解決這個問題，請將節點集區升級至修正版本 (1.35.6-gke.1005000 以上版本，或 1.36.0-gke.2459000 以上版本)。

如果無法升級，可以 檢查是否有空白層或重複層。如果無法移除空白層或重複層，請停用映像檔串流。

• 1.28.9-gke.1103000 以上版本
• 1.29.4-gke.1202000 以上版本
• 1.30：所有版本

缺少檔案，因此無法串流映像檔

映像檔串流功能中的錯誤可能會導致容器因缺少一或多個檔案而失敗。

在下列版本中，如果節點已啟用映像檔串流功能，在該節點上執行的容器可能無法啟動，或是在執行時發生錯誤，指出特定檔案不存在。以下是這類錯誤的範例：

• No such file or directory
• Executable file not found in $PATH

如果受到這個問題影響，可以停用映像檔串流。

閘道 TLS 設定錯誤

我們發現，在執行 GKE 1.28.4-gke.1083000 版的叢集中，為閘道設定 TLS 時會發生問題。這會影響使用 SSLCertificate 或 CertificateMap 的 TLS 設定。如果升級的叢集已有閘道，系統將無法更新閘道。如果是新的閘道，系統不會佈建負載平衡器。這個問題將在日後的 GKE 1.28 修補程式版本中修正。

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.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.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.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.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.29.10-gke.1071000 以上版本
• 1.30.5-gke.1723000 以上版本
• 1.31.2-gke.1115000 以上版本

Ray Operator 與 Cloud KMS 資料庫加密不相容

部分 Ray Operator 版本與 Cloud KMS 資料庫加密不相容。

解決方法：

將叢集控制層升級至修正版本或更新版本。

• 1.30.8-gke.1051000 以上版本
• 1.31.1-gke.2008000 以上版本

GPU 維護處理常式 Pod 卡在 CrashLoopBackOff 狀態

發生這個問題時，gpu-maintenance-handler Pod 會在各自的節點上卡在「CrashLoopBackOff」狀態。這個狀態會導致 GKE 節點無法套用「即將進行維護」標籤，進而影響工作負載的節點排除和 Pod 淘汰程序。

如果受到這個問題影響，只要將控制層升級至包含修正程式的 GKE 版本，即可解決問題。

在已啟用映像檔串流的節點上，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-gke.2541000 之前的 1.34 版本

• 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 的下一層。