如何解决Istio使节代理请求循环导致OOM 有关症状的更多详细信息:
我有一个有趣的问题。我认为我发现了一个无限的请求循环,这导致我的istio-proxy在特定情况下因OOM错误而崩溃。
当我直接从应用程序容器内部向应用程序本地提交请求时,它似乎运行良好,并且在istio-proxy
日志中,我看到upstream_cluster
是PassthroughCluster
但是,当我通过用于SSL终止的特使代理(而不是应用程序/网格的istio-proxy)提交请求时,该请求似乎会被重试/重复,直到istio-proxy
崩溃并出现OOM;我在那些日志中看到的唯一的上游集群是inbound|80|myapp
有人以前见过类似的东西吗?似乎请求已被路由到错误的侦听器,或者我们坐在网格中的应用程序前面的特使代理以某种方式弄乱了请求。
有关症状的更多详细信息:
我在服务网格中只有一个应用程序,该应用程序的流量来自处理SSL终止的特使代理服务器
Envoy -> (istio-proxy / app ) -> other services
当我从app
内部直接将请求发送到localhost时,它可以正常工作;当我直接转发到(istio-proxy / app)
窗格并发出请求时,它也可以正常工作。当我通过Envoy
发送请求时,我开始在(istio-proxy / app)
日志中看到数千个相同的请求,最终istio-proxy
随OOM崩溃。
解决方法
事实证明,这并不是Istio或Envoy的问题;
我的应用程序充当反向代理并转发入站请求。
当请求通过Envoy
进入时,它更改了请求的HOST
标头以匹配k8s服务。
当我们的服务收到请求时,它会在主机标头完整的情况下转发该请求,然后istio-sidecar尝试使用此标头;这是导致问题的原因。
在反向代理应用中更新或删除主机标头可以解决此问题。
此github问题具有更多详细信息
https://github.com/istio/istio/issues/26946#issuecomment-715365117
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。