Analysieren des Kubernetes gRPC-Lastausgleichs (L4 vs. L7)

Dieser Artikel wird von der go-Sprachetutorial-Kolumne zur Einführung des gRPC-Lastausgleichs in Kubernetes eingeführt. Ich hoffe, er wird Freunden in Not hilfreich sein!

                                                                                                               

Abhängigkeiten der Installationsumgebung

• docker-desktop >= 4.1.1
• kubernetes >= 1.21.5
• go >= 1.17
• protobuf >= 3.17.3
ist ioctl >= 1.11.4

Laden Sie Docker Desktop herunter, installieren Sie es und starten Sie den integrierten Kubernetes-Cluster.

# 安装 Gobrew install go# 安装 Protobufbrew install protobuf# 安装 Istiobrew install istioctl
kubectl config use-context docker-desktop
istioctl install -y

Projektadresse

github.com/jxlwqq/grpc-lb

Pull-Code:

git clone git@github.com:jxlwqq/grpc-lb.gitcd grpc-lb

Makefile-Einführung

BefehlAnweisungen make init make protoc

make init	安装 protoc-gen-go 和 protoc-gen-grpc
make protoc	基于 proto 文件，生成 *_pb.go 和 *_grpc.pb.go
make docker-build	构建 docker 镜像
make kube-deploy	在集群中部署服务
make kube-delete	删除服务
make istio-injectProtoc-gen-go und protoc-gen-grpc installieren

Generieren Sie auf der Grundlage der Proto-Datei *_pb.go und *_grpc.pb. Gehen Sie

make docker-build

Erstellen Sie das Docker-Image

make kube-deploy

Stellen Sie den Dienst im Cluster bereit

make kube-delete

• Delete service
• make istio-inject

Inject Istio sidecar

Für spezifische Logik sehen Sie sich bitte das Makefile an.

L4 vs. L7-Lastausgleich

Die sogenannte Schicht vier ist ein Lastausgleich basierend auf IP + Port, während Schicht sieben ein Lastausgleich basierend auf Anwendungsschichtinformationen wie der URL ist; basierend auf iptables/ipvs. Nur L4 wird unterstützt. Mit anderen Worten: Der Dienst unterstützt das HTTP/1.1-Protokoll, aber nicht das HTTP/2-Protokoll.

Envoy (Istio) ist vielseitiger und unterstützt alle von gRPC angeforderten und beantworteten HTTP/2-Funktionen als zugrunde liegendes Routing und Lastausgleich.

Projektarchitektur

Dieses Projekt testet die Unterstützung von Service und Envoy (Istio) für den HTTP/RPC-Lastausgleich.

cmd/server/main.go: Server, der sowohl HTTP- als auch RPC-Dienste bereitstellt. Die Antwortdaten sind der Pod-Name, in dem sich der Servercontainer befindet (basierend auf der Downward-API).

cmd/client-http/main.go: HTTP-Client ruft über die HTTP-Methode zyklisch die Serverschnittstelle auf und gibt den Rückgabewert aus.

cmd/client-grpc/main.go: Der gRPC-Client ruft über RPC remote die Servermethode in einer Schleife auf und gibt den Rückgabewert aus.

Testprinzip

Der Server stellt 3 Kopien im Kubernetes-Cluster in Form einer Bereitstellung bereit. Die Pod-Namen der 3 Kopien sind unterschiedlich, und client-http und client-grpc rufen den Dienst einmal pro Sekunde auf. Terminal aufrufen und den Rückgabewert ausdrucken. Wenn alle drei Pod-Namen im Rückgabewert vorhanden sind, bedeutet dies, dass ein effektiver Lastausgleich durchgeführt wird, andernfalls bedeutet dies, dass kein effektiver Lastausgleich durchgeführt wird.

Testen Sie den Dienst

Erstellen Sie das Bild:

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

Anzeigen Sie das Bild:

docker images ls

Zurück:

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

Bereitstellen im Cluster:

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

Anzeigen des Pods:

kubectl get pods

Zurück:

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

Sehen Sie sich das an client-http Pod-Protokoll:

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

Rückgabe:

#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

Sehen Sie sich das Protokoll des client-grpc-Pods an:

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

Rückgabe:

#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

🎜Es ist ersichtlich, dass die HTTP-Anfrage Nutzlast trägt, während die RPC-Anfrage ungültig ist laden. 🎜🎜🎜🎜Testen von Envoy (Istio)🎜🎜Wir haben Istio im Cluster bereitgestellt, aber es gibt keinen Befehlsraum für die automatische Injektion, daher führen wir hier eine manuelle Injektion durch. 🎜🎜Manuelle Injektion: 🎜

make istio-inject # 注入 Istio 边车

🎜Pod anzeigen: 🎜

kubectl get pods

🎜Rückgabe: 🎜

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-Protokoll anzeigen: 🎜

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

🎜Rückgabe: 🎜

#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-Protokoll anzeigen: 🎜

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

🎜Rückkehr: 🎜

#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

🎜As Wie ersichtlich ist, tragen sowohl HTTP-Anfragen als auch RPC-Anfragen Nutzlasten. 🎜🎜🎜🎜Aufräumen🎜

make kube-delete
istioctl experimental uninstall --purge

Das obige ist der detaillierte Inhalt vonAnalysieren des Kubernetes gRPC-Lastausgleichs (L4 vs. L7). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!