2

我有一个托管在 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并下载成功
  • 我的应用程序记录了请求被取消（由请求者）
  • 我可以验证所有文件都没有损坏（可以直接从存储中下载所有文件）
4

1 回答 1

2

我相信您的“backend_connection_closed_after_partial_response_sent”问题是由后端提前终止的 websocket 连接引起的。您可以在 nginx 中查看有关websocket 代理的文档- 它解释了此过程的性质。简而言之 - 默认情况下 WebSocket 连接在 10 分钟后被终止。

为什么直接从 pod 下载文件时它会起作用？因为您绕过了负载平衡器，并且 websocket 连接保持正常活动。当您代理 websocket 时，事情开始发生，因为 WebSocket 依赖于未代理的逐跳标头。

这里讨论了类似的情况。它是通过从后端向客户端发送 ping 帧来解决的。

在我看来，你最好的办法就是这样做。当代理 websocket 时，我发现许多类似问题的案例，其中大多数建议使用 ping，因为它会重置连接计时器并使其保持活动状态。

这是有关使用 WebSocket和超时ping 客户端的更多信息

我为 Google 工作，这就是我可以为您提供的帮助 - 如果这不能解决您的问题，您必须联系 GCP 支持。

于 2019-11-18T11:36:16.813 回答