istio 问题请教，为啥不能通过一个 istio-ingressgateway pod + 多个 service (LB)对外提供服务？

資深大佬 : nixum 5

环境：使用的是 AWS 的 EKS 做集群管理，安装的 Kubernetes 1.8 和 istio 1.8

场景：想要部署两个 LB，分别对外网和对 VPC 内部的请求做控制。对外网使用 ALB 提供 HTTP 的访问，对 VPC 内部使用 NLB 提供 gRpc 访问。

一开始的处理方式：因为之前已经通过 istio + ALB 的方式对外提供了 HTTP 访问了，就想着在原来的 istio-ingressgateway pod 的基础上再开一个新端口（用于 gRpc 对外通信用），然后再部署一个新的 istio-ingressgateway service(暂且叫 internal svc)，再通过 NLB 对外暴露 gRpc 访问，

即一个 istio-ingressgateway pod 被两个不同的 istio-ingressgateway service 所 selected 。

遇到的问题：业务服务的 Gateway 、VirtualService 、DestinationRule 都是针对这个 internal svc 做的配置，处理请求的端口也和另一个 service 不一样，然后发现这个 internal svc 可以处理 HTTP 请求，但是处理不了 gRPC 请求。查过 envoy 的日志，发现 gRpc 请求都进不来。

解决方案：部署一个新的 istio-ingressgateway pod(暂且叫 internal pod)，然后把之前 internal svc 和相关业务服务的配置都指向这个新的 internal pod 后，端口什么的也没改，就能处理 gRPC 请求了。

疑惑的点：在同一个 istio-ingressgateway pod 上套的两个不同 istio service，使用两个不同的 LB 对外暴露，对使用 istio-ingressgateway pod 的端口都做了区分，按理说应该是没什么影响才对，但是却无法处理这两种协议的请求，但是当分别使用两套 istio pod + service 就可以了

google 和 StackOverflow 都搜过，好像没看到有人遇到这种场景，特地请教下各位大佬。

大佬有話說 (8)

資深大佬 : MarsBar

k8s 不太懂但是我想说 grpc 有专门的 grpc lb 不要用 nlb..

主資深大佬 : nixum

@MarsBar 为啥，可是 AWS 总共就三种 LB 可以选，ALB 又是最近才支持 gRPC 的，感觉选 NLB 也没事吧

主資深大佬 : nixum

帖子要沉了 🙁 是不是字数太多大家都不愿意看呀。难受

資深大佬 : MarsBar

@nixum
简单来讲 NLB/ALB 都不能完全利用 http2 的特性。。就失去了 grpc 的大部分意义
可以看下这个我朋友公司写的一个 blog 作者很强
https://rokt.com/engineering_blog/learnings-grpc-aws/

資深大佬 : MarsBar

为了回你的帖子我还专门验证了下手机号。。。

資深大佬 : FakNoCNName

先不说你遇到的问题，只看你现在的应用场景，为什么不加一个 vs 指定 mesh 呢，内部外部使用不同的 vs 控制可以做到这一点。

主資深大佬 : nixum

@MarsBar 谢大佬了，这篇文章之前有搜到过了，不过没怎么看，=有空的时候再看看。因为业务方的服务不是部署在我的集群里的，所以只能通过 LB 来暴露了，利用不到也没办法了。

主資深大佬 : nixum

@FakNoCNName 目前确实是通过两套不同的 Gateway 和 VirtualService 来控制 http 和 gRpc 的请求路由的。
疑惑的点是我用了两套不同的 Gateway 、VirtualService 、istio-ingressgateway svc，但是都 select 同一个 istio-ingressgateway pod，通过不同的端口来区分请求的协议，但是这样做行不通