我们在集群中部署了一个gRPC应用程序(版本1.17.6(，并安装了Istio(版本1.6.2(。集群将istio-ingressgateway设置为边缘LB，SSL终止。istio-ingressgateway在直通模式下由AWS ELB(经典LB(引导。该设置功能齐全，总体而言，交通流量符合预期。所以设置看起来像：
ELB＝>istio-ingressgateway=>虚拟服务=>应用程序服务=>[特使吊舱]
我们正在使用GHZ(GHZ.sh(对此设置运行负载测试，该测试在应用程序集群外部运行。从我们运行的测试中，我们观察到，无论GHZ测试的配置如何，每个应用程序容器似乎都有大约300个RPS路由到它。作为参考，我们尝试了测试的各种并发和连接设置组合。这个约300 RPS低于我们对应用程序的期望，因此需要更多的POD来提供所需的吞吐量。
在这种情况下，我们非常有兴趣了解物理连接(gRPC/HTTP2(设置的细节，从ELB到应用程序/特使，以及正在进行的负载平衡的细节。特别令人感兴趣的是，当同一客户端(例如GHZ(打开多个连接(通过--connection选项指定(时的情况。我们已经看过Kiali，但它并没有给我们适当的可见性。
问题：
- 我们如何了解从入口网关到pod/代理的物理连接
- "每请求gRPC"负载平衡是如何实现的
- 可能存在哪些选项来优化此设置中涉及的各种组件
谢谢。
1.我们如何才能了解从入口网关到pod/代理的物理连接？
如果Kiali没有展示出你到底需要什么，也许你可以试试Jaeger？
Jaeger是一个开源的端到端分布式跟踪系统，允许用户在复杂的分布式系统中监控和排除事务。
有关于Jaeger的istio文档。
此外，普罗米修斯和格拉法纳在这里可能会有所帮助，请看这里。
2."每请求gRPC"负载平衡是如何实现的？
如前所述
默认情况下，Envoy代理使用循环模型在每个服务的负载平衡池中分配流量，在循环模型中，请求依次发送到每个池成员，一旦每个服务实例收到请求，就会返回到池的顶部。
如果不想更改默认的循环模型，可以使用Destination Rule。目标规则允许您在调用整个目标服务或特定服务子集时自定义Envoy的流量策略，例如您的首选负载平衡模型、TLS安全模式或断路器设置。
有istio的相关文档。
有关特使中负载平衡的更多信息，请点击此处。
3.可能存在哪些选项来优化此设置中涉及的各种组件？
我不确定istio组件中是否有什么需要优化的地方，也许是Destination Rule中的一些自定义配置？
其他资源：
- itnext.io
- medium.com
- programmaticthings.com