我们在具有Istio（v 1.6.2）设置的群集（v 1.17.6）中部署了一个gRPC应用程序。群集将istio-ingressgateway设置为边缘LB，并带有SSL终止。 istio-ingressgateway在直通模式下位于AWS ELB（经典LB）的前面。通常，此设置可以正常运行，并且流量按预期进行。因此设置如下：
ELB => istio-ingressgateway =>虚拟服务=>应用程序服务=> [（特使）豆荚]
我们正在使用GHZ（ghz.sh）在此设置上运行负载测试，并在应用程序集群外部运行。从我们运行的测试中，我们发现，无论GHZ测试的配置如何，每个应用容器似乎都可以路由约300 RPS。作为参考，我们尝试了各种--concurrency和--connection设置组合进行测试。这个约300 RPS低于我们从应用程序获得的预期，因此需要更多的POD才能提供所需的吞吐量。
在这种情况下，我们真的很想了解物理连接（gRPC / HTTP2）设置的详细信息，从ELB到应用程序/使节的所有方式，以及正在完成的负载平衡的详细信息。当同一个客户端GHZ例如打开多个连接（通过--connection选项指定）时，这种情况尤其令人感兴趣。我们已经查看了Kiali，但它没有为我们提供适当的可视性。
问题：
谢谢。
答案 0 :(得分：0)
1。我们如何获得从入口网关到Pod /代理的物理连接的可见性？
如果Kiali并未显示您真正需要什么，也许您可以尝试使用Jaeger？
Jaeger是开源的端到端分布式跟踪系统，允许用户监视复杂的分布式系统中的事务并进行故障排除。
有有关Jaeger的istio文档。
另外，Prometheus和Grafana在这里可能会有所帮助，请查看here。
2。“按请求gRPC”负载平衡如何发生？
如上所述here
默认情况下，Envoy代理使用循环模型在每个服务的负载平衡池中分配流量，该请求将请求依次发送到每个池成员，一旦每个服务实例收到请求，便返回池的顶部
如果您不想更改默认的轮询模型，则可以使用Destination Rule。通过目标规则，您可以在调用整个目标服务或特定服务子集时自定义Envoy的流量策略，例如首选的负载平衡模型，TLS安全模式或断路器设置。
有一个有关documentation的信息。
有关特使here中的负载平衡的更多信息。
3。可能存在哪些选项来优化此设置中涉及的各个组件？
我不确定istio组件中是否有任何要优化的东西，也许是Destination Rule中的一些自定义配置？
其他资源：