Istio Ingress Gateway - gRPC 连接和负载平衡的可见性答案

【问题标题】：Istio Ingress Gateway - Visibility into gRPC connections and load balancingIstio Ingress Gateway - gRPC 连接和负载平衡的可见性
【发布时间】：2021-02-13 04:28:03
【问题描述】：

我们有一个 gRPC 应用程序部署在具有 Istio (v 1.6.2) 设置的集群 (v 1.17.6) 中。集群将 istio-ingressgateway 设置为边缘 LB，并带有 SSL 终止。 istio-ingressgateway 前面是一个 AWS ELB（经典 LB），处于直通模式。通常，此设置功能齐全，流量按预期流动。所以设置看起来像：

ELB => istio-ingressgateway => 虚拟服务 => 应用服务 => [(envoy)pods]

我们正在使用 GHZ (ghz.sh) 在此设置上运行负载测试，在应用程序集群外部运行。从我们运行的测试中，我们观察到每个应用程序容器似乎都有大约 300 RPS 路由到它，无论 GHZ 测试的配置如何。作为参考，我们为测试尝试了 --concurrency 和 --connection 设置的各种组合。这约 300 RPS 低于我们对应用程序的预期，因此需要更多的 POD 来提供所需的吞吐量。

在这种情况下，我们非常有兴趣了解物理连接 (gRPC/HTTP2) 设置的详细信息，从 ELB 到应用程序/特使以及正在完成的负载平衡的详细信息。特别令人感兴趣的是同一个客户端（例如 GHZ）打开多个连接（通过 --connection 选项指定）的情况。我们已经查看了 Kiali，但它并没有给我们适当的可见性。

问题：

我们如何才能了解正在设置的从入口网关到 pod/代理的物理连接？
“按请求 gRPC”负载平衡是如何发生的？
可能存在哪些选项来优化此设置中涉及的各种组件？

谢谢。

【问题讨论】：

标签： kubernetes amazon-elb istio

【解决方案1】：

1.我们如何才能了解从入口网关到 Pod/代理的物理连接？

如果 Kiali 没有显示您的确切需求，也许您可以尝试使用 Jaeger？

Jaeger 是一个开源的端到端分布式跟踪系统，允许用户监控复杂分布式系统中的事务并进行故障排除。

有关于 Jaeger 的 istio 文档。

另外Prometheus 和Grafana 在这里可能会有所帮助，看看here。

2.“per request gRPC”负载均衡是如何发生的？

如上所述here

默认情况下，Envoy 代理使用循环模型在每个服务的负载平衡池中分配流量，其中请求依次发送到每个池成员，一旦每个服务实例收到请求，就会返回到池的顶部.

如果您不想更改默认的循环模式，您可以使用Destination Rule。目标规则允许您在调用整个目标服务或特定服务子集时自定义 Envoy 的流量策略，例如您首选的负载平衡模型、TLS 安全模式或断路器设置。

关于那个有 istio documentation。

更多关于 envoy here 中的负载平衡。

3.可能存在哪些选项来优化此设置中涉及的各种组件？

我不确定在 Istio 组件中是否有任何需要优化的地方，也许是 Destination Rule 中的一些自定义配置？

其他资源：

【讨论】：