1

我有一个使用 version 部署的 GKE 集群1.20.10-gke.1600。我已经使用 GCE 创建了内部入口，并将内部 ip 分配给了我的内部入口。但是，我无法从同一区域和网络中的 VM ping 到此内部入口 IP。对外部入口的 Ping 工作正常。我阅读了下面的文档，它说无法 ping 到内部 TCP/UDP，因为它没有部署为网络设备。但是，我没有看到任何有关内部 HTTPS 负载平衡器的信息。

ping 10.128.0.174
Pinging 10.128.0.174 with 32 bytes of data:
Request timed out.
Ping statistics for 10.128.0.174:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss)

问题是：为什么我无法 ping 到我的内部 LB 入口 IP？我正在尝试从同一区域和网络中的 VM ping。curl到内部入口 IP 正在工作，但ping不是。

4

1 回答 1

1

集群 IP 只是（正如Gari Singh 所写）一个不会响应的虚拟设备ping。这是预期的行为。

关于ping LB 的内部地址的文档你清楚地链接说：

此测试演示了预期的行为：您无法 ping 负载均衡器的 IP 地址。这是因为内部 TCP/UDP 负载平衡器是在虚拟网络编程中实现的——它们不是单独的设备。

然后解释原因：

内部 TCP/UDP 负载平衡是使用来宾操作系统中的虚拟网络编程和 VM 配置实现的。在 Linux VM 上，Linux 来宾环境通过在来宾操作系统路由表中安装路由来执行本地配置。由于此本地路由，流向负载平衡器 IP 地址的流量会停留在负载平衡 VM 本身上。（此本地路由与 VPC 网络中的路由不同。）

所以 - 例如，如果您尝试设置某种自定义健康检查，请确保，还要考虑从集群内部“ping”LB 的内部地址也是不可靠的：

不要依赖于从正在负载平衡的 VM 向内部 TCP/UDP 负载平衡器发出请求（在该负载平衡器的后端服务中）。请求始终发送到发出请求的 VM，而健康检查信息将被忽略。此外，后端可以响应使用协议和目标端口发送的流量，而不是在负载平衡器的内部转发规则上配置的那些。

更：

当发送请求的后端 VM 具有 --next-hop-ilb 路由且下一跃点目标是其自己的负载平衡 IP 地址时，此默认行为不适用。当 VM 以路由中指定的 IP 地址为目标时，请求可以由另一个负载平衡的 VM 应答。

例如，您可以使用 10.20.1.1 的 --next-hop-ilb 创建目标路由 192.168.1.0/24。

然后，负载平衡器后面的 VM 可以定位 192.168.1.1。由于该地址不在本地路由表中，因此将其发送到 VM 以使 Google Cloud 路由适用。假设没有其他更高优先级的路由适用，则选择 --next-hop-ilb 路由。

最后 - 查看支持的协议表- ICMP 仅适用于外部 TCP/UDP 负载平衡器。

于 2021-11-18T12:44:48.113 回答