kubernetes - GKE 流式大文件下载失败，部分响应

Question

我有一个托管在 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 状态代码。谷歌对此没有任何帮助。

直接访问pod并使用k8s port-forward下载成功

我的应用程序记录请求已取消(由请求者)

我可以验证没有任何文件损坏(可以直接从存储下载所有文件)

Answer 1

我相信您的“backend_connection_closed_after_partial_response_sent”问题是由后端过早终止 websocket 连接引起的。您可以在 websocket proxying in nginx 上查看文档- 它解释了这个过程的性质。简而言之 - 默认情况下，WebSocket 连接会在 10 分钟后终止。

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

类似 case was discussed here .它是通过从后端向客户端发送 ping 帧来解决的。

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

这里有更多关于 pinging the client using WebSocket和 timeouts

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