问题标签 [google-cloud-internal-load-balancer]

每次客户端发送任何请求（例如 HTTP）时，负载均衡器（如果已设置）都会收到该请求，并将请求重定向到其中一个实例。现在Client->LB->Server之间建立了连接。只要客户端不断发送请求，这种情况就会持续存在。但是如果客户端停止向服务器发送请求一段时间（超过空闲时间），负载均衡器将停止客户端与该特定服务器之间的通信。现在，如果客户端在一段时间后再次尝试发送请求，那么负载均衡器应该将该请求转发到其他实例。

什么是空闲时间？这是客户端不向负载均衡器发送任何请求的一段时间。它通常在 60 到 3600 秒之间，具体取决于云服务提供商。

最后是我的怀疑。

理想情况下，在空闲超时之后，负载均衡器应该终止现有的通信，但 GCP 的内部负载均衡器不是这种情况（我在这种情况下也有一个 PoC）。GCP 的负载均衡器即使在空闲超时后也不会终止通信并无限期地保持它。有什么办法可以重新配置负载均衡器以避免这种无限时间连接？

几天以来，我在尝试在 Google Cloud 上部署使用内部负载平衡器的新服务时遇到以下错误：

创建负载均衡器时出错（将重试）：无法确保服务生产交易/身份验证的负载均衡器：googleapi：错误 403：您无法在此项目中创建更多内部转发规则，因为已达到 20.0 的限制。， internalForwardingRulesLimitsExceeded

在Google Cloud 文档中，限制应该是 50。

另外，通常我会要求增加配额，但这次我在配额部分没有找到与此功能相关的配额。

任何想法 ？谢谢

我正在尝试在 GCP 云上设置内部负载均衡器，问题是，当我尝试通过另一个属于同一 VPC 的实例访问相同的负载均衡器时，我面临“连接被拒绝”错误。已检查防火墙规则并交叉检查负载均衡器和尝试访问的独立实例是否位于同一子网中。

背景：我们在 GKE 集群中托管应用程序，在 GKE 集群上运行的应用程序有一个入口资源，其中包含指向我们的应用程序服务的规则。我们使用 ingress-nginx 作为这个集群的入口控制器。

我们现在已经创建了一个 GCP 内部负载均衡器 (TCP) 来指向 ingress-controller 服务正在侦听的节点端口。（注意：“nginx 入口控制器服务”是节点端口类型）

1. 当我们尝试使用http://ILB-IP:80 (http-port) 访问应用程序时，它会抛出连接被拒绝异常，但是当我们直接使用 nodeport http://ILB-IP:31380 (nodeport)访问时会得到所需的响应

2. 当我们将入口服务作为类型负载均衡器提供时，GCP 在后台创建一个 ILB。在这种情况下，应用程序可以通过 http 端口访问，并且所有请求都在处理。

任何人都可以帮助我们弄清楚我们何时显式创建 ILB 并发送请求，为什么当我们在 http 端口上访问 ILB 前端时应用程序无法访问，而当 ILB 前端是 ILB-IP 时应用程序可以访问：？

提前致谢！

我在 GCP 中建立了自己的 Elasticsearch 集群。集群已启动并运行良好。

集群包含两个client节点，我可以在内部访问它们并使用http://IP:9200/和对它们进行运行状况检查/http://IP:9200/_cluster/health。所有节点都只有私有 IP。

我补充说：

• client仅跨越节点的内部负载均衡器，

• 防火墙规则将两者都列入白名单：130.211.0.0/22, 35.191.0.0/16带有适当标签的谷歌健康检查 IP 范围，

• client主机的上述规则的适当标签，

• 谷歌健康检查服务是否可用，

• 后端和实例组。

问题是所有client主机都添加到负载均衡器，但任何主机都标记为健康。

如果我遗漏了什么，你能告诉我吗？

是否可以对没有公共 IP 的实例进行健康检查？

谢谢，卡罗尔

我需要从另一个 GCP 区域访问在内部负载均衡器上运行的 GKE Nginx Ingress 服务上运行的内部应用程序。

我完全清楚直接使用 Google 网络是不可能的，这是一个巨大的限制（GCP 功能请求）。

内部负载均衡器可以通过 AWS 的 VPN 隧道很好地访问，但我不确定在同一网络下的 GCP 区域之间创建这样的隧道是一个好主意。

欢迎解决方法！

我在 GKE 中创建了一个使用内部负载均衡器公开的服务。ILB 的健康检查端口是 10256，它是 kube-proxy。ILB 上的端口是我的 kubernetes 服务端口的端口。（不是目标端口）。但是，在 ILB 上没有这样的信息表明流量正在到达暴露服务的 NodePort。这在内部如何工作？

我尝试使用本文档中提到的以下注释创建内部负载均衡器：

这是完整的清单：

我尝试从不同区域的 VM 访问负载均衡器，但 VM 无法到达端点。

但是，根据此文档，我在创建的转发规则上运行以下命令（GCP 为所有可以使用gcloud compute forwarding-rules list命令检索的负载均衡器创建一个具有随机名称的转发规则）以更新全局访问：

运行上述命令并手动更新负载均衡器后，可以从所有区域访问端点。运行命令的这个手动步骤是否gcloud必要？

如果是，那么注释的用途是什么？我也使用最新的可用 GKE 版本 ( 1.15.4-gke.22 ) 进行注释，但如果不使用该gcloud命令进行更新，它将无法工作。是我遗漏了什么还是 GCP 中的错误？

编辑：我还用 GCP 打开了这个问题，这个问题很快得到了解决，他们更新了公共文档（2020 年 1 月 15 日），特别提到了 GKE 1.16 要求全球访问功能正常工作。

我正在尝试在端口 2379 上运行的 3 个 etcd 集群前面部署负载均衡器。但我总是收到连接被拒绝错误。我为健康检查添加了防火墙 IP，并在端口 2379 上添加了 0.0.0.0 的 fw 规则，但仍然存在此问题。部署一个内部 LB 以对在 2379 端口上服务的后端服务器进行负载平衡太难了，我错过了什么吗？

以前有人遇到过这种问题吗？

是否可以在 GCP 中创建一个内部负载均衡器来平衡不同区域的两个计算实例之间的流量？

两个实例（在它们上写入 NAT）位于不同的区域（例如一个 inus-central1和另一个 in asia-south1）在相同的端口上提供服务，并且内部负载均衡器（例如使用 IP: 170.0.0.4）正在接受来自客户端的请求并将它们转发到这些 VM。

这将有助于创建一个高可用性服务（在本例中为 NAT），即使在一个 VM 或服务或区域关闭时也能正常工作。

编辑：

在此处添加更多详细信息：

1. 虚拟机和负载均衡器都有内部 IP。
2. 虚拟机和负载均衡器都在同一个 VPC 网络中
3. 我需要一个第 7 层 (HTTP(S)) 内部 lLoad 平衡器。