10.《Envoyクラスターネットワークトラフィック管理を行うコントロールプレーン構築の方法》
- 前文この記事を読んだ後、本当に翻訳したいと思いました、なぜでしょうか？一方ではEnvoyを学び、会社の実際のプロジェクトでEnvoyを使用していますが、実際には、複数のクラスターのすべてのトラフィックを均一に制御する制御管理端末を設計しています。私はすべてのフロー制御について話しています。現在、この管理システムは社内で徐々に使用されています。そのためこの記事を翻訳する、つまりEnvoyテクノロジーを学ぶためにも、参考として、私の考え方がOKかどうかを確認し、長所を学び短所を補いたいと思いました。
- Envoy Proxyを管理し、サービスゲートウェイとして、またはサービスグリッドで使用するために、サービスエッジでのコントロールプレーンの構築をガイドします。Envoyは非常に人気のあるネットワークコンポーネントになりました。Matt Kleinが数年前にブログにて、Envoyの動的構成APIと、それがEnvoyをますます採用されている理由のひとつになっている理由について議論しました。彼はブログの投稿で、これは「統合データパネルAPI」（UDPA）であると述べました。 Envoyをコアコンポーネントとして採用している他の多くのプロジェクトでは、Envoyが標準APIを確立するだけでなく、7層のネットワークソリューションにも適用されると言っても過言ではありません。「Envoyは、クラウドネイティブアーキテクチャの下で統合されたデータプレーンになりました。」
さらに、Envoyの統合されたデータプレーンAPIにより、業界がEnvoyテクノロジファシリティに基づく構成管理のための多くの管理システムを開発したことがわかります。この記事では、Envoyのコントロールプレーンを構築するために必要なものについて詳しく説明します。この情報を使用して、組織とシナリオに最適なインフラストラクチャの種類を評価できます。これは大きなトピックであるため、著者はこれを詳細に説明する一連の記事を公開します（後ほど興味のある記事もいくつか取り上げます）。
EnvoyCon / KubeConフォーラムでは非常に多くの良い議論が行われており、ここで多くの組織が、独自のコントロールプレーンを構築する方法など、Envoyを採用した経験を共有しています。 ここに、彼らが独自のコントロールプレーンを構築することを選択した理由をいくつか示します。
- 既存のソリューションはさまざまなデータプレーン上に構築されており、すでにコントロールプレーンがあり、Envoyとの互換性が必要である。
- オープンソースインフラストラクチャなしで構築するか、他のEnvoyコントロールプレーン（VM、AWS、ECSなど）を使用する。
- Envoyの一部の機能のみを使用する必要はない。
- 独自のワークフローと作業ビューにさらに適応するには、Envoyの専用ドメインのAPIオブジェクトモデルを構成および開発する必要がある。
- オンラインで使用するが、他のコントロールプレーンが十分に成熟していない。
ただし、一部の初期のユーザーが独自のコントロールプレーンを構築したという事だけで、あなたもそのようにすべきだという理由にはなりません。
まず、昨年Envoy用に開発された多くのコントロールプレーンは非常に成熟していたため、別のコントロールプレーンの再開発を決定する前に、これらの既存のプレーンを研究する必要があります。第二に、Datawireの面々が発見し、Daniel Bryantが最近記事に公開したように、Envoyのコントロールプレーンを構築することはそれほど簡単ではありません。
私は、Enovyのコントロールプレーンを構築するためのいくつかのオープンソースプロジェクトの開発に携わっています。たとえば、Glooは機能的なゲートウェイであり、強力なKubernetesアクセスサービス、APIゲートウェイ、またはモノリシックサービスからマイクロサービスへの機能的なゲートウェイとして使用できます。GlooにはEnvoyのコントロールプレーンがあり、コントロールプレーンの要件に従って設計を抽象化し、プラグイン管理とスケーラビリティ管理を実現する方法を、私のシリーズ記事の例として説明します。istioやHeptio Contourなど、参照可能な他のコントロールプレーンも、私のシリーズ記事の良い例です。自分でコントロールプレーンを開発することが確実であれば、これらに加えて、他の既存のコントロールプレーンを参照することもできます。
このシリーズ記事では、次の重要なポイントに焦点を当てます。
- メカニズムを使用して、Envoyのルーティング、サービス検出、およびその他の構成を動的に更新できます。
- バックエンドストレージ、サービスディスカバリAPI、セキュリティコンポーネントなど、コントロールプレーンの形成に使用されるコンポーネントを特定します。
- シーンとチームの編成に従って、カスタマイズされた領域の構成オブジェクトとAPIを最も適切な方法で確立します。
- コントロールプレーンを必要な場所に最適な方法で埋め込む方法を検討します。
- さまざまなコントロールプレーンコンポーネントを展開する方法。
- コントロールプレーンのテスト方法を検討します。この一連のディスカッションを開始するには、最初にEnvoyの動的構成APIを使用してEnvoyを実行している間にEnvoyを更新してトポロジとデプロイメントの変更を処理する方法を確認します。
Envoyを動的に構成するEnvoyのxDS API
Envoyでコントロールプレーンを構築するための主な便利なサポートは、そのデータプレーンAPIです。データプレーンAPIを使用すると、Envoyの最も重要なランタイム設定を動的に構成できます。xDS APIを介したEnvoy構成は、最終的に整合性がとれるように設計されており、クラスター内のすべてのエージェントをアトミックに更新する方法はありません。コントロールプレーンに設定の更新がある場合、xDS APIを介してデータプレーンエージェントが利用できるようになり、各エージェントはこれらの設定を取得および適用するために互いに独立しています。
以下は、xDSを介してEnvoyを動的に構成できるいくつかのランタイムモデルです。
- 監視検出サービス（LDS）API-LDSは、サービス監視ポートを提供するために使用されます。
- 端末検出サービス（EDS）API-EDSはユーザーサービスを検出します。
- ルート検出サービス（RDS）API-RDSは、トラフィックルーティングの決定に使用されます。
- Cluster Discovery Service（CDS）-CDSは、過去にトラフィックをルーティングできるバックエンドサービスに使用されます。
- キー検出サービス（SDS）-SDSユーザーはキー（証明書とキー）を配布します。
これらのAPIは、Proto3のプロトコルバッファーを使用して定義されており、独自のコントロールプレーンを構築するときに参照を提供できるいくつかの関連する実装が既にあります。
- go-control-plane
- java-control-plane各xDS（LDS / EDS / RDS / CDS / SDS、総称してxDSと呼ばれます）は動的に構成可能ですが、これはすべてを動的に構成する必要があることを意味しません。 適応を組み合わせて、静的構成と動的構成を区別できます。たとえば、構成を通じてサービス検出のタイプを構成するには、ターミナルが動的であることを期待しますが、クラスターはデプロイ時にルーティング情報をすでに認識しているため、EnvoyのEndpoint Discovery Serviceを使用してクラスターの構成を静的に定義できます。どのアップストリームクラスターが配置されているかわからない場合は、クラスター検出サービスを使用して、アップストリーム検出を動的に構成できます。重要なのは、ワークフローとプロセスを構築して必要なパーツを静的に構成でき、動的なxDSサービスを使用して実行時に必要なパーツを発見できることです。さまざまなコントロールプレーンの実装がある理由の1つは、誰もが完全に動的で置き換え可能な環境を持っているわけではないことです（この環境のすべての構成は動的である必要があります）。これはほとんど不可能な事です。既存の条件と利用可能なワークフローの制約に基づいて、完全な動的構成ではなく、システムに適切なレベルの動的構成を採用する必要があります。Glooの実装では、go-control-plane実装に基づいてコントロールプレーンを構築し、xDS APIの動的構成をEnvoyに実装します。IstioおよびHeptio Contourもこの方法を使用します。このコントロールプレーンのAPIはgRPCストリーミングを使用して実装されており、実装インターフェースは残っているため、実装時にこれらのインターフェースを実装するだけで済みます。このようにして、EnvoyデータプレーンAPIを非常に効率的な方法でコントロールプレーンに統合できます。
gRPCストリーミング方式は、Envoy構成を更新する唯一の方法ではありません。 Envoyの以前のバージョンのxDS APIでは、ポーリングが、新しい構成が利用可能かどうかを検出する唯一の方法です。これも悪い方法ではなく、構成更新の結果整合性の原則に準拠していますが、ネットワークおよびコンピューティングの使用にはまだ十分に効率的ではありません。また、リソースの浪費を減らすためにポーリング構成を調整および最適化することはより困難です。
最後に、一部のEnvoy管理システム実装は、静的Envoy構成ファイルを生成し、ディスクに書き込まれたEnvoy構成ファイルを定期的に上書きしてから、Envoyプロセスのホットリスタートを実行します。非常に動的な環境（Kubernetesのように、実際には短期間のコンピューティングプラットフォームも全てカウントする場合）では、そのようなファイルの生成、配信、ホットリスタートなどの管理が非常に面倒な場合があります。Envoyは元々この方法で動作していましたが（Lyftカンパニーがこのプロジェクトを作成したケースです）、徐々に現在のxDS APIに進化しました。
