Istio 1.3 服务之间随机出现“上游连接错误或在标头之前断开/重置”

Question

所以，这个问题是在不同的服务之间随机发生的（看起来）。

\n\n

例如，我们有一个服务 A 需要与服务 B 通信，有时我们会收到此错误，但过了一段时间，该错误就会消失。而且这个错误并不经常发生。

\n\n

发生这种情况时，我们看到服务 A 中的错误日志抛出 \xe2\x80\x9cupstream connect error\xe2\x80\x9d 消息，但服务 B 中没有消息。所以我们认为这可能与 sidecar 有关。

\n\n

我们注意到的一件事是，在服务 B 中，我们在 istio-proxy 容器中收到很多这样的错误消息：

\n\n

[src/istio/mixerclient/report_batch.cc:109] Mixer Report failed with: UNAVAILABLE:upstream connect error or disconnect/reset before headers. reset reason: connection failure\n

\n\n

根据文档，当请求进来时，envoy 会询问 Mixer 是否一切正常（授权和其他事情），如果 Mixer 没有回复\xe2\x80\x99t，则请求未成功。所以\xe2\x80\x99s为什么存在一个名为policyCheckFailOpen的选项。\n我们将其设置为false，我猜这是一个正常的默认值，我们不\xe2\x80\x99希望如果无法到达Mixer则请求通过，但是为什么可以\xe2\x80\x99t？

\n\n

disablePolicyChecks: true\npolicyCheckFailOpen: false\ncontrolPlaneSecurityEnabled: false\n

\n\n

注意：istio-policy 与 istio-proxy sidecar 一起运行。那是对的吗？

\n\n

我们在其他一些服务中看不到 xe2x80x99 的错误，这些服务也可能失败。

\n\n

我经常看到的另一个日志是，该日志发生在所有未以 root 身份运行并且在 YAML 文件中定义了 fsGroup 的服务中：

\n\n

watchFileEvents: "/etc/certs": MODIFY|ATTRIB\nwatchFileEvents: "/etc/certs/..2020_02_10_09_41_46.891624651": MODIFY|ATTRIB\nwatchFileEvents: notifying\n

\n\n

我正在寻找的线索之一是关于默认断路器值。会不会和这个有关系呢？

\n\n

谢谢

\n

Answer 1

您看到的错误是由于未能建立与 istio-policy 的连接

基于这个github问题

社区成员在此处添加两个答案，可以帮助您解决问题

如果全局启用 mTLS，请确保设置 controlPlaneSecurityEnabled: true

我遇到了同样的问题，然后我读到了协议选择。我意识到服务定义中的端口名称应该以 http- 开头。这为我解决了这个问题。和 。如果您仍然遇到问题，您可能需要查看 pod 的 tls 检查并使用目标规则和策略解决它。

istio-policy 与 istio-proxy sidecar 一起运行。那是对的吗？

是的，我刚刚查了一下，它是带有 sidecar 的。

让我知道是否有帮助。