Service Meshの最もホットなプロジェクトIstioレイヤードアーキテクチャ、本当に理解していますか？

著者|王西寧アリババ上級技術専門家

「Alibaba Cloud Native」パブリックアカウントの最後にあるメッセージインタラクションに参加してください。つまり、本のギフト特典を受け取る機会があります。

この記事は、Alibaba Cloudの上級技術エキスパートであるWang Yuningが書いた「Istioサービスグリッドテクノロジーの分析と実践」の本から引用したものです。大きな開発傾向により、Istioサービスグリッドの関連知識が体系的かつ包括的に導入されました。記事のやり取りの最後にご参加いただければ幸いです。料金の支払いは弊社が行います。テクニカルマンエッセンシャルブック「Istioサービスグリッドテクノロジーの分析と実践」フリーカラー

Istioは、分散型マイクロサービスアーキテクチャに必要な基本的な運用要素と管理要素を提供するオープンソースのサービスグリッドです。組織がクラウドプラットフォームを採用するにつれて、開発者はマイクロサービスを使用して移植性のあるアーキテクチャを設計する必要があり、運用担当者はハイブリッドクラウドデプロイメントやマルチクラウドデプロイメントを含む大規模な分散アプリケーションを管理する必要があります。Istioは、マイクロサービスを保護、接続、監視するための一貫した方法を使用して、マイクロサービスデプロイメントの管理の複雑さを軽減します。

アーキテクチャ設計の観点から見ると、Istioサービスグリッドは論理的に、コントロールプレーンとデータプレーンの2つの部分に分かれています。その中で、コントロールプレーンパイロットは、エージェントを管理および構成してトラフィックをルーティングし、ミキサーを構成してポリシーを実装し、テレメトリデータを収集します。データプレーンは、サイドカーモードでデプロイされた一連のインテリジェントエージェント（エンボイ）で構成され、これらのエージェントはマイクロサービスを調整および制御できますそして、ミキサー間のすべてのネットワーク通信。

（Istioアーキテクチャ）

プロキシとして、Envoyはサービスグリッドシナリオに非常に適していますが、Envoyの価値を最大化するには、基盤となるインフラストラクチャまたはコンポーネントと適切に連携させる必要があります。Envoyはサービスメッシュのデータプレーンを構成し、Istioが提供するサポートコンポーネントがコントロールプレーンを作成します。

（パイロットおよびエンボイデータプレーン）

一方では、Envoyで、静的構成ファイルまたは一連の検出サービスを使用して、一連のサービスエージェントを構成し、実行時にリスナー、エンドポイント、およびクラスターを検出できることを確認しました。Istioは、これらのEnvoyプロキシのxDS APIをPilotに実装しました。

一方、Envoyのサービスディスカバリは、サービスレジストリを利用してサービスエンドポイントを検出します。Istio PilotはこのAPIを実装しますが、特定のサービス登録実装からEnvoyを抽象化します。IstioがKubernetesにデプロイされると、KubernetesのサービスレジストリがIstioによってサービス検出に使用されます。HashiCorpの領事のような他のレジストリも使用できます。Envoyデータプレーンは、これらの実装の詳細にまったく影響されません。

（ミキサーアーキテクチャ）

さらに、Envoyプロキシは多くのインジケーターとテレメトリデータを送信でき、これらのテレメトリデータの送信先はEnvoyの構成によって異なります。Istioは、テレメトリーレシーバーミキサーをコントロールプレーンの一部として提供し、Envoyプロキシはこのデータをミキサーに送信できます。Envoyはまた、分散追跡データを（Open Tracing APIに従って）オープン追跡エンジンに送信します。Istioは、互換性のあるオープントラッキングエンジンをサポートし、その場所にトラッキングデータを送信するようにEnvoyを構成できます。

Istioコントロールプレーンの構造

IstioのコントロールプレーンとEnvoyのデータプレーンを組み合わせて、魅力的なサービスメッシュ実装を構成します。どちらも繁栄し活気に満ちたコミュニティがあり、次世代のサービスアーキテクチャを目指しています。Istioはプラットフォームに依存せず、クロスクラウド、オンプレミス、Kubernetes、Mesosなどのさまざまな環境で実行できます。Istioは、KubernetesまたはNomad with Consulにデプロイできます。Istioは現在、Kubernetesにデプロイされたサービス、Consulに登録されたサービス、および仮想マシンにデプロイされたサービスをサポートしています。

その中でも、コントロールプレーンパーツには、パイロット、ミキサー、シタデル、ギャレーの4つのコンポーネントが含まれています。Istioアーキテクチャの写真をご覧ください。

1.パイロット

IstioのPilotコンポーネントは、トラフィックの管理に使用されます。これにより、トラフィックのフローとサービス間のAPI呼び出しを制御できます。Pilotを使用すると、トラフィックをよりよく理解して、問題が発生する前に見つけることができます。これにより、通話の信頼性が高まり、ネットワークの堅牢性が高まり、悪条件が発生した場合でも、アプリケーションを安定させることができます。Istioのパイロットを使用すると、ヒューズ、タイムアウト、再試行などのサービスレベル属性を構成し、カナリアリリース、A / Bテスト、スプリットトラフィックに基づく段階的リリースなどの一般的な継続的デプロイメントタスクを設定できます。Pilotは、Envoyエージェントにサービスディスカバリ機能を提供し、インテリジェントルーティングおよび復元機能（タイムアウト、再試行、ヒューズなど）にトラフィック管理機能を提供します。Pilotは、トラフィックの動作を制御する高度なルーティングルールをEnvoyプロキシ固有の構成に変換し、実行時にEnvoyに伝達します。さらに、Istioは、タイムアウト、タイムアウトバジェットと可変ジッターをサポートするリトライメカニズム、アップストリームサービスへの同時接続、リクエスト数の制限、ロードバランシングプールの各メンバーなど、すぐに使える強力な障害回復機能を提供します定期的なアクティブヘルスチェックとパッシブヘルスチェックを実施します。

パイロットは、プラットフォーム固有のサービスディスカバリメカニズムを抽象化し、標準形式に合成します。これは、データプレーンAPIに準拠するサイドカーで使用できます。この疎結合により、Istioを複数の環境（Kubernetes、Consul、Nomadなど）で実行しながら、トラフィック管理用の同じユーザーインターフェイスを維持できます。

2.ミキサー

IstioのMixerコンポーネントは、ポリシー制御とテレメトリ収集機能を提供し、残りのIstioを各バックエンドインフラストラクチャバックエンドの実装の詳細から分離します。Mixerは、プラットフォームに依存しないコンポーネントであり、サービスグリッドでアクセス制御と使用ポリシーを実行し、Envoyエージェントやその他のサービスからテレメトリデータを収集します。エージェントはリクエストレベルの属性を抽出し、評価のためにミキサーに送信します。

Mixerには、さまざまなホスト環境やバックエンドインフラストラクチャに接続できる柔軟なプラグインモデルが含まれており、EnvoyプロキシとIstioマネージドサービスをこれらの詳細から抽象化します。ミキサーを使用すると、グリッドとバックエンドインフラストラクチャバックエンド間のすべてのやり取りを細かく制御できます。

メモリを節約する必要があるSidecarプロキシとは異なり、Mixerは独立して実行されるため、かなりのキャッシュと出力バッファーを使用して、Sidecarの高度にスケーラブルで可用性の高いセカンダリキャッシュとして機能できます。

ミキサーは、各インスタンスに高可用性を提供するように設計されています。そのローカルキャッシュとバッファは、レイテンシを削減し、バックエンドが応答していない場合でも、バックエンドインフラストラクチャのバックエンド障害をシールドするのに役立ちます。

3.城塞

Istio Citadelのセキュリティ機能は、強力な認証、強力なポリシー、透過的なTLS暗号化、サービスとデータを保護する認証、承認、監査（AAA）ツールを提供します。Envoyは、グリッド内のサービスへのTLSを終了または開始できますトラフィック。このため、Citadelは証明書の作成、署名、ローテーションをサポートする必要があります。Istio Citadelは、サービス間のトラフィックを保護するために相互TLSを確立するために使用できるアプリケーション固有の証明書を提供します。

（Istio Citadelアーキテクチャ）

Istio Citadelを使用すると、機密データを含むサービスに、厳密に認証および承認されたクライアントからのみアクセスできるようにすることができます。Citadelは、組み込みのIDおよび資格情報管理を通じて、強力なサービスルームとエンドユーザー認証を提供します。これを使用して、サービスグリッド内の暗号化されていないトラフィックをアップグレードし、運用担当者にネットワーク制御ではなくサービス識別に基づいてポリシーを適用する機能を提供できます。Istioの構成ポリシーは、サーバー側でプラットフォーム認証を構成しますが、クライアント側ではこのポリシーを適用しませんが、サービスの認証要件を指定できます。Istioの鍵管理システムは、鍵と証明書を自動的に生成、配布、ローテーション、および取り消すことができます。

Istio RBACは、使いやすい役割ベースのセマンティクス、サービスからサービス、エンドユーザーからサービスへの承認、役割と役割のバインディングなど、Istioグリッド内のサービスに名前空間レベル、サービスレベル、メソッドレベルのアクセス制御を提供します特定の側面で柔軟なカスタム属性のサポートを提供します。

Istioは、サービスコードを変更せずに、マイクロサービスとその通信（サービス間およびエンドユーザー間のサービス通信を含む）のセキュリティを強化できます。各サービスに強力な役割ベースのIDメカニズムを提供し、クラスター間およびクラウド間の対話型操作を実現します。

4.ギャレー

Galleyは、ユーザー作成のIstio API構成を検証するために使用されます。今後、Galleyは、構成、処理、および配布コンポーネントの取得に関するIstioの最高の責任を引き継ぎます。基盤となるプラットフォーム（Kubernetesなど）からユーザー構成を取得する詳細から他のIstioコンポーネントを分離する役割があります。

全体として、Pilotを使用すると、Istioは展開が拡大するにつれてトラフィック管理を簡素化するのに役立ちます。ミキサーを使用すると、堅牢で使いやすい監視機能の助けを借りて、問題を迅速かつ効果的に検出および修復できます。Citadelを使用すると、セキュリティの負担が軽減され、開発者は他の重要なタスクに集中できます。

Istioのアーキテクチャ設計にはいくつかの重要な目標がありますが、これらの目標は、システムが大規模なトラフィックと高性能なサービス処理を処理するために重要です。

• 透明性の最大化： Istioを採用するには、O＆Mと開発者は、少ないコストでそれから真の価値を得ることができるはずです。このため、Istioはサービス間のすべてのネットワークパスに自動的に挿入されます。IstioはEnvoyプロキシを使用してトラフィックをキャプチャし、可能であれば、ネットワークレイヤーを自動的にプログラムして、デプロイされたアプリケーションコードに変更を加えたり、変更を加えたりすることなく、これらのプロキシを介してトラフィックをルーティングします。Kubernetesでは、Envoyプロキシがポッドに挿入され、iptablesルールを介してトラフィックをキャプチャします。Envoyプロキシがポッドに挿入され、ルーティングルールが変更されると、Istioはすべてのトラフィックを規制できます。この原則はパフォーマンスにも適用されます。Istioをデプロイに使用すると、運用および保守担当者は、これらの機能を提供するための追加のリソースオーバーヘッドが非常に小さいことに気付く場合があります。すべてのコンポーネントとAPIは、パフォーマンスとスケールを考慮して設計する必要があります。

• スケーラビリティ：運用および保守の担当者と開発者がIstioによって提供される機能にますます依存するようになるにつれて、システムは彼らのニーズに合わせて成長する必要があります。私たちは新しい機能を追加し続けていますが、最も必要なのは、戦略システムを拡張し、他の戦略と制御ソースを統合し、グリッド動作信号を他のシステムに伝播して分析できるようにすることです。ポリシーランタイムは、他のサービスに挿入するための標準の拡張メカニズムをサポートしています。さらに、グリッドによって生成された新しい信号に基づいて戦略を実施できるように語彙を拡張できます。

• 移植性： Istio を使用するエコシステムは、多くの点で異なります。Istioは、最小限のコストで任意のクラウドまたはローカル環境で実行できる必要があります。Istioベースのサービスを新しい環境に移行するのは簡単です。また、Istioを使用して複数の環境に同時にサービスをデプロイすることも可能です。たとえば、ハイブリッドクラウドにデプロイして、冗長な災害復旧を実現できます。

• ポリシーの一貫性：ポリシーはサービス間のAPI呼び出しに適用され、グリッドの動作を適切に制御できます。ただし、APIレベルで表現する必要がないリソースの場合、リソースに戦略を適用することも同様に重要です。たとえば、機械学習トレーニングタスクによって消費されるCPUの量に割り当てを適用する方が、このジョブを開始する呼び出しに割り当てを適用するよりも便利です。そのため、Istioは、ポリシーシステムをプロキシに置くのではなく、独自のAPIを持つ独自のサービスとして維持します。これにより、サービスを必要に応じて直接統合できます。

Istioデータプレーンの構造

サービスメッシュの概念を紹介するときは、サービスエージェントの概念と、エージェントを使用してサービスメッシュを構築する方法を説明して、マイクロサービス間のすべてのネットワーク通信を規制および制御します。Istioは、Envoyプロキシをデフォルトのデフォルトのサービスプロキシとして使用します。これらのEnvoyプロキシは、サービスメッシュに参加しているが、同じコンテナプロセスではないすべてのアプリケーションインスタンスで実行され、サービスメッシュのデータプレーンを形成します。アプリケーションが他のサービスと通信したい限り、サービスエージェントEnvoyを経由します。これは、Envoyプロキシがデータプレーンおよびサービスメッシュアーキテクチャ全体の主要コンポーネントであることを示しています。

1.特使エージェント

Envoyは、分散システムの構築時に発生するいくつかの複雑なネットワーク問題を解決するためにLyftによって最初に開発されました。2016年9月にオープンソースプロジェクトとして提供され、1年後にCloud Native Computing Foundation（CNCF）に参加しました。EnvoyはC ++言語で実装されており、高いパフォーマンスを備えています。ネットワークはアプリケーションに対して透過的である必要があり、ネットワークとアプリケーションに問題がある場合、問題の原因を簡単に特定できる必要があります。このような設計概念に基づいて、Envoyはサービス指向の7層プロキシおよび通信バスとして設計されています。

Envoyをよりよく理解するために、最初にいくつかの関連する基本的な用語を明確にする必要があります。

• アウトプロセスアーキテクチャ： Envoyは独立したプロセスです。Envoyは透過的な通信グリッドを形成します。各アプリケーションはローカルホストとの間でメッセージを送受信しますが、ネットワークトポロジを考慮する必要はありません。
• シングルプロセスマルチスレッドモデル： Envoyは、シングルプロセスマルチスレッドアーキテクチャモデルを使用します。メインスレッドは、さまざまな簡単なタスクを管理し、一部の作業サブスレッドは、監視、フィルタリング、および転送機能の実行を担当します。
• ダウンストリーム： Envoyに接続され、要求を送信して応答を受信するホストは、ダウンストリームホストと呼ばれます。つまり、ダウンストリームホストは、要求を送信するホストを表します。
• アップストリーム：ダウンストリームとは対照的に、リクエストを受信するホストはアップストリームホストと呼ばれます。
• リスナー：リスナーは、ポート、UNIXドメインソケットなどを含む名前付きのネットワークアドレスであり、ダウンストリームホストによって接続できます。Envoyは、1つ以上のリスナーをダウンストリームのホスト接続に公開します。各リスナーは、いくつかのネットワークレベル（つまり、レイヤー3またはレイヤー4）フィルターで個別に設定されます。リスナーが新しい接続を受信すると、構成されたローカルフィルターがインスタンス化され、後続のイベントの処理を開始します。一般的に言って、リスナーアーキテクチャは、速度制限、TLSクライアント認証、HTTP接続管理、MongoDB sniff？Ing、生のTCPプロキシなど、さまざまなプロキシタスクのほとんどを実行するために使用されます。
• クラスター：クラスターは、Envoyによって接続された同じロジックを持つ上流ホストのグループを指します。
• xDSプロトコル： Envoyでは、xDSプロトコルは、
  クラスター探索サービス（CDS、クラスター探索サービス）、リスナー探索サービス（LDS、リスナー探索サービス）、ルート探索サービス（RDS、ルート探索サービス）など、複数の探索サービスプロトコルを表します）、Endpoint Discovery Service（EDS、Endpoint Discovery Service）、およびKey Discovery Service（SDS、Secret Discovery Service）。

（特使代理）

Envoyプロキシには、サービス間通信に使用できる多くの機能があります。たとえば、1つ以上のリスナーをダウンストリームホスト接続に公開し、ポートを介して外部アプリケーションに公開します。ルーティングルールを定義してリスナーで送信されたトラフィックを処理し、トラフィックを送信しますターゲットクラスタなどに直接 以降の章では、Istioにおけるこれらの発見サービスの役割と機能をさらに分析します。

Envoyの用語を理解した後、Envoyがどのような役割を果たすかをできるだけ早く知りたいと思うかもしれません。

まず、Envoyはネットワークアーキテクチャの仲介者として機能するプロキシであり、セキュリティ、プライバシー保護、ポリシーの提供など、ネットワークのトラフィック管理に追加機能を追加できます。サービス間の呼び出しのシナリオでは、エージェントはサービスバックエンドのトポロジの詳細をクライアントから隠し、やり取りの複雑さを簡素化し、過負荷からバックエンドサービスを保護できます。たとえば、バックエンドサービスは実際には実行中の同一のインスタンスのセットであり、各インスタンスは特定の量の負荷を処理できます。

第2に、Envoyのクラスターは、Envoyが接続されている論理的に同一の上流ホストのセットを本質的に指します。では、クライアントはどのようにして、バックエンドサービスと対話するときに使用するインスタンスまたはIPアドレスを知るのでしょうか。Envoyはルーティングのプロキシとして機能します。サービスディスカバリ（SDS、サービスディスカバリサービス）を通じて、Envoyプロキシはクラスタ内のすべてのメンバーを検出し、アクティブなヘルスチェックを通じてクラスタメンバーのヘルスステータスを決定します。バランシング戦略は、リクエストをルーティングするクラスターメンバーを決定します。Envoyプロキシはサービスインスタンス間の負荷分散プロセスを処理しますが、クライアントは実際のデプロイメントの詳細を知る必要はありません。

2. Envoyスタートアップ構成

Envoyは現在、v1とv2の2つのバージョンのAPIを提供しています。Envoy1.5.0以降、v2 APIがあります。ユーザーがv2バージョンのAPIにスムーズに移行できるようにするため、Envoyは-v2の起動時にパラメーターを設定します-conf？ig-only。このパラメーターを使用して、Envoyがv2 APIを使用するプロトコルを明示的に指定できます。さいわい、v2 APIはv1のスーパーセットであり、v1 APIと互換性があります。Istio 1.0以降の現在のバージョンでは、v2をサポートするAPIが明確に指定されています。Envoyをサイドカープロキシとして使用するコンテナー起動コマンドを見ると、次のような同様の起動パラメーターを確認できます（パラメーター--v2-conf？Ig-onlyが指定されています）。

$ /usr/local/bin/envoy -c
/etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45
--parent-shutdown-time-s 60 --service-cluster ratings --service-node
sidecar~172.33.14.2~ratings-v1-8558d4458d-ld8x9.default~default.svc.cluster.local
--max-obj-name-len 189 --allow-unknown-fields -l warn --v2-config-only

このうち、パラメーター-cはバージョンv2に基づくブート構成ファイルのパスを示し、形式はJSONであり、YAML、Proto3などの他の形式もサポートされています。最初にバージョンv2のブート構成ファイルとして解析されます。分析が失敗した場合、[-v2-conf？Ig-only]オプションに従って、バージョンv1のJSON構成ファイルとして解析するかどうかが決定されます。他のパラメーターは次のように説明されるため、Envoyエージェントがタイムリーに開始されたときに、読者は構成情報を理解できます。

• restart-epochはウォームリスタートサイクルを表し、初回の起動ではデフォルトで0になり、各ウォームリスタート後に増やす必要があります。
• service-clusterは、Envoyが実行するローカルサービスクラスターの名前を定義します。
• service-nodeは、Envoyが実行されるローカルサービスノードの名前を定義します。
• drain-time-sは、ウォームリスタート中にEnvoyが接続をドレインする時間（秒）を示します。デフォルトは600秒（10分）です。通常、枯渇時間は--parent-shutdown-time-sオプションで設定された親プロセスのシャットダウン時間よりも短くする必要があります。
• parent-shutdown-time-sは、ウォームリスタート中にEnvoyが親プロセスをシャットダウンする前に待機する時間（秒単位）を示します。
• max-obj-name-lenは、クラスタークラスター、ルーティング構成route_conf？ig、およびリスナーの名前フィールドの最大長をバイト単位で示します。このオプションは通常、クラスター名が自動的に生成されるシナリオで使用され、通常は60文字の内部制限を超えます。デフォルトは60です。
• Envoyの起動構成ファイルは、静的構成と動的構成の2つの方法に分かれています。具体的なパフォーマンスは次のとおりです。
• 静的構成とは、すべての情報を構成ファイルに入れ、起動時に直接ロードすることです。
• 動的構成では、Envoyサーバーを提供する必要があります。Envoyサーバーは、Envoyが必要とするサービスディスカバリーインターフェイスを動的に生成するために使用されます。

3.静的および動的構成の担当者

Envoyは、JSON形式またはYAML形式の構成ファイルによって駆動されるインテリジェントエージェントです。EnvoyまたはEnvoyの構成にすでに精通しているユーザーは、Envoyの構成にもさまざまなバージョンがあることを知っているはずです。初期バージョンv1は、Envoyの起動時にEnvoyを構成する元の方法です。このバージョンは、v2バージョンのEnvoy構成をサポートするために非推奨になりました。Envoyのリファレンスドキュメント（https://www.envoyproxy.io/docs）には、v1とv2を明確に区別するドキュメントも含まれています。この記事は最新バージョンであり、Istioで使用されているものであるため、v2構成のみに焦点を当てます。

Envoyバージョンv2の構成APIはgRPCに基づいて構築されています。v2APIの重要な機能は、APIを呼び出すときにストリーミング関数を使用して、Envoyプロキシが構成を集約するのに必要な時間を短縮できることです。実際、これによりAPIのポーリングの欠点が取り除かれ、サーバーが定期的にプロキシをポーリングする代わりにEnvoyプロキシに更新をプッシュできるようになります。

Envoyのアーキテクチャでは、さまざまなタイプの構成管理方法を使用できます。配置に使用される方法は、実装者のニーズによって異なります。完全な静的構成によって単純な展開を実現でき、より複雑な展開では、より複雑な動的構成を段階的に追加できます。主に次の状況に分かれています。

• 完全静的：完全静的構成では、実装者は一連のリスナーとフィルターチェーン、クラスター、およびオプションのHTTPルーティング構成を提供します。動的ホスト検出は、DNSベースのサービスを通じてのみ検出できます。設定のリロードは、組み込みのホットリスタートメカニズムを介して実行する必要があります。
• SDS / EDSのみ：静的構成では、Envoyはこのメカニズムを介して上流クラスターのメンバーを検出できます。
• SDS / EDSおよびCDS：Envoyは、このメカニズムで使用される上流クラスターを検出できます。
• SDS / EDS、CDS、およびRDS：RDSは、実行時にHTTP接続マネージャーフィルターのルーティング構成全体を検出できます。
• SDS / EDS、CDS、RDSおよびLDS：LDSは実行時にリスナー全体を検出できます。これには、RDSにアプリケーションが埋め込まれたHTTPフィルターを含む、すべてのフィルタースタックが含まれます。

静的構成

Envoyの構成ファイルを使用して、リスナー、ルーティングルール、およびクラスターを指定できます。次の例は、非常に単純なEnvoy構成を示しています。

static_resources:
 
listeners:
 
- name: httpbin-demo
   
address:
     
socket_address: { address: 0.0.0.0, port_value: 15001 }
   
filter_chains:
   
- filters:
     
- name: envoy.http_connection_manager
       
config:
          stat_prefix: egress_http
          route_config:
            name: httpbin_local_route
            virtual_hosts:
            - name: httpbin_local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/"
}
                route:
                  auto_host_rewrite: true
                  cluster: httpbin_service
          http_filters:
          - name: envoy.router
 
clusters:
   
- name: httpbin_service
     
connect_timeout: 5s
     
type: LOGICAL_DNS
     
# Comment out the following line to test on v6 networks
     
dns_lookup_family: V4_ONLY
     
lb_policy: ROUND_ROBIN
     
hosts: [{ socket_address: { address: httpbin, port_value: 8000 }}]

このシンプルなEnvoy構成ファイルでは、ポート15001でソケットを開き、それにフィルターチェーンを接続するリスナーを宣言します。フィルターhttp_connection_managerは、Envoy構成のルーティング手順を使用し（この例にある単純なルーティング手順は、すべての仮想ホストに一致するワイルドカードです）、すべてのトラフィックをhttpbin_serviceクラスターにルーティングします。構成の最後の部分では、httpbin_serviceクラスターの接続プロパティを定義します。この例では、エンドポイントサービス検出のタイプがLOGICAL_DNSであり、上流のhttpbinサービスと通信するときの負荷分散アルゴリズムがROUND_ROBINであることを指定しています。

これは、リスナーへの着信トラフィックを作成し、すべてのトラフィックをhttpbinクラスターにルーティングするために使用される単純な構成ファイルです。また、使用する負荷分散アルゴリズムの設定と使用する接続タイムアウト構成も指定します。

どのリスナーが指定されているか、どのルーティングルールがあるか、どのクラスターにルーティングできるかなど、多くの構成が明示的に指定されていることがわかります。これは完全に静的な構成ファイルの例です。

これらのパラメーターの詳細については、Envoyのドキュメント（www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#logical-dns）を参照してください。
前のセクションで、Envoyがさまざまな設定を動的に構成できることを指摘しました。以下では、Envoyの動的構成と、Envoyが動的構成にxDS APIを使用する方法を紹介します。

動的構成

Envoyは、一連のAPIを利用して、ダウンタイムや再起動なしで構成を更新できます。Envoyは、構成を正しいディスカバリーサービスAPIにポイントする単純なブート構成ファイルのみを必要とし、残りは動的に構成されます。Envoyの動的に構成されたAPIは、一般にxDSサービスと総称され、次のものが含まれます。

• リスナー検出サービス（LDS）： Envoyがリスナー全体を照会できるようにするメカニズム。このAPIを呼び出すことにより、既知のリスナーを動的に追加、変更、または削除できます。各リスナーには一意の名前を付ける必要があります。名前を指定しない場合、EnvoyはUUIDを作成します。
• ルート検出サービス（RDS）：ルーティング構成を動的に取得するためのEnvoyのメカニズムルーティング構成には、HTTPヘッダーの変更、仮想ホスト、および各仮想ホストに含まれる個々のルーティングルールが含まれます。各HTTP接続マネージャーは、APIを介して独自のルーティング構成を個別に取得できます。RDS構成はリスナー検出サービスLDSの一部であり、LDSのサブセットです。これは、静的構成と動的構成をいつ使用するか、およびどのルートを使用するかを指定するために使用されます。
• Cluster Discovery Service（CDS）： Envoyがクラスター管理メンバーを動的に取得するために呼び出すオプションのAPI。Envoyはまた、API応答に基づいてクラスター管理を調整し、必要に応じて既知のクラスターを追加、変更、または削除します。Envoy構成で静的に定義されたクラスターは、CDS APIを介して変更または削除できません。
• エンドポイント検出サービス（EDS）： Envoyがクラスターメンバーを取得できるようにするメカニズム。これはgRPCまたはRESTJSON APIに基づいています。これはCDSのサブセットであり、クラスターメンバーはEnvoy用語でエンドポイントと呼ばれます。Envoyはクラスターごとに、検出サービスからエンドポイントを取得します。EDSは、推奨されるサービス検出メカニズムです。
• Key Discovery Service（SDS）：証明書を配布するためのAPI; SDSの最も重要な利点は、証明書管理を簡素化することです。この機能がない場合、Kubernetesデプロイメントでは、証明書をキーとして作成し、Envoyプロキシコンテナにマウントする必要があります。証明書の有効期限が切れた場合は、キーを更新し、エージェントコンテナーを再デプロイする必要があります。キー検出サービスSDSを使用して、SDSサーバーは証明書をすべてのEnvoyインスタンスにプッシュします。証明書の有効期限が切れた場合、サーバーは新しい証明書をEnvoyインスタンスにプッシュするだけでよく、Envoyは再デプロイせずに新しい証明書をすぐに使用します。
• Aggregation Discovery Service（ADS）：上記の他のAPIのすべての変更のシリアル化されたストリーム。この単一のAPIを使用して、すべての変更を順番に取得できます。ADSは実際のxDSではなく、必要に応じて収束機能を提供します複数の同時xDSアクセスの場合、ADSは1つのストリームで実行できます。

構成では、上記のサービスの1つまたはいくつかを組み合わせて使用​​できますが、すべてを使用する必要はありません。注目すべき点の1つは、EnvoyのxDS APIは最終的な整合性を前提として構築されており、正しい構成が最終的に収束することです。たとえば、Envoyは最終的に新しいルートを使用してRDS更新を取得し、CDSで更新されていないクラスターにトラフィックをルーティングします。つまり、CDSが更新されるまで、ルーティングによってルーティングエラーが発生する可能性があります。Envoyはこの問題を解決するために集約検出サービスADSを導入し、Istioは集約検出サービスADSを実装し、ADSを使用してプロキシ構成の変更を行いました。

たとえば、Envoyプロキシが動的にリスナーを検出する必要がある場合は、次の構成を使用できます。

dynamic_resources:
 
lds_config:
   
api_config_source:
     
api_type: GRPC
     
grpc_services:
       
- envoy_grpc:
            cluster_name: xds_cluster
clusters:
- name: xds_cluster
 
connect_timeout: 0.25s
 
type: STATIC
 
lb_policy: ROUND_ROBIN
 
http2_protocol_options: {}
 
hosts: [{ socket_address: { address: 127.0.0.3, port_value: 5678 }}]

上記の構成では、構成ファイルで各リスナーを明示的に構成する必要はありません。EnvoyにLDS APIを使用して、実行時に正しいリスナー構成値を見つけるように指示しました。ただし、LDS APIが配置されているクラスター（この例で定義されているクラスターxds_cluster）を明示的に構成する必要があります。

静的構成に基づいて、各ディスカバリー・サービスによって提供される情報は、より直感的に表されます。

（XDSサービス情報）

静的構成に基づいて、各ディスカバリー・サービスによって提供される情報は、より直感的に表されます。

この記事は、「Istio Service Grid Analysis and Actual Combat」からの抜粋であり、発行元の許可を得て公開されています。この本は、Alibaba CloudのシニアテクニカルエキスパートであるWang Xiningによって書かれました。Istioの基本原則と実際の開発を詳細に紹介しています。選択した多数のケースとリファレンスコードが含まれており、Istio開発をすぐに開始できます。ガートナーは、2020年にサービスグリッドがすべての主要なコンテナー管理システムの標準技術になると考えています。この本は、マイクロサービスとクラウドネイティブに興味があるすべての読者に適しています。この本を詳しく読むことをお勧めします。

パブリックアカウントメッセージの対話に参加してください。つまり、次のメリットを得る機会があります！

「Alibaba Cloud Nativeは、マイクロサービス、サーバーレス、コンテナ、サービスメッシュ、およびその他の技術分野に焦点を当て、クラウドネイティブの一般的なテクノロジートレンド、クラウドネイティブの大規模なランディングプラクティスに焦点を当て、クラウドネイティブの開発者を最もよく理解している公開番号です。」