在 Kubernetes 集群中 gRPC 的负载均衡

微信扫一扫,分享到朋友圈

在 Kubernetes 集群中 gRPC 的负载均衡

很多人觉得,在Kubernetes中不是只要用 Service就可以做负载均衡了吗?SVC确实有负载均衡的作用。它是由Kube-proxy提供,但是由于Grpc的特性没有办法让它很好的处理负载均衡。

SVC负载调度原理

在k8s的文档中阐述了kube-proxy的特点:

The kube proxy:
runs on each node #运行在每个节点
proxies UDP, TCP and SCTP #可以代理UDP、TCP、SCTP协议
does not understand HTTP #但是不能识别HTTP协议
provides load balancing #提供负载均衡
is just used to reach services #只用于到达服务

proxies UDP, TCP and SCTP #可以代理UDP、TCP、SCTP协议
does not understand HTTP #但是不能识别HTTP协议
provides load balancing #提供负载均衡
is just used to reach services #只用于到达服务

其中阐述了kube-proxy的iptbles代理,是不能支持应用层协议识别的。所以存在一个消费者与生产者之间过载复用一条tcp链接的情况,导致后端pod副本的应用载荷不一致。

下面是查看svc的负载均衡实现

service 的集群ip实现负载均衡

创建service后,kubernetes会在kube-proxy里面设置iptables相应规则,从api-server获取到后端pod的ip以及端口情况。生产相应转发规则

当目标地址为service的地址10.97.211.12/32和目标端口为8000时,跳转到KUBE-SVC-EHPSUHUW2JIVMPQD链

-A KUBE-SERVICES -d 10.97.211.12/32 -p tcp -m comment
--comment "default/backend:grpc cluster IP" -m tcp --dport 8000 \
-j KUBE-SVC-EHPSUHUW2JIVMPQD

链KUBE-SVC-EHPSUHUW2JIVMPQD为3条规则,副本数是3

30.333%的几率去KUBE-SEP-MPFDKKCFY2PBGU4S链(pod1 的ip)
-A KUBE-SVC-EHPSUHUW2JIVMPQD -m statistic --mode random --probability 0.33332999982 \
-j KUBE-SEP-MPFDKKCFY2PBGU4S
50%的几率去KUBE-SEP-LMG22MVGXQA364F6链(pod2的ip地址)
-A KUBE-SVC-EHPSUHUW2JIVMPQD -m statistic --mode random --probability 0.50000000000 \
-j KUBE-SEP-LMG22MVGXQA364F6
其余的全部走KUBE-SEP-EX64MF3TTLO7J5EC链(pod3的ip地址)
-A KUBE-SVC-EHPSUHUW2JIVMPQD -j KUBE-SEP-EX64MF3TTLO7J5EC

pod3的ip地址

-A KUBE-SEP-EX64MF3TTLO7J5EC -s 10.80.167.226/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-EX64MF3TTLO7J5EC -p tcp -m tcp -j DNAT --to-destination 10.80.167.226:8000

pod1的ip地址

-A KUBE-SEP-MPFDKKCFY2PBGU4S -s 10.80.128.247/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-MPFDKKCFY2PBGU4S -p tcp -m tcp -j DNAT --to-destination 10.80.128.247:8000

pod2的ip地址

-A KUBE-SEP-LMG22MVGXQA364F6 -s 10.80.153.167/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-LMG22MVGXQA364F6 -p tcp -m tcp -j DNAT --to-destination 10.80.153.167:8000

所以得到:

pod3:10.80.167.226
pod2:10.80.128.247
pod1:10.80.153.167

这些ip和上面的comment信息,均来自apiserver,apiserver最终是在etcd里面存储并及时更新并管理这些对象。

所以在GRPC的技术棧中,生产者和消费者之间的互相调用,并达到真正的负载均衡的目的。使用其他方法进行,这里介绍两种方法。

使用无头服务

Headless Service的负载均衡,是通过内部coredns进行dns解析pod所有地址列表进行的。

kind: Service
apiVersion: v1
metadata:
name: backendh
spec:
selector:
app: backend #对应后端生产者或者消费者
ports:
- port: 8000
protocol: TCP
targetPort: 8000
clusterIP: None

在grpc的生产者
者消费者之间的通信,通过在发起方预埋变量名方式获取dns解析后向具体服务进行发起请求。

使用 istio 服务网格

1.在集群中部署好istio基础设施

2.编排VirtualService和DestinationRule CRD

因为是内部互相调用,并不需要Gateway。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
spec:
hosts:
- backend
http:
- route:
- destination:
host: backend
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: backend
spec:
host: backend
trafficPolicy:
loadBalancer:
simple: RANDOM

NASA宣布SpaceX国际空间站新任务延期至10月31日

上一篇

[图]国际空间站空气泄漏点已基本锁定 NASA正进一步排查

下一篇

你也可能喜欢

在 Kubernetes 集群中 gRPC 的负载均衡

长按储存图像,分享给朋友