GKE 已知问题

动态预配的 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 存储桶中重命名或移动文件可能会失败，并显示 I/O 错误。

临时解决方法：

临时向 Pod 清单添加特定的边车映像定义。在 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 将继续为升级后的集群版本自动注入和管理正确的边车映像。

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 调整器插件：使用 containerd/nri ulimit-adjuster 插件调整 ulimit。
• 降级节点池（仅限 Standard）：对于 Standard GKE 集群，您可以暂时将节点池降级到 1.32 版，以避免此问题，直到有永久性解决方案可用为止。

托管式 CRD 的 CRD status.storedVersions 无效

某些 GKE 管理的 CRD 可能具有无效的 status.storedVersions 字段，这会带来升级后无法访问 CRD 对象的风险。

此问题会影响同时满足以下两个条件的集群：

• 在某个时间点使用过受影响的 GKE 版本的集群。
• 在 etcd 中存储了不受支持 (served=false) 版本的 CRD 对象的集群。

临时解决方法：

建议的解决方法是延迟集群升级，直到问题得到解决。

或者，如果您知道集群包含不受支持的 CRD 对象版本，可以使用 kubectl patch 命令将这些版本添加到 status.storedVersions 字段。

• 1.32.2-gke.1652003 或更高版本
• 1.31.6-gke.1221001 或更高版本
• 1.30.10-gke.1227001 或更高版本

缺少指标或工作负载自动扩缩器未扩缩

如果集群大小增加超过 5 个节点，您可能会发现受影响的版本上的指标数据出现缺口。此问题还可能会影响自动扩缩操作。

此问题仅影响升级到受影响版本的集群。新创建的集群应能按预期运行。

临时解决方法：

如果您受到影响，可以降级一个补丁版本，也可以升级到较新的修复版本。

Google Cloud Hyperdisk 大小和连接限制

通常，如果 pod 因节点的卷连接限制而无法成功调度，则会触发新节点的自动预配。当运行使用 Hyperdisk 产品的工作负载被调度到运行 C3 虚拟机的节点时，不会发生节点自动预配，并且 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 连接限制因虚拟机 vCPU 数量和 Hyperdisk 产品而异。如需了解详情，请参阅 Hyperdisk 性能限制。

临时解决方法：

Hyperdisk 产品会在其他虚拟机类型上触发自动预配。我们建议使用仅支持 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，以移除该状态。您可以使用如下所示的 patch 命令来移除悬空状态：

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 驱动程序可能会过度记录日志

如果 GKE 集群运行的是特定的 1.32 版本，则可能会从 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 及更高版本

尝试在之前具有只读 (RO) 装载的 COS 节点上装载 NFS 永久性卷的 Pod 将仅以 RO 模式装载

对于 GKE 1.27 版及更高版本，使用 Kubernetes 树内 CSI 驱动程序的 NFS 卷只能在同一节点上进行之前的 RO 装载后，才能以 RO 模式装载永久性卷。

临时解决方法：

将节点池降级到受影响版本之前的版本

• 1.32.1-gke.1357001 之前的 1.32　版本到　1.32.4-gke.1106000，但不包括 1.32.4-gke.1106000。
• 1.33.0-gke.1552000 之前的所有 1.33 版本

• 1.32 版本：1.32.4-gke.1106000 及更高版本
• 1.33 版本：1.33.0-gke.1552000 及更高版本

尝试在 Ubuntu 节点上装载 NFS 永久性卷的 Pod 将无法运行。

对于使用 Kubernetes 树内 CSI 驱动程序的 GKE 1.32 版及更高版本 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.1668000 或更高版本
• 1.29.13-gke.1028000 或更高版本
• 1.30.8-gke.1287000 或更高版本
• 1.31.6-gke.1020000 或更高版本
• 1.32.1-gke.1302000 或更高版本

使用与 io_uring 相关的系统调用的 Pod 可能会卡在“正在终止”状态

由于 Linux 内核中存在 bug，使用与 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 及更高版本

使用映像流式传输的工作负载因身份验证错误而失败

映像流式传输功能中的 bug 可能会导致工作负载在容器读取文件时满足一组特定条件的情况下失败。您可能会在 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 逐出率提高

分别使用 COS 113 和 COS 117 的部分 GKE 1.30 和 GKE 1.31 版本具有使用 CONFIG_LRU_GEN_ENABLED=y 选项构建的内核。此选项会启用内核功能 Multi-Gen 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 停用 Multi-Gen LRU 选项。

1. 更新您要在其中运行 DaemonSet 的 GKE 节点池，并添加注解以停用 Multi-Gen 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) 中的 bug 可能会导致 Pod 和容器卡在“正在终止”状态，并显示类似于以下内容的错误：

如果您受到此问题的影响，可以将节点升级到具有已修复的 containerd 版本的 GKE 版本。

• 1.28.9-gke.1103000 及更高版本
• 1.29.4-gke.1202000 及更高版本
• 1.30：所有版本

由于符号链接，映像流式传输失败

映像流式传输功能中的 bug 可能会导致容器无法启动。

在特定 GKE 版本上启用了映像流式传输的节点上运行的容器可能无法创建，并显示以下错误：

如果您受到此问题的影响，可以检查是否存在空层或重复层。如果您无法移除空层或重复层，请停用映像流式传输。

• 1.28.9-gke.1103000 及更高版本
• 1.29.4-gke.1202000 及更高版本
• 1.30：所有版本

由于缺少文件，映像流式传输失败

映像流式传输功能中的 bug 可能会导致容器因缺少一个或多个文件而失败。

在以下版本上启用了映像流式传输的节点上运行的容器可能无法启动或运行，并显示某些文件不存在的错误。以下是此类错误的一些示例：

• 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.8 之前的 1.27 补丁版本，则可能会遇到节点 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 部署失败

Container Threat Detection 可能无法部署在运行以下 GKE 版本的 Autopilot 集群上：

• 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