サードパーティのサービスレジストリを 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 のバージョンが進化し続けると、サービスモデルと登録関連のメカニズムが変更される可能性があり、サードパーティのサービスレジストリとの統合方法も変更される可能性があります。

参照ドキュメント