环境:使用的是 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 都搜过,好像没看到有人遇到这种场景,特地请教下各位大佬。
1
MarsBar 2021-04-07 08:27:26 +08:00
k8s 不太懂 但是我想说 grpc 有专门的 grpc lb 不要用 nlb..
|
2
nixum OP @MarsBar 为啥,可是 AWS 总共就三种 LB 可以选,ALB 又是最近才支持 gRPC 的,感觉选 NLB 也没事吧
|
3
nixum OP 帖子要沉了 :( 是不是字数太多大家都不愿意看呀。难受
|
4
MarsBar 2021-04-08 09:11:28 +08:00
@nixum
简单来讲 NLB/ALB 都不能完全利用 http2 的特性。。 就失去了 grpc 的大部分意义 可以看下这个 我朋友公司写的一个 blog 作者很强 https://rokt.com/engineering_blog/learnings-grpc-aws/ |
5
MarsBar 2021-04-08 09:11:47 +08:00
为了回你的帖子我还专门验证了下手机号。。。
|
6
FakNoCNName 2021-04-08 09:55:41 +08:00
先不说你遇到的问题,只看你现在的应用场景,为什么不加一个 vs 指定 mesh 呢,内部外部使用不同的 vs 控制可以做到这一点。
|
7
nixum OP @MarsBar 谢大佬了,这篇文章之前有搜到过了,不过没怎么看,=有空的时候再看看。因为业务方的服务不是部署在我的集群里的,所以只能通过 LB 来暴露了,利用不到也没办法了。
|
8
nixum OP @FakNoCNName 目前确实是通过两套不同的 Gateway 和 VirtualService 来控制 http 和 gRpc 的请求路由的。
疑惑的点是我用了两套不同的 Gateway 、VirtualService 、istio-ingressgateway svc,但是都 select 同一个 istio-ingressgateway pod,通过不同的端口来区分请求的协议,但是这样做行不通 |