kubernetes Istio在两分钟后以较大的响应剪切请求

ndasle7k  于 2023-08-03  发布在  Kubernetes
关注(0)|答案(1)|浏览(128)

我有一个Kubernetes环境,设置了Istio网关。我偶然发现了一个我似乎无法解决的问题。
我们创建了一个Nodejs后端微服务,它提供一个API,其中一个API端点可以提供100 MB以上的大响应。我们所有的微服务部署都支持Istio Proxy sidecar。
我尝试的第一种方法是使用流响应。当我向这个API发出请求,并且我知道我可以期待如此大的响应,它总是在两分钟后被切断(或者大约96 MB的流响应)。
我采取的另一种方法是在后端构建响应,然后返回整个响应,但两分钟后返回类似的失败响应。有趣的是,我可以在后端的日志中观察到Request aborted by the client,然后Istio网关重试两次向后端发送具有相同ID的相同请求,以相同的方式失败。
如果我直接在Pod上curl请求,因此完全绕过网关,我在大约2分39秒后收到了109 MB的完整响应,没有任何问题,所以这再次保证了我的理论,即问题在网关级别的某个地方。
我已经尝试在我使用的虚拟服务上手动将超时限制设置为300 s,以防万一,但结果是一样的。
我的第二个选择是尝试增加Istio Proxy sidecar上的readiness Probe的failureTreshold配置数量,以防健康请求超时,在请求完成之前,这在这种情况下也没有任何积极的结果。
我已经检查了Istio Sidecar的日志,我相信那里正在发生一些事情。在这个屏幕截图中,您可以看到整个连接被重新创建-这是两分钟后发生的事情x1c 0d1x
下面是一个完整的日志:istio.log
我希望有人能帮助我解决我的问题,因为我已经不知道是什么原因导致了这个问题。如果有任何额外的信息需要我会很乐意提供。

pcrecxhr

pcrecxhr1#

在我的示例中,我还使用OAuth2 Client进行授权,该授权是在Kubernetes中使用Istio与Oathkeeper结合实现的,Oathkeeper的超时配置为120秒。由于我没有权限更改Oathkeeper的资源,我的解决方案是手动对大型响应进行分页并将其流式传输到客户端。

相关问题