GKE 网络已知问题


本页面列出了 GKE 网络的已知问题。本页面适用于管理底层技术基础设施生命周期,并在未实现服务等级目标 (SLO) 或应用故障时对提醒和页面做出响应的管理员和架构师。

如需按产品版本过滤已知问题,请从下面的下拉菜单中选择所需的过滤条件。

选择您的 GKE 版本:

  • 1.30
  • 1.29
  • 1.28
  • 1.27

或者,搜索您的问题:

已识别的版本 已修复的版本 问题和解决方法
1.30、1.31、1.32
  • 1.31.5-gke.1068000 及更高版本
  • 1.32.1-gke.1002000 及更高版本

新创建的节点未添加到第 4 层内部负载均衡器

为内部 LoadBalancer Service 创建的 Google Cloud 负载均衡器可能在后端实例组中缺失新创建的节点。

该问题在缩减至零个节点,然后又扩增回一个或多个节点的集群中非常明显。

解决方法:

  • 启用 GKE 子集并重新创建 Service。

    注意:GKE 子集一旦启用便无法关闭。

  • 创建另一个内部 LoadBalancing Service。同步后,受影响的 Service 的实例组也会得到修复。同步完成后,可以移除新 Service。
  • 在其中一个节点中添加 node.kubernetes.io/exclude-from-external-load-balancers 标签,然后将其移除。
  • 向集群添加节点。Service 开始正常运行后,您可以移除该节点。
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 时存在问题。这会影响使用 SSLCertificateCertificateMap 的 TLS 配置。 如果您要升级包含现有网关的集群,则对网关所做的更新将失败。新网关的问题则是,负载均衡器未得到预配。我们会在即将发布的 GKE 1.28 补丁版本中修复此问题。

1.27、1.28、1.29
  • 1.26.13-gke.1052000 及更高版本
  • 1.27.10-gke.1055000 及更高版本
  • 1.28.6-gke.1095000 及更高版本
  • 1.29.1-gke.1016000 及更高版本

连接建立间歇性故障

在控制平面 1.26.6-gke.1900 及更高版本上的集群可能会遇到连接建立间歇性故障的问题。

发生故障的可能性很低,并且不会影响所有集群。从出现问题起,几天后故障应完全消停。

1.27、1.28、1.29
  • 1.27.11-gke.1118000 或更高版本
  • 1.28.7-gke.1100000 或更高版本
  • 1.29.2-gke.1217000 或更高版本

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 清单中的 portcontainerPort 配置为相同的值。

1.27、1.28
  • 1.28.3-gke.1090000 或更高版本
  • 1.27.11-gke.1097000 或更高版本

“发卡”(hairpin) 连接流的数据包丢弃

对于已启用 GKE Dataplane V2 的集群,当 Pod 使用 Service 创建一个连接到自身的 TCP 连接,以便 Pod 同时充当连接的来源和目的地时,GKE Dataplane V2 eBPF 连接跟踪功能错误地跟踪连接状态,导致 conntrack 条目泄露。

当连接元组(协议、源/目标 IP 和源/目标端口)泄露时,使用同一连接元组的新连接可能会导致返回数据包丢弃。

解决方法:

请使用下列解决方法之一:

  • 为可能使用 Service 与自己通信的 Pod 中运行的应用启用 TCP 重复使用 (keep-alive)。这可以防止发出 TCP FIN 标志,并避免泄露 conntrack 条目。
  • 使用短期连接时,请使用代理负载均衡器(例如网关)公开 Pod,以公开 Service。这会导致连接请求的目的地设置为负载均衡器 IP 地址,从而阻止 GKE Dataplane V2 对环回 IP 地址执行 SNAT。
1.31.0-gke.1506000 之前的版本 1.31.0-gke.1506000 及更高版本

GKE 多网络中的设备类型网络在网络名称过长时会失败

集群创建失败,并显示以下错误:

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

解决方法:

将设备类型的网络对象名称的长度限制在 41 个字符以内。编写每个 UNIX 域套接字的完整路径,包括相应的网络名称。Linux 对套接字路径长度有限制(低于 107 个字节)。在考虑目录、文件名前缀和 .sock 扩展名后,网络名称的长度上限为 41 个字符。

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.28、1.29、1.30、1.31

在总节点数少于 3 个且 vCPU 不足的集群中,Calico Pod 运行状况不佳

在满足以下所有条件的集群上,无法调度 calico-typha 和 calico-node Pod:总节点数少于 3 个,每个节点的可分配 vCPU 数为 1 或更少,并且已启用网络政策。这是由于 CPU 资源不足。

解决方法:

  • 扩容至至少 3 个节点池,其中 1 个节点使用 1 个可分配 vCPU。
  • 将单个节点池的大小调整为至少 3 个节点,且每个节点具有 1 个可分配 vCPU。
  • 使用在包含单个节点的节点池中至少具有 2 个可分配 vCPU 的机器类型。