ダボでのプロキシレスメッシュの実践

著者 |王成明

1. 背景

Dubbo 3.1 のリリースにより、Dubbo はクラウド ネイティブへの道において新たな重要な一歩を踏み出しました。このバージョンでは、プロキシレス メッシュの新機能が追加されました。 Dubbo Proxyless Mesh は xDS プロトコル解析を直接実装し、Dubbo とコントロール プレーン間の直接通信を可能にすることで、トラフィック制御、サービス ガバナンス、可観測性、セキュリティなどの統合制御を実現し、サイドカー モードによってもたらされるパフォーマンスの低下や展開アーキテクチャの複雑さを回避します。 02​

2. サービスメッシュとは

サービス メッシュは、「サービス メッシュ」とも翻訳され、サービス間の通信のためのインフラストラクチャ層として機能します。 Buoyant の CEO である Willian Morgan 氏は、記事「サービス メッシュとは何か? なぜ必要なのか?」で、サービス メッシュとは何か、クラウド ネイティブ アプリケーションにサービス メッシュが必要な理由を説明しています。

William Morgan 氏は Service Mesh を次のように説明しています。

サービス メッシュは、サービス間通信を処理するための専用のインフラストラクチャ レイヤーです。最新のクラウド ネイティブ アプリケーションを構成するサービスの複雑なトポロジを通じて、リクエストを確実に配信する役割を担います。実際には、サービス メッシュは通常、アプリケーションが意識することなく、アプリケーション コードと一緒にデプロイされる軽量ネットワーク プロキシの配列として実装されます。

中国語に翻訳: サービス メッシュは、サービス間の通信を処理するインフラストラクチャ層です。最新のクラウドネイティブ アプリケーションを構成する複雑なサービス トポロジ全体でリクエストを確実に配信する役割を担います。実際には、サービス メッシュは通常、アプリケーションがプロキシの存在を認識することなく、アプリケーション コードと一緒にデプロイされる軽量ネットワーク プロキシの配列として実装されます。サービス メッシュについて話すとき、古典的なサイドカー アーキテクチャ モデルについて言及する必要があります。ビジネス コンテナの通信トラフィックを引き継ぐために、ビジネス ポッドにサイドカー コンテナを挿入します。同時に、サイドカー コンテナはグリッド プラットフォームのコントロール プレーンに接続されます。コントロール プレーンが発行するポリシーに基づいてプロキシ トラフィックを統制および管理し、元のサービス フレームワークの統制機能をサイドカー コンテナーに下げることで、基本的なフレームワーク機能を沈め、ビジネス システムから切り離します。

従来の Sidecar Mesh 展開アーキテクチャには、スムーズなアップグレード、多言語、ビジネスへの介入の少なさなど、多くの利点がありますが、次のような追加の問題も生じます。

• プロキシによって生じるパフォーマンスの低下は、複雑なトポロジを持つネットワーク呼び出しで特に顕著になります。
• トラフィック傍受によるアーキテクチャの複雑さ
• サイドカーライフサイクル管理
• 展開環境は制限されており、すべての環境が Sidecar トラフィック傍受条件を満たすわけではありません。

Sidecar Meshモデルの問題に対して、Dubboコミュニティは以前からDubboをコントロールプレーンに直接接続することを検討・検討しており、国内のオープンソースコミュニティで初めてProxyless Meshの概念を提案しました。もちろん、プロキシレスの概念は Google によって最初に提案されました。 03​

3. Dubbo プロキシレスメッシュ

Dubbo プロキシレス モードとは、Dubbo が Istiod と直接通信し、xDS プロトコルを通じてサービス検出やサービス ガバナンスなどの機能を実装することを意味します。

プロキシレス モードでは、マイクロサービスは 2.x 時代のデプロイメント アーキテクチャに戻ります。これは、Dubbo の従来のサービス ガバナンス モードと非常によく似ています。したがって、このモードは新しいものではありません。 Dubbo は最初からこのように設計されていました。そうすることで、アプリケーションのパフォーマンスが大幅に向上し、ネットワークの遅延が短縮されます。このアプローチは、元の SDK ベースのマイクロサービス モデルに応えるものだと考える人もいます。実際、Envoy の xDS API はまだ使用されていますが、アプリケーションに Sidecar プロキシを挿入する必要がなくなったため、アプリケーション パフォーマンスの低下を軽減できます。

ヒント: 対応する検出サービスとそれに対応するAPIはxDSと呼ばれます

しかし、メッシュ アーキテクチャと比較すると、Dubbo の従来のサービス ガバナンス モデルは、コントロール プレーンの統合制御を重視していません。これはまさにサービス メッシュが重視している点です。トラフィック、可観測性、証明書などの標準化された制御とガバナンスを重視しており、これはメッシュ コンセプトの高度な側面でもあります。

Dubbo プロキシレス アーキテクチャ モードでは、Dubbo プロセスはコントロール プレーンと直接通信し、Dubbo プロセスは直接通信モードを維持し続けます。プロキシレス アーキテクチャの利点は次のとおりです。

• 追加のプロキシトランジットロスがないため、パフォーマンスに敏感なアプリケーションに適しています。
• レガシーシステムのスムーズな移行に貢献
• シンプルなアーキテクチャ、簡単な操作とメンテナンスの導入
• ほぼすべての導入環境に適しています

4. サービス検出

xDS アクセスは登録センターモードで接続されます。ノード検出は、他の登録センターのサービス イントロスペクション モデルと同じです。 xDS の負荷分散およびルーティング構成は、ServiceInstance の動的ランタイム構成を通じて送信されます。構成パラメータは、Invoker の構築時に構成アドレスに渡されます。

5. 証明書管理

ゼロトラスト アーキテクチャでは、ワークロードの識別と信頼を厳密に区別する必要があり、X.509 証明書を発行することが推奨される認証方法です。 Kubernetes クラスターでは、サービスは DNS 名を介して相互にアクセスし、ネットワーク トラフィックは DNS スプーフィング、BGP/ルーティング ハイジャック、ARP スプーフィングなどによってハイジャックされる可能性があります。サービス名 (DNS 名) をサービス ID に強力に関連付けるために、Istio は X.509 証明書に配置された安全な命名メカニズムを使用します。 SPIFFE は、Istio で採用されている安全な命名仕様です。これは、クラウド ネイティブによって定義された標準化された移植可能なワークロード ID 仕様でもあります。 Secure Production Identity Framework For Everyone (SPIFFE) は、サービス間の相互 ID 認証のための一連の標準であり、主に次のものが含まれます。

• SPIFFE ID標準では、SPIFFE IDはサービスの一意の識別子であり、特定の実装ではURIリソース識別子を使用します。
• SPIFFE検証可能ID文書（SVID）標準。SPIFFE IDを暗号的に検証可能なデータ形式にエンコードします。
• SVIDの発行と取り消しのためのAPI標準（SVIDはSPIFFE IDの識別資格情報です）

SPIFFE ID は、ワークロードの一意の識別子として、spiffe://<信頼ドメイン>/<ワークロード識別子> などの URI 形式を指定します。 Istio は独自のエコシステム内では、セキュリティ名として SPIFFE ID のみを使用します。データ形式は独自に実装されており、通信形式はCNCFがサポートするxDSプロトコル仕様（証明書認証通信は具体的にはxDSのSDS）を採用しています。 Istio は、特定の形式の SPIFFE ID をセキュア名として使用し、X.509 証明書の subjectAltName 拡張に挿入します。 「trust_domain」パラメータは、Istiod 環境変数 TRUST_DOMAIN を通じて挿入され、マルチクラスター環境での対話に使用されます。​

具体的な形式は次のとおりです: spiffe://<trust_domain>/ns/<namespace>/sa/<service_account>

Dubbo Proxyless Mesh 証明書を発行するプロセスは次のとおりです。

• RSA秘密鍵を作成する
• CSR（証明書署名要求）テンプレートを作成する
• 自己署名CSRを使用して証明書を生成する
• CA 証明書と秘密鍵を保存するための Kubernetes Secret リソースを作成する (CA サービスによって処理される)

VI.ケース実践

次に、既存のプロジェクトをプロキシレス メッシュ モードで簡単に実行する例を紹介します。

1. 環境整備

• Dockerをインストールする

参考:

• minikubeをインストールする

推奨: https://kubernetes.io/zh-cn/docs/tutorials/hello-minikube/

• istioをインストールする

https://istio.io/latest/docs/setup/getting-started/

注: Istio をインストールするときは、first-party-jwt サポートを有効にする必要があります (istioctl ツールを使用してインストールするときに --set values.global.jwtPolicy=first-party-jwt パラメータを追加します)。そうしないと、クライアント認証が失敗します。

参照コマンドは次のとおりです。

 https://istio.io/downloadIstio を実行します。 sh -
 cd istio - 1.xx.x
エクスポート PATH = $PWD / bin : $PATH
 istioctl インストール--set profile=demo --set values.global.jwtPolicy=first-party-jwt -y

2. コードの準備

ここでは、公式サンプルを直接再利用します。コード アドレス: https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-xds これまでのところ、環境とコードはすべて準備完了です。 03

3. イメージを構築する

（1）Dockerを起動する

（２）minikubeを起動する

minikube はローカル K8s であるため、起動するには仮想エンジンが必要であり、ここでは docker を使用して管理します。次のコマンドで起動します

minikube スタート

dockerでminikubeを見ることができます

（３）istioの状態を確認する

（4）イメージを構築する

コードの場所をローカルで見つけ、次のコマンドを順番に実行します。

 # プロバイダーが配置されているパスを見つける
cd ./dubbo-samples-xds-provider/
 # プロバイダーイメージをビルドする
docker build -t apache / dubbo - demo : dubbo - samples - xds - provider_0 .0 .1 を実行します。 

 # 消費者が位置するパスを見つける
cd ../dubbo-samples-xds-consumer/
 # 消費者イメージの構築
docker build -t apache / dubbo - demo : dubbo - samples - xds - consumer_0 .0 .1 を実行します。 

（５）現地の画像を確認する

（6）名前空間を作成する

 # 名前空間を初期化する
kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/dubbo-samples-xds/deploy/Namespace.yml

 # 名前空間を切り替える
kubens dubbo -デモ

名前空間を作成しないと、次のエラーが表示されます。

4. コンテナをデプロイする

 # プロバイダーが配置されているパスを見つける
cd ./dubbo-samples-xds-provider/src/main/resources/k8s
 # dubbo -サンプル- xds / dubbo -サンプル- xds -プロバイダー/ src / main / resources / k8s / Deployment.yml
 # dubbo -サンプル- xds / dubbo -サンプル- xds -プロバイダー/ src / main / resources / k8s / Service.yml

 # プロバイダーのデプロイメントとサービスをデプロイする
kubectl 適用-f デプロイメント.yml
 kubectl apply -fサービス.yml 

 # 消費者が位置するパスを見つける
cd ../../../../../dubbo-samples-xds-consumer/src/main/resources/k8s
 # dubbo -サンプル- xds / dubbo -サンプル- xds -コンシューマー/ src / main / resources / k8s / Deployment.yml

 # コンシューマーのデプロイメントをデプロイする
kubectl 適用-f デプロイメント.yml

minikubeダッシュボードで、デプロイしたポッドを確認します。

5. 消費者効果を観察する

kubectl ログ xxx

結果:こんにちは、 xDS Consumer さん! ホスト: 172.17.0.5 ​
結果:こんにちは、 xDS Consumer さん! ホスト: 172.17.0.5 ​
結果:こんにちは、 xDS Consumer さん! ホスト: 172.17.0.6 ​
結果:こんにちは、 xDS Consumer さん! ホスト: 172.17.0.6 ​ 

7. まとめと展望

この記事では、主にアーキテクチャ、サービス検出、証明書管理など、Dubbo Proxyless Mesh のコアプロセスを分析します。最後に、例を通して Dubbo Proxyless の使用方法を説明します。

Dubbo 3.1 のリリースにより、Dubbo はクラウド ネイティブへの道において新たな重要な一歩を踏み出しました。今年末には、Dubbo Mesh はサービス検出機能を備えたバージョンをリリースする予定です。これにより、すべての Dubbo ユーザーは、下位​​バージョンから Mesh アーキテクチャにスムーズに移行できるようになります。ガバナンス機能を備えたバージョンは来年の春先にリリースされる予定です。ホットプラグインアップデート機能を備えたバージョンは来年末までにリリースされる予定です。 Dubbo のクラウドネイティブの旅を目の当たりにすることに興味のある学生が、コミュニティへの貢献に積極的に参加してくれることを願っています。

著者について

Ant Financial エンジニアであり、Apache Dubbo コミッターでもある Wang Chengming 氏は、RPC、サービス メッシュ、クラウド ネイティブに重点を置いています。