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

我使用 Google Cloud TCP 负载平衡器将请求转发到 Kubernetes NGINX 服务。正如预期的那样，NGINX 上的日志显示负载均衡器 IP。如何检索实际 IP

我遵循创建基于内容的负载平衡的文档：https ://cloud.google.com/load-balancing/docs/https/content-based-example

我想用 https 访问外部地址。我希望负载均衡器通过简单的 http 连接到 VM。

两个虚拟机都按预期工作，并在通过 IP 地址到达时返回正确的应答。LB的设置看起来不错。两项运行状况检查均通过且 Google SSL 证书处于活动状态。

但是，当我尝试访问负载均衡器的 IP 地址或域时，我得到 502。

LB IP 为 35.244.161.226 wciel.pl

负载均衡器的日志显示statusDetails: "failed_to_connect_to_backend"

我附上了我的 Google Cloud Console 的屏幕。

请指教。

我目前正在 GCE 中实施蓝绿色设置。本质上，我正在做的是将 nginx 负载均衡器作为 GCP 的后端，因为可以快速完成将规则切换到 nginx 中的不同池。

如果没有可用的 nginx 后端，我想对存储在存储桶中的自定义页面进行错误处理，但我看不到使用标准运行状况检查的明确方法。有没有人遇到过这种事情？

这指的是 GCP Http(s) 全局负载平衡教程。此示例显示了基于跨区域内容的负载平衡。我想检查是否可以使用类似的配置（基于 URL 映射）为另一个区域的应用程序设置 DR 站点。例如，

• europe-west3 区域（主要）中的实例组。在负载均衡器配置时添加的 URL 映射条目。
• Europe-west4 区域 (DR) 中的另一个实例组。

这个想法是在调用 DR 过程时更新 URL 映射条目以指向第二个 (DR) 实例组。

问题

1. 假设 DR 实例组始终处于启动状态（活动），URL 映射条目更新需要多长时间才能开始将流量路由到第二个 (DR) 实例组？
2. 是否有另一种方法可以在不更新 URL 映射的情况下开始将流量路由到第二个实例组？是否可以配置 DNS 设置以创建类似的效果？

2019 年 10 月 15 日更新

目前，最好的选择似乎是设置一个多区域部署，并将 URL 映射配置到两个区域。GFE 将确保从主要区域向用户提供流量——假设主要区域离用户最近。但是，由于 DR 触发器以外的原因（如这篇有用的文章中列出的那样），流量可能会溢出到辅助 (DR) 区域，这需要加以考虑。

客观的：

我想允许https://example.com、http://example.com和 www.example.com 指向我在 Google Cloud Storage 存储桶上托管的静态网站。

我的设置：

我在 Google Cloud Storage 存储桶上托管一个静态网站。

• 名为 www.example.com 的存储桶
• 我有带有 https 前端的负载均衡器和作为后端的存储桶。
• 在 Cloud DNS 中，我有指向存储桶的 CNAME 记录。
• 我有一条记录，将我的域“example.com”指向负载均衡器前端的 https IP 地址。

通过上述设置，https: //example.com 和 www.example.com 可以正常工作。

我也想允许http。因此，我在负载均衡器“http”中添加了另一个前端。然后，我将该前端的 IP 地址添加到现有的 A 记录中。所以，现在我的 A 记录有 http 和 https 的 IP 地址。

之后，http ://example.com开始工作。但是，https://example.com停止工作。我错过了什么吗？

我在 GCP 上有一个集群，上面有多个部署。部署通过 NodePort 服务公开。我正在设置一个 HTTP(S) 负载均衡器，目的是从前端路由到后端服务，一个域到一个部署。

问题是当我保存负载均衡器时，我定义的后端服务突然都指向同一个端口。这导致两个定义的域都指向相同的服务。

https://i.imgur.com/q2tfbFY.png 这是它的设置方式，有两个后端服务。

https://i.imgur.com/sBaRsdd.png 这是主机和路径规则的定义方式。

https://i.imgur.com/JGt7aco.png 编辑“first-backend-service”中的“Port numbers”并保存负载均衡器时，“second-backend-service”中的端口号会发生变化与“first-backend-service”中定义的相同。

我试过使用两个负载均衡器，每个服务一个，结果相同。

我面临的问题是我的 istio-ingressgateway 在网络层负载均衡器（L4 负载均衡器或 TCP 负载均衡器）上完美运行文件，但是当我通过在后端服务附加 nodePort 将 istio-ingressgateway 连接到第 7 层负载均衡器时。之后 http 到 https重定向无法正常工作，即使我使用 https 协议请求，它也总是给出响应代码 301。

我正在将 Heroku 迁移到 Google Cloud Platform，目前我正在运行 3 个 n1-highcpu-4 节点 GKE 集群来测试设置和我的应用程序。集群是使用默认配置构建的（抢占式节点除外）。为了创建 Ingres、LB（使用 NEG 平衡）并使用 Google 管理的 SSL 证书，我严格遵循了以下指南：

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer https://cloud.google.com/ kubernetes-engine/docs/how-to/container-native-load-balancing#create_service

在我开始负载测试之前，一切都可以完美地开箱即用。

我们的 Web 应用程序正在从传感器收集数据，通过 HTTP(S) POST 发送给它。我使用 loader.io 进行测试，这个集群每秒处理大约 30k 个请求，通过 HTTP 的响应时间不到 200 毫秒。然而，当我切换到 HTTPS 并重复测试时，性能急剧下降到不到 4k RPS，响应时间为 1.7s-4s。

我尝试运行更多 pod，添加新节点；从 loader.io 向 LB 发送更多请求；配置保持活动/空闲超时；一些内核调整，但没有一个有助于跨越 4k RPS 障碍。即使用 nginx 容器替换应用程序并测试其静态欢迎页面也有相同的结果。

Stackdriver GCLB 指标显示大约 10 毫秒的前端延迟和 8 秒的后端延迟。但是，我的应用程序的指标显示请求通常需要 20 毫秒到 700 毫秒之间。

ingress.yml：

service.yml

backend-config.yml就是这样：

对于提高 HTTPS 性能和减少请求延迟或帮助我进一步调查的任何建议，我将不胜感激。我现在被困住了:(谢谢！

我有一个托管在 GKE 上的应用程序，在许多任务中，它向客户端提供了一个 zip 文件。这些 zip 文件是通过谷歌云存储上的许多单独文件动态构建的。

我面临的问题是，当这些 zip 变得特别大时，连接会随机失败（介于 1.4GB 到 2.5GB 之间）。时间似乎也没有任何规律——它可能发生在 2-8 分钟之间。

AFAIK，负载平衡器和我的应用程序之间的连接断开连接。是否已知 GKE 入口（负载均衡器）会关闭长/大连接？

GKE 设置：

• HTTP(S) 负载平衡器入口
• NodePort 后端服务
• 部署（我的应用程序）

更多细节/调试步骤：

• 我无法在本地复制它（没有 kubernetes）。
• 负载均衡器记录statusDetails: "backend_connection_closed_after_partial_response_sent"，而响应具有 200 状态代码。对此的谷歌没有任何帮助。
• 使用k8s port-forward直接访问pod并下载成功
• 我的应用程序记录了请求被取消（由请求者）
• 我可以验证所有文件都没有损坏（可以直接从存储中下载所有文件）

我有一个在 App Engine 上的自定义 Java 容器中运行的应用程序。我一直在试图找出为什么我收到过时的响应，并将问题缩小到缓存的响应。

我知道我们的应用程序没有返回过时的内容，因为我们没有共享缓存，并且在我们重新部署后过时的响应仍然存在。我们也没有使用 Cloud CDN。

当我在https://[app-id].appspot.com/api/123访问我的应用程序 API 时，我的应用程序返回一个Cache-Control: public, s-maxage=31536000, max-age=3600响应标头。s-maxage旨在告诉 Cloudflare（我们的 CDN）缓存响应，我们在更新内容时手动清除 Cloudflare 的缓存。但是，我们的应用程序前面似乎有一些东西正在缓存响应。在缓存的响应中，日期响应标头保持不变并且年龄增加，表明内容确实是陈旧的。

我在 App Engine 标准文档中看到了有关缓存的文档app.yaml，但我在 App Engine 灵活文档中找不到任何提及缓存基础设施的内容。我的心智模型是，只有 HTTPS 负载平衡代表应用程序发生，但情况似乎并非如此。

如果我尝试通过 SSH 连接到 Compute Engine 实例或 App Engine Flexible 实例从 GCP 中重现此问题，我不会观察到任何缓存。但是，我已经从其他云和笔记本电脑上尝试过，并且缓存是一致的。Cloudflare 支持人员最初提醒我们注意这种行为，他们看到了来自生产数据中心的缓存，这些数据中心通过他们的 CDN 互连程序直接与 Google 对等。

这必须来自 Google 的基础架构本身，可能是用于 App Engine 的隐藏的 Google Cloud Load Balancer，因为连接是加密的。

缓存在做什么，如何禁用它，以及如何清除它？