K8s中gRpc通信负载均衡失效
上篇文章在做 整合K8s+SpringCloudK8s+SpringBoot+gRpc 时，发现K8s中使用gRpc通信，负载均衡功能失效
查了下gRpc的最佳实践，找到这里
Load balancing
Some load balancers don't work effectively with gRPC. L4 (transport) load balancers operate at a connection level, by distributing TCP connections across endpoints. This approach works well for loading balancing API calls made with HTTP/1.1. Concurrent calls made with HTTP/1.1 are sent on different connections, allowing calls to be load balanced across endpoints.
Because L4 load balancers operate at a connection level, they don't work well with gRPC. gRPC uses HTTP/2, which multiplexes multiple calls on a single TCP connection. All gRPC calls over that connection go to one endpoint.
There are two options to effectively load balance gRPC:
Client-side load balancing
L7 (application) proxy load balancing
Note
Only gRPC calls can be load balanced between endpoints. Once a streaming gRPC call is established, all messages sent over the stream go to one endpoint.
Client-side load balancing
With client-side load balancing, the client knows about endpoints. For each gRPC call, it selects a different endpoint to send the call to. Client-side load balancing is a good choice when latency is important. There's no proxy between the client and the service, so the call is sent to the service directly. The downside to client-side load balancing is that each client must keep track of the available endpoints that it should use.
Lookaside client load balancing is a technique where load balancing state is stored in a central location. Clients periodically query the central location for information to use when making load balancing decisions.
For more information, see gRPC client-side load balancing.
Proxy load balancing
An L7 (application) proxy works at a higher level than an L4 (transport) proxy. L7 proxies understand HTTP/2, and are able to distribute gRPC calls multiplexed to the proxy on one HTTP/2 connection across multiple endpoints. Using a proxy is simpler than client-side load balancing, but can add extra latency to gRPC calls.
There are many L7 proxies available. Some options are:
Envoy - A popular open source proxy.
Linkerd - Service mesh for Kubernetes.
YARP: Yet Another Reverse Proxy - An open source proxy written in .NET.
上面也给出了解决方案，我们采用第二种 Linkerd 来做，这是个Service Mesh的一个实现，类似于Istio，但要比Istio更轻量级，我们这里只是选择一个代理而已，之后可能会集成Trace和监控的功能，所以功能上不用太丰富，而是要简单轻量，还要快，毕竟是代理嘛。
一、安装Linkerd
https://linkerd.io/2.12/getting-started/
安装完成之后会自动打开 dashboard
二、把应用交给Linkerd 托管
kubectl get deploy service-consumer -n service-k8s-demo -o yaml \| linkerd inject - \| kubectl apply -f -kubectl get deploy service-provider -n service-k8s-demo -o yaml \| linkerd inject - \| kubectl apply -f -
三、我这里有两个服务 service-consumer 和 service-provider，每个服务都有3个副本，再测试下负载均衡，发现已经生效了。
