本页面列出了 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 地址耗尽问题。此问题是由容器运行时 bug 引起的，当 Pod 在创建期间遇到临时 CNI 错误时，该 bug 可能会泄漏已分配的 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 托管负载均衡器的后端分离。这会导致负载均衡器没有活跃的后端，进而导致发送到这些负载均衡器的所有入站请求都被丢弃。 此问题会影响使用旧版网络且版本为 1.31 或更高版本的 GKE 集群。 如需识别使用旧版网络的 GKE 集群，请运行以下命令：
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"
如果集群采用旧版网络，此命令将返回空输出。 临时解决方法： 由于旧版网络已弃用一段时间，因此首选解决方案是将旧版网络迁移到 VPC 网络。为此，您可以转换包含 GKE 集群的旧版网络。如果您目前无法执行此迁移，请与 Cloud Customer Care 联系。 |
| 1.30、1.31、1.32 |
|
新创建的节点未添加到第 4 层内部负载均衡器为内部 LoadBalancer Service 创建的 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 无法创建，并卡在 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 此问题会影响版本介于 1.32 和 1.32.3-gke.1170000 之间的 GKE 集群，这些集群是在 GKE 版本 1.31 或 1.32 下创建的。根本原因是，维护已分配 Cilium 身份集合的内存中数据结构未与 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 |
从 Service 中移除端口后，NEG 控制器停止管理端点当 NEG 控制器配置为为某个 Service 创建独立 NEG 时，如果其中一个已配置的端口稍后从该 Service 中移除，NEG 控制器最终会停止管理该 NEG 的端点。除了用户在其中创建独立 NEG 注解的 Service 之外，这还会影响 GKE 网关、MCI 和 GKE 多集群网关引用的服务。 临时解决方法： 从具有独立 NEG 注解的 Service 中移除端口时，还需要更新该注解以移除相关端口。 |
|
| 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 使用 Service 或内部直通式网络负载均衡器的虚拟 IP 地址连接到自身时，由于数据平面中的 conntrack 查找不正确，回复数据包不被认定为现有连接的一部分。这意味着限制 Pod 入口流量的网络政策未在数据包上正确施行。 此问题的影响取决于为 Service 配置的 Pod 数量。比方说，如果 Service 有 1 个后端 Pod，则连接始终失败。如果 Service 有 2 个后端 Pod，则连接失败几率为 50%。 临时解决方法：
要缓解此问题，您可以将 Service 清单中的 |
| 1.27、1.28 |
|
“发卡”(hairpin) 连接流的数据包丢弃对于已启用 GKE Dataplane V2 的集群，当 Pod 使用 Service 创建一个连接到自身的 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) 发现的旧版机制，当可用区级集群中的节点在控制平面重启期间暂时不可用时，该机制会错误地报告零个后端。这会导致负载均衡器移除所有后端，从而导致流量丢失。 解决方法：
|