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

[nixum]

环境：使用的是 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 都搜过，好像没看到有人遇到这种场景，特地请教下各位大佬。

[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，通过不同的端口来区分请求的协议，但是这样做行不通