浅谈K8S下gRPC负载均衡问题
source link: https://blog.huoding.com/2021/07/14/929
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
浅谈K8S下gRPC负载均衡问题
一般来说，在 K8S 下部署服务是很简单的事儿，但是如果部署的是一个 gRPC 服务的话，那么稍不留神就可能掉坑里，个中缘由，且听我慢慢道来。
在 K8S 下部署服务，缺省情况下会被分配一个地址（也就是 ClusterIP），客户端的请求会发送给它，然后再通过负载均衡转发给后端某个 pod：
ClusterIP
如果是 HTTP/1.1 之类的服务，那么 ClusterIP 完全没有问题；但是如果是 gRPC 服务，那么 ClusterIP 会导致负载失衡，究其原因，是因为 gRPC 是基于 HTTP/2 的，多个请求在一个 TCP 连接上多路复用，一旦 ClusterIP 和某个 pod 建立了 gRPC 连接后，因为多路复用的缘故，所以后续其它请求也都会被转发给此 pod，结果其它 pod 则完全被忽略了。
看到这里，有的读者可能会有疑问：HTTP/1.1 不是实现了基于 KeepAlive 的连接复用么？为什么 HTTP/1.1 的复用没问题，而 HTTP/2 的复用就有问题？答案是 HTTP/1.1 的 复用是串行的，当请求到达的时候，如果没有空闲连接那么就新创建一个连接，如果有空闲连接那么就可以复用，同一个时间点，连接里最多只能承载一个请求，结果是 HTTP/1.1 可以连接多个 pod；而 HTTP/2 的复用是并行的，当请求到达的时候，如果没有连接那么就创建连接，如果有连接，那么不管其是否空闲都可以复用，同一个时间点，连接里可以承载多个请求，结果是 HTTP/2 仅仅连接了一个 pod。
了解了 K8S 下 gRPC 负载均衡问题的来龙去脉，我们不难得出如下解决方案：
在 Proxy 中实现负载均衡：采用 Envoy 做代理，和每台后端服务器保持长连接，当客户端请求到达时，代理服务器依照规则转发请求给后端服务器，从而实现负载均衡。
Proxy
在 Client 中实现负载均衡：把服务部署成 headless service，这样服务就有了一个域名，然后客户端通过域名访问 gRPC 服务，DNS resolver 会通过 DNS 查询后端多个服务器地址，然后通过算法来实现负载均衡。
Client
两种方案的优缺点都很明显：Proxy 方案结构清晰，客户端不需要了解后端服务器，对架构没有侵入性，但是性能会因为存在转发而打折扣；Client 方案结构复杂，客户端需要了解后端服务器，对架构有侵入性，但是性能更好。
此条目是由老王发表在Technical分类目录的。将固定链接加入收藏夹。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK