GKE 网络已知问题

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

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

选择您的 GKE 版本：

或者，搜索您的问题：

已识别的版本 已修复的版本 问题和解决方法
1.30、1.31、1.32

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

Google Cloud 为内部 LoadBalancer Service 创建的负载平衡器可能会错过后端实例组中新创建的节点。

此问题最明显地体现在将集群缩减为零个节点，然后再扩容为一个或多个节点的集群上。

解决方法：

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

    注意：GKE 子集化功能一经启用便无法关闭。

  • 再创建一个内部负载平衡器服务。同步时，系统还会为受影响的服务修正实例组。同步后，您可以移除新服务。
  • 在其中一个节点上添加 node.kubernetes.io/exclude-from-external-load-balancers 标签，然后将其移除。
  • 向集群添加节点。服务开始运行后，您可以移除该节点。
1.27、1.28、1.29、1.30、1.31

从 Service 中移除端口后，NEG 控制器会停止管理端点

如果 NEG 控制器配置为为某项服务创建独立 NEG，而稍后从该服务中移除了其中一个已配置的端口，NEG 控制器最终会停止管理该 NEG 的端点。除了用户创建独立 NEG 注解的服务之外，这还会影响 GKE 网关、MCI 和 GKE 多集群网关引用的服务。

临时解决方法：

从具有独立 NEG 注解的服务中移除端口时，还需要更新该注解以移除相关端口。
1.28

网关 TLS 配置错误

我们发现了在运行 GKE 1.28.4-gke.1083000 版本的集群中为网关配置 TLS 时存在的问题。这会影响使用 SSLCertificate 或 CertificateMap 的 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 清单中的 port 和 containerPort 配置为相同的值。

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 的机器类型。