Kubernetes gRPC ロード バランシングの分析 (L4 と L7)

この記事は、Kubernetes での gRPC ロード バランシングを紹介する go language チュートリアル コラムで紹介されています。

                                                                                                               

#インストール環境の依存関係

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

Docker Desktop をダウンロードしてインストールし、組み込みの Kubernetes クラスター。

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

プロジェクトアドレス

github.com/jxlwqq/grpc-lb

プルコード:

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

Makefile の概要

コマンド説明#make init##proto ファイルに基づいて protoc を作成しますBuild docker imagemake kube-deployクラスターにサービスをデプロイサービスの削除Istio サイドカーの注入L4 と L7 のロード バランシング

protoc-gen-go と protoc-gen-grpc をインストールします
## 、*_pb.go と *_grpc.pb.go を生成します	#make docker-build
##make kube-delete
make istio-inject
特定のロジックについては、Makefile を確認してください。

いわゆるレイヤー 4 は IP ポートに基づくロード バランシングですが、レイヤー 7 は次のようなアプリケーション層の情報に基づくロード バランシングです。 URL、Kubernetes 組み込みのサービス負荷分散は iptables/ipvs に基づいており、L4 のみをサポートします。つまり、サービスは HTTP/1.1 プロトコルをサポートしますが、HTTP/2 プロトコルはサポートしません。

Envoy (Istio) はより汎用性が高く、基盤となるルーティングと負荷分散として gRPC によって要求および応答されるすべての HTTP/2 機能をサポートします。

プロジェクト アーキテクチャ

このプロジェクトでは、HTTP/RPC ロード バランシングのための Service と Envoy (Istio) のサポートをそれぞれテストします。

cmd/server/main.go: HTTP サービスと RPC サービスの両方を提供するサーバー。応答データは、サーバー コンテナーが配置されているポッド名です (Downward API に基づく)。 cmd/client-http/main.go: HTTP クライアントは、HTTP モードを通じてサーバー インターフェイスを周期的に呼び出し、戻り値を出力します。

cmd/client-grpc/main.go: gRPC クライアントは、RPC を通じてループ内でサーバー メソッドをリモートで呼び出し、戻り値を出力します。

• テスト原則
• サーバーは、デプロイメントの形式で Kubernetes クラスターに 3 つのコピーをデプロイします。3 つのコピーのポッド名は異なり、クライアントは-http と client-grpc は 1 秒ごとにサーバーを呼び出し、戻り値を出力します。戻り値に 3 つの Pod 名がすべて存在する場合は、効果的な負荷分散が実行されていることを示し、そうでない場合は、効果的な負荷分散が実行されていないことを示します。

テストサービス

イメージの構築:

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

Deployment クラスターに移動します:

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

ポッドを表示します:

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 ポッドのログを表示します:

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

Return :

#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}"

Return:

#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 リクエストはペイロードを伝送していることがわかります。無効な荷物を運んでいます。

Test Envoy(Istio)

Istio をクラスターにデプロイしましたが、自動インジェクション用のコマンド スペースがないため、ここでは手動インジェクションを実行します。

手動インジェクション:

make istio-inject # 注入 Istio 边车

ポッドの表示:

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

クライアント http ポッドのログの表示:

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

Return:

#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}"

Return:

#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 ロード バランシングの分析 (L4 と L7)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。