サードパーティのサービスレジストリを Istio に統合するにはどうすればよいですか?

 この記事はWeChatの公開アカウント「趙華兵」から転載したものです。この記事を転載する場合は、趙華兵の公開アカウントにご連絡ください。

[[328847]]

目次

• Istio サービス モデル
• パイロットサービスモデルのソースコード分析
• サードパーティのサービスレジストリ統合
  • Consul 統合
  • 他のサービスレジストリとの統合
• まとめ
• 参照ドキュメント

クラウドネイティブ サービス メッシュの分野で人気の高いオープン ソース プロジェクトである Istio は、非侵入型トラフィック管理、安全な通信、サービスの可視性などのサービス ガバナンス機能を備えたマイクロサービスを提供できます。現在、ますます多くのマイクロサービス プロジェクトが、マイクロサービス インフラストラクチャを Istio に移行することを検討し始めています。

Istio は Kubernetes に強く依存しており、そのサービス検出は Kubernetes に基づいて実装されています。既存のマイクロサービス プロジェクトの多くは、まだ Kubernetes に移行されていません。あるいは、Kubernetes がデプロイメントと管理に使用されているにもかかわらず、Consul や Eureka などの他のサービス登録ソリューションや、独自に構築したサービス登録センターが引き続き使用されている場合もあります。

この場合、既存のマイクロサービス プロジェクトを Istio と最小限のコストで迅速に統合し、Istio が提供するさまざまなサービス ガバナンス機能を活用するにはどうすればよいでしょうか。この記事では、Istio サービス登録メカニズムの原理を分析し、読者の参考のために Istio をサードパーティのサービス登録センターと統合するための実現可能なソリューションをいくつか提案します。

Istio サービス モデル

まず、Istio 内のサービス モデルを見てみましょう。 Istio コントロール プレーンでは、Pilot コンポーネントがサービス メッシュ内のサービスとトラフィック ポリシーの管理を担当します。 Pilot は、サービス情報とルーティング ポリシーを xDS インターフェイスの標準データ構造に変換し、データ プレーン上の Envoy に送信します。

Pilot 自体はメッシュ内のサービス登録を担当しませんが、他のサービス レジストリと統合することでメッシュ内で管理されるサービスを取得します。さらに、Istio は、API を介してレジストリ以外の独立したサービスをメッシュに追加することもサポートしています。

図 1 Istio サービス モデル データ ソース

上の図からわかるように、Pilot で管理されるサービス データは、次の 2 つのソースから取得されます。

• サービス レジストリ: Kubernetes のサービスや Consul カタログに登録されたサービスなど、さまざまなサービス レジストリから派生します。 Istio は、特定のアダプターを介してこれらのサービス レジストリを接続し、サービス レジストリ内のプライベート サービス モデルを Istio がサポートする標準サービス モデルに変換します。
• 構成ストレージ: さまざまな構成データ ソースから派生した独立したサービスで、Istio によって定義された ServiceEntry および WorkloadEntry リソース タイプを通じて Pilot の内部サービス モデルに追加されます。

パイロットサービスモデルのソースコード分析

Pilot のサービス モデルに関係するコード モジュールを次の図に示します。

図2 パイロットサービスモデルに関連するコード構造

Pilot のエントリ関数は、pilot/cmd/pilot-discovery/main.go のメイン メソッドです。検出サーバーはメイン メソッドで作成されます。検出サーバーおよびサービス モデルには、主に次の 3 つの部分が含まれます。

• 構成コントローラ: ユーザーが作成したトラフィック管理ルールやポリシーなど、さまざまな構成データを管理するために使用されます。構成データには、サービス モデルに関連する 2 つの API オブジェクト (ServiceEntry と WorkloadEntry) があります。 Istio は現在、次の 3 種類の Config Controller をサポートしています。
  • Kubernetes: 構成データのストレージとして Kubernetes を使用します。この方法は、Kubernetes の強力な CRD メカニズムを直接利用して構成データを保存します。これはシンプルで便利であり、Istio で使用されるデフォルトの構成ストレージ ソリューションです。
  • メモリ: ファイル ディレクトリを監視し、ディレクトリ内の yaml ファイルで定義された Istio API 構成オブジェクトを読み込む、メモリ内の Config Controller 実装。この方法は主にテストに使用されます。
  • MCP: MCP (Mesh Configuration Protocol) プロトコルを通じて、1 つ以上の MCP サーバーにアクセスできます。 Pilot は、ServiceEntry および WorkloadEntry によって定義されたサービス データ、および VirtualService、DestinationRule、その他のルーティング ルールなどのその他の構成を含むグリッド構成データを MCP サーバーから取得します。 Istio には、MCP サーバーとして実装されている Galley コンポーネントがあります。 Kubernetes API サーバーから構成データを取得し、MCP プロトコルを通じて Pilot に提供します。
• サービス コントローラー: さまざまなサービス レジストリに接続し、サービス レジストリからメッシュ内で管理する必要があるサービスを同期する役割を担います。現在、Istio でサポートされているサービス レジストリは次のとおりです。
  • Kubernetes: Kubernetes レジストリに接続して、Kubernetes サービスとエンドポイントを Istio に収集します。
  • Consul: Consul カタログに接続して、Consul に登録されているサービス データを Istio に収集します。
  • 外部サービス検出: このサービス レジストリは特別です。バックエンドはサービス レジストリに接続されていません。代わりに、Config コントローラーの構成変更メッセージをリッスンし、Config コントローラーから ServiceEntry および WorkloadEntry リソースを取得し、それらを Service Registry の形式で Service コントローラーに提供します。

検出サービス: サービス モデルとコントロール プレーン構成をデータ プレーンの標準データ形式に変換し、xDS インターフェイスを介してデータ プレーン エージェントに送信します。主に以下のロジックが含まれます。

• GRPC サーバーを起動し、Envoy 側からの接続要求を受信します。
• Envoy から xDS 要求を受信し、Config Controller と Service Controller から構成とサービス情報を取得し、応答メッセージを生成して Envoy に送信します。
• Config Controller からの構成変更メッセージと Service Controller からのサービス変更メッセージをリッスンし、xDS インターフェイスを介して構成とサービスの変更内容を Envoy にプッシュします。

サードパーティのサービスレジストリ統合

Consul 統合

Istio は Kubernetes との密接な関係を考慮して、当初は Kubernetes サービス登録の統合のみに重点を置いていました。 Istio の初期バージョンには Consul と Eureka の適応コードも含まれていますが、これらのコードは基本的にプロトタイプ検証ノードにすぎず、多くの障害とパフォーマンスの問題があります。

プロジェクトでは自社開発のサービス登録用のバックエンドストレージとして Consul を使用しているため、Istio との統合時に Consul の適応性について多くのテストと調査を実施し、機能とパフォーマンス効率の面でいくつかの問題を解決しました。これらの Consul 適応の問題は解決され、Istio バージョンに統合されました。次の PR を参照してください。

• Consul カタログ #17881 から更新を取得するには、ポーリングではなく監視を使用します。
• 修正: Consul の CPU 使用率が高い (#15509) #15510
• 不要なサービス変更イベントを回避する(#11971) #12148
• ServiceMeta を使用してプロトコルやその他のサービス プロパティを伝えます #9713

これらの問題が解決された後、Consul レジストリの統合は基本的に使用可能になりました。 Consul を Pilot に接続するには、pilot-discovery 起動コマンドの次の 2 つのパラメータを使用して、レジストリ タイプと Consul の接続アドレスを指定します: --registries Consul --consulserverURL http://$consul-ip:$port。

他のサービスレジストリとの統合

1.0 では Eureka 用の適応コード フレームワークがまだ存在しますが、Istio のそれ以降のバージョンでは Eureka 適応関連のコードは完全に削除されました。ネイティブ Istio コードは、Kubernetes と Consul 以外のサービス レジストリをサポートしていません。しかし、次の 3 つの方法で Istio に統合できます。

図3 サードパーティのサービスレジストリを統合する3つの方法

上の図では、赤、緑、青を使用して、これら 3 つの異なる統合方法を識別しています。

カスタム サービス レジストリ アダプター

図 3 の赤い矢印で示されているように、サードパーティのサービス レジストリを統合するためのカスタム アダプターを作成できます。カスタム アダプターは、サードパーティのサービス レジストリからサービスとサービス インスタンスを取得し、それらを Pilot 内の標準モデルに変換して、サービス コントローラーに統合します。カスタム アダプターは、serviceregistry.Instance インターフェイスを実装する必要があります。この方法の原理は Consul Service Registry の適応と似ており、記述には Consul Service Registry の適応コードを参照できます。

このソリューションを実装するには、Pilot 内部サービス モデルと、Service Registry の適応に関連する Istio ソース コードに精通している必要があり、カスタム アダプタ コードと Pilot コードを一緒にコンパイルして、カスタマイズされた Pilotd バイナリ実行可能ファイルを生成する必要があります。このソリューションの問題点は、Istio コードと密接に結合されていることです。後続の Istio バージョンのアップグレードでは、アダプター コードの変更と再コンパイルが必要になる場合があります。

MCP サーバーのカスタマイズ

この統合方法のビジネス プロセスは、図 3 の青い矢印で示されています。このソリューションでは、カスタム MCP サーバーを作成して、サードパーティのレジストリからサービスとサービス インスタンスを取得し、それらを ServiceEntry および WorkloadEntry リソースに変換する必要があります。その後、これらのリソースは、MCP プロトコルを介して Pilot の MCP 構成コントローラーに提供されます。

このように、グローバル メッシュ オプションの configSources パラメータを通じてカスタム MCP サーバーのアドレスを設定する必要があります。現在の 1.6 Config Controller 実装では、異なるタイプの Config Controller を同時に使用できないことに注意してください。つまり、カスタム MCP サーバーを使用してサードパーティのレジストリからサービス データを取得する場合は、他のコントロール プレーンの構成を取得するために Galley も使用する必要があります。

 configソース:
  - アドレス:istio-galley.istio-system.svc:9901
  - アドレス:${your-coustom-mcp-server}:9901

バージョン 1.5 以降では、Galley の機能は Istiod に統合され、デフォルトで無効になっています。 Isito 操縦面の簡素化の傾向から判断すると、Galley は今後徐々に廃止される可能性が高く、Galley 自体の機能の安定性も疑問視されています。したがって、本番環境で Galley を有効にすることはお勧めしません。

さらに、Istio コミュニティの MCP over XDS 提案によると、コミュニティでは構成データを送信するために現在の MCP プロトコルを置き換えるために XDSv3/UDPA の使用が議論されているため、バージョン 1.7 では MCP サーバーと Pilot 間の通信メカニズムが変更される可能性があります。

ServiceEntry と WorkloadEntry を API サーバーに書き込む

この統合方法のビジネス プロセスは、図 3 の緑色の矢印で示されています。サードパーティのサービス レジストリからサービスとサービス インスタンス データを取得し、それらを Istio の ServiceEntry および WorkloadEntry リソースに変換し、K8s API サーバーのインターフェースを介して API サーバーに書き込む別のサービスを記述するだけで済みます。 Pilot の Kube Config Controller は、K8s API サーバー内の Istio 関連のリソース オブジェクトの変更を監視し、ServiceEntry と WorkloadEntry を Piolt の内部サービス モデルに変換します。

まとめ

この記事では、カスタム サービス レジストリ アダプター コード、カスタム MCP サーバー、独立したサービスを使用して ServiceEntry と WorkloadEntry を API サーバーに書き込むなど、Istio をサードパーティのサービス レジストリと統合するいくつかの方法を分析します。必要な読者は、プロジェクトの実際の状況に基づいて、どの方法を採用するかを選択できます。現時点では、1 番目と 2 番目の方法の両方に問題があるので、個人的には、まず 3 番目の方法を使用し、Istio が Galley と MCP の変換を完全に完了した後に 2 番目の方法への移行を検討することをお勧めします。

注: この記事の分析と提案は、Istio 1.6 を使用することを前提としています。 Istio のバージョンが進化し続けると、サービス モデルと登録関連のメカニズムが変更される可能性があり、サードパーティのサービス レジストリとの統合方法も変更される可能性があります。

参照ドキュメント

• Istio サービス登録プラグインの仕組み
• Istio パイロットコードの詳細
• Istioとマイクロサービスの管理
• Istio 1.6 変更点
• サードパーティのサービスレジストリをIstioと統合するための推奨方法