Kubernetes gRPC负载均衡分析

本文主要讲解“Kubernetes gRPC负载均衡分析”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“Kubernetes gRPC负载均衡分析”！

安装环境依赖

docker-desktop=4.1.1

kubernetes=1.21.5

go=1.17

protobuf=3.17.3

istioctl=1.11.4

下载Docker Desktop并启动内置的Kubernetes集群。

#安装Gobrewinstallgo #安装Protobufbrewinstallprotobuf #安装Istiobrewinstallistioctl

kubectconfiguse-contextdocker-desktop

github.com/jxlwqq/grpc-lb istioctlinstall-y

项目地址

拉码：

gitnegit @ github.com : jxlwqq/grpc-lb . gitdgrpc-lb

Makefile 介绍

命令显示make init基于proto文件安装proto-gen-go和proto-gen-grp make协议。生成*_pb.go和* _ grpc . Pb . go make docker-构建docker映像make kube-在集群中部署服务make kube-删除删除服务make Istio-将特定逻辑注入Istio sidecar，请检查Makefile文件。

00-1010所谓四层是基于IP端口的负载均衡，七层是基于URL等应用层信息的负载均衡。Kubernetes内置的Service负载均衡基于iptables/ipvs，只支持L4。换句话说，该服务支持HTTP/1.1协议，而不是HTTP/2协议。

特使(Istio)更通用，支持所有HTTP/2功能，作为gRPC请求和响应的路由和负载平衡的底层。

00-1010这个项目分别测试了Service和特使(Istio)对HTTP/RPC负载均衡的支持。

Cmd/server/main.go:服务器同时提供HTTP和RPC服务。响应数据是服务器容器所在的Pod名称(基于Downward API)。

cmd/client-HTTP/main . go : HTTP client通过HTTP，循环调用服务器接口并打印返回值。

cmd/client-grpc/main . go : grpc客户端，通过rpc模式，循环远程调用服务器方法并打印返回值。

L4 vs L7 负载均衡

"header-link octicon octicon-link">测试原理

服务端 server 在 Kubernetes 集群中以 Deployment 的方式部署 3 个副本，3 个副本的 Pod 名称各不相同，而 client-http 和 client-grpc 则会每秒调用一次服务端，并打印返回值。如果返回值中，三个 Pod 的名称都存在，则表明正在进行有效的负载均衡，否则，则表明未进行有效的负载均衡。

测试 Service

构建镜像：

make docker-build # 构建镜像（构建好的镜像，不 push 到远程仓库中）

查看镜像：

docker images ls

返回：

REPOSITORY            TAG       IMAGE ID       CREATED          SIZE
grpc-lb/client-grpc   latest    95d32ead8d9b   12 seconds ago   16.6MB
grpc-lb/client-http   latest    dbf0341206f6   22 seconds ago   11.5MB
grpc-lb/server        latest    1ef346785b2a   29 seconds ago   18.2MB

部署到集群中：

make kube-deploy  # 在集群中部署服务

查看 Pod：

kubectl get pods

返回：

NAME                           READY   STATUS    RESTARTS   AGE
client-grpc-6c565594f4-tdf75   1/1     Running   0          2m48s
client-http-55d95c744d-f7nx4   1/1     Running   0          2m49s
server-7c4bfd74d-29c69         1/1     Running   0          2m51s
server-7c4bfd74d-4btvw         1/1     Running   0          2m51s
server-7c4bfd74d-fk8zf         1/1     Running   0          2m51s

查看 client-http Pod 的日志：

export CLIENT_HTTP_POD=$(kubectl get pod -l app=client-http -o jsonpath={.items..metadata.name})kubectl logs "${CLIENT_HTTP_POD}"

返回：

#1: server-7c4bfd74d-4btvw#2: server-7c4bfd74d-4btvw#3: server-7c4bfd74d-29c69#4: server-7c4bfd74d-fk8zf#5: server-7c4bfd74d-fk8zf#6: server-7c4bfd74d-29c69#7: server-7c4bfd74d-fk8zf#8: server-7c4bfd74d-4btvw#9: server-7c4bfd74d-fk8zf

查看 client-grpc Pod 的日志：

export CLIENT_GRPC_POD=$(kubectl get pod -l app=client-grpc -o jsonpath={.items..metadata.name})kubectl logs "${CLIENT_GRPC_POD}"

返回：

#1: server-7c4bfd74d-fk8zf#2: server-7c4bfd74d-fk8zf#3: server-7c4bfd74d-fk8zf#4: server-7c4bfd74d-fk8zf#5: server-7c4bfd74d-fk8zf#6: server-7c4bfd74d-fk8zf#7: server-7c4bfd74d-fk8zf#8: server-7c4bfd74d-fk8zf#9: server-7c4bfd74d-fk8zf

可以看出，HTTP 请求在进行有效负载，而 RPC 请求在进行无效负载。

测试 Envoy(Istio)

我们在集群中已经部署了一个 Istio，但是没有设置自动注入的命令空间，所以我们在这里进行手动注入。

手动注入：

make istio-inject # 注入 Istio 边车

查看 Pod：

kubectl get pods

返回：

NAME                           READY   STATUS    RESTARTS   AGE
client-grpc-7864f57779-f6blx   2/2     Running   0          17s
client-http-f8964854c-jclkd    2/2     Running   0          21s
server-7846bd6bb4-bcfws        2/2     Running   0          27s
server-7846bd6bb4-fv29s        2/2     Running   0          40s
server-7846bd6bb4-hzqj6        2/2     Running   0          34s

查看 client-http Pod 的日志：

export CLIENT_HTTP_POD=$(kubectl get pod -l app=client-http -o jsonpath={.items..metadata.name})kubectl logs "${CLIENT_HTTP_POD}"

返回：

#1: server-7846bd6bb4-hzqj6#2: server-7846bd6bb4-fv29s#3: server-7846bd6bb4-hzqj6#4: server-7846bd6bb4-hzqj6#5: server-7846bd6bb4-hzqj6#6: server-7846bd6bb4-hzqj6#7: server-7846bd6bb4-hzqj6#8: server-7846bd6bb4-bcfws#9: server-7846bd6bb4-fv29s

查看 client-grpc Pod 的日志：

export CLIENT_GRPC_POD=$(kubectl get pod -l app=client-grpc -o jsonpath={.items..metadata.name})kubectl logs "${CLIENT_GRPC_POD}"

返回：

#1: server-7846bd6bb4-fv29s#2: server-7846bd6bb4-hzqj6#3: server-7846bd6bb4-fv29s#4: server-7846bd6bb4-bcfws#5: server-7846bd6bb4-fv29s#6: server-7846bd6bb4-hzqj6#7: server-7846bd6bb4-fv29s#8: server-7846bd6bb4-bcfws#9: server-7846bd6bb4-fv29s

可以看出，HTTP 请求 和 RPC 请求均在进行有效负载。

清理

make kube-delete
istioctl experimental uninstall --purge

到此，相信大家对“Kubernetes gRPC负载均衡分析”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！