tldr

勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントはこちらのディレクトリ以下にあります（ライセンス：Apache License 2.0, NOTICE）。

ロードバランシング

概要

負荷分散とは

ロードバランシングは、利用可能なリソースを効果的に利用するために、単一のアップストリームクラスタ内の複数のホスト間でトラフィックを分散させる方法です。これを実現するにはさまざまな方法があるため、Envoyはいくつかの異なる負荷分散戦略を提供しています。高レベルでは、これらの戦略を2つのカテゴリに分類できます。グローバルロードバランシングと分散ロードバランシングです。

分散ロードバランシング

分散ロードバランシングとは、アップストリームホストの場所を知っていることに基づいて、Envoy自身がエンドポイントへの負荷分散方法を決定することです。

例

アクティブヘルスチェック：アップストリームホストをヘルスチェックすることにより、Envoyは優先順位と地域の重みを調整して利用できないホストを考慮することができます。
ゾーン対応ルーティング：コントロールプレーンで優先順位を明示的に設定しなくても、Envoyがより近いエンドポイントを優先するようにこれを使用することができます。
負荷分散アルゴリズム：Envoyは提供された重みを使用して選択するホストを決定するためにいくつかの異なるアルゴリズムを使用できます。

グローバルロードバランシング

グローバル負荷分散とは、ホスト間で負荷を分散させる方法を決定する単一のグローバル権限を持つことです。 Envoyの場合、これはコントロールプレーンによって行われます。コントロールプレーンは、優先度、地域の重み、エンドポイントの重み、エンドポイントの正常性などのさまざまなパラメータを指定して、個々のエンドポイントに適用される負荷を調整できます。

簡単な例は、より少ないネットワークホップを必要とするホストが優先されるようにするために、コントロールプレーンにネットワークトポロジに基づいてホストを異なる優先順位に割り当てることです。これはゾーン対応ルーティングと似ていますが、Envoyではなくコントロールプレーンによって処理されます。コントロールプレーンでそれをすることの利点はそれがゾーンを意識したルーティングの制限のいくつかを回避することです。

より複雑な設定では、リソース使用量がコントロールプレーンに報告され、現在のリソース使用量を考慮してエンドポイントまたはローカリティの重みを調整し、ビジー状態のものより新しいホストにアイドル要求をルーティングしようとします。

分散とグローバルの両方

最も洗練された展開では、両方のカテゴリの機能を利用します。例えば、グローバルロードバランシングを使用して高レベルルーティング優先順位および重みを定義することができ、分散ロードバランシングを使用してシステム内の変化に対処することができる（たとえば、アクティブヘルスチェックを使用すること）。これらを組み合わせることで、両方の長所を活用することができます。マクロレベルでトラフィックの流れを制御しながら、個々のプロキシをミクロレベルでの変更に対応させることができる、グローバルに認識される機関です。

対応ロードバランサー

フィルタがアップストリームクラスタ内のホストへの接続を取得する必要がある場合、クラスタマネージャは負荷分散ポリシーを使用してどのホストが選択されているかを判断します。ロードバランシングポリシーはプラガブルであり、設定内のアップストリームクラスタごとに指定されます。アクティブヘルスチェックポリシーがクラスタに設定されていない場合は、health_statusで特に指定されていない限り、すべてのアップストリームクラスタメンバーは正常であると見なされます。

加重ラウンドロビン

これは、利用可能な各アップストリームホストがラウンドロビン方式で選択されるという単純なポリシーです。地域内のエンドポイントに重みが割り当てられている場合は、重み付けラウンドロビンスケジュールが使用されます。重み付けされたラウンドロビンスケジュールは、効果的な重み付けを達成するためにローテーションでより頻繁に表示されます。

加重最小要求

最小要求ロードバランサは、いずれかのホストの重みが1より大きいかどうかによって異なるアルゴリズムを使用します。

すべての重み1：構成で指定されたN個のランダムに利用可能なホストを選択し（デフォルトでは2）、アクティブな要求が最も少ないホストを選択するO（1）アルゴリズム（このアプローチはOとほぼ同じです）（N）フルスキャン）。これはP2C（2つの選択肢の力）としても知られています。 P2Cロードバランサには、クラスタ内でアクティブな要求の数が最も多いホストが新しい要求を受け取らないという特性があります。それは他のすべてのホスト以下になるまで排水することが許されるでしょう。
すべてのウェイトが1ではない：クラスタ内のいずれかのホストのロードバランシングウェイトが1より大きい場合、ロードバランサはその時点でのホストの要求負荷に基づいてウェイトが動的に調整される加重ラウンドロビンスケジュールを使用するモードに移行します。（重みは現在のアクティブな要求数で割られます。たとえば、重みが2でアクティブな要求数が4のホストの場合、合成重みは2/4 = 0.5になります）。このアルゴリズムは、定常状態では良好なバランスを提供しますが、負荷の不均衡にすぐには適応しない場合があります。さらに、P2Cとは異なり、ホストは真に排水することはありませんが、時間の経過とともに要求が少なくなります。

注意

すべての重みが1ではなく、同じ（たとえば、42）である場合、Envoyは依然としてP2Cの代わりに重み付けラウンドロビンスケジュールを使用します。

リングハッシュ

リング/モジュロハッシュロードバランサは、上流ホストへの一貫したハッシュを実装しています。各ホストは、アドレスをハッシュすることによって円（「リング」）にマッピングされます。各リクエストは、リクエストのプロパティをハッシュし、リングの周りを時計回りに最も近い対応するホストを見つけることによって、ホストにルーティングされます。この手法は一般に「Ketama」ハッシュとも呼ばれ、すべてのハッシュベースのロードバランサーと同様に、ハッシュする値を指定するプロトコルルーティングが使用されている場合にのみ有効です。

各ホストはハッシュされ、その重みに比例して何度かリング上に配置されます。たとえば、ホストAのウェイトが1、ホストBのウェイトが2の場合、リング上に3つのエントリがあります。1つはホストA用、もう2つはホストB用です。これは実際には目的の2を提供しません。ただし、計算されたハッシュは偶然にも互いに非常に接近している可能性があるため、円の1分割。したがって、目的の分散をより適切に近似するには、ホストあたりのハッシュ数を増やす必要があります（たとえば、ホストAのリングに100エントリ、ホストBのリングに200エントリを挿入するなど）。ベストプラクティスは、minimum_ring_sizeとmaximum_ring_sizeを明示的に設定し、min_hashes_per_hostゲージとmax_hashes_per_hostゲージを監視して適切な分布を確保することです。適切にパーティション化されたリングでは、N個のホストのセットから1個のホストを追加または削除しても、1 / N要求にのみ影響します。

優先順位ベースのロードバランシングが使用されている場合、優先順位レベルもハッシュによって選択されるため、バックエンドのセットが安定している場合でも、選択されたエンドポイントは一貫しています。

Maglev

Maglevロードバランサーは、上流ホストへの一貫したハッシュを実装しています。 65537の固定テーブルサイズでこのペーパーのセクション3.4で説明されているアルゴリズムを使用します（同じペーパーのセクション5.3を参照）。 Maglevは、一貫性のあるハッシュが必要な場所であれば、リングハッシュロードバランサの代わりとして使用できます。リングハッシュロードバランサーと同様に、一貫性のあるハッシュロードバランサーは、ハッシュする値を指定するプロトコルルーティングが使用されている場合にのみ有効です。

テーブル構築アルゴリズムは、テーブルが完全に一杯になるまで、各ホストをその重みに比例して何回かテーブルに配置します。たとえば、ホストAの重みが1、ホストBのホストが2の場合、ホストAのエントリは21,846エントリ、ホストBのエントリ数は43,691エントリ（合計65,537エントリ）になります。設定されたホストとローカリティの重みに関係なく、アルゴリズムは各ホストをテーブルに少なくとも1回配置しようとします。そのため、極端な場合には実際の比率が設定された重みと異なる場合があります。たとえば、ホストの総数が固定テーブルサイズよりも大きい場合、一部のホストはそれぞれ1エントリを取得し、残りのホストは重みに関係なく0を取得します。ベストプラクティスは、min_entries_per_hostおよびmax_entries_per_hostゲージを監視して、ホストが過少表示または不足していないことを確認することです。

一般に、リングハッシュ（「ケタマ」）アルゴリズムと比較すると、マグレブは、テーブル検索の構築時間とホスト選択時間が大幅に短縮されています（256Kエントリの大きなリングサイズを使用する場合、それぞれ約10倍と5倍）。 Maglevの欠点は、リングハッシュほど安定していないことです。ホストが削除されると、より多くのキーが位置を移動します（シミュレーションでは、キーが移動するのに比べて約2倍になります）。そうは言っても、Redisを含む多くのアプリケーションにとって、Maglevはリングハッシュの代わりになる可能性が非常に高いです。上級の読者はこのベンチマークを使用して、リングハッシュとMaglevを異なるパラメータで比較することができます。

ランダム

ランダムロードバランサは、ランダムに利用可能なホストを選択します。ヘルスチェックポリシーが設定されていない場合、ランダムロードバランサは一般にラウンドロビンよりもパフォーマンスが優れています。ランダム選択は、障害が発生したホストの後に来るセット内のホストへの偏りを回避します。

優先度

負荷分散の間、Envoyは通常、最も高い優先度レベルで設定されたホストのみを考慮します。各EDS LocalityLbEndpointに対して、オプションの優先順位も指定できます。最高の優先順位レベル（P = 0）のエンドポイントが正常な場合、すべてのトラフィックはその優先順位レベルのエンドポイントに到達します。最高の優先順位レベルのエンドポイントが正常でなくなると、トラフィックは低い優先順位レベルに細流化し始めます。

システムは、現在デフォルトで1.4に設定可能な、設定可能なオーバープロビジョニング係数でオーバープロビジョニングできます（このドキュメントではこの値を想定しています）。優先度レベルの80％のエンドポイントが健全である場合でも、80 * 1.4> 100であるため、そのレベルは依然として完全に健全であると見なされます。

優先順位レベルのロジックは整数のヘルススコアで機能します。レベルのヘルススコアは、（レベル内の健全なホストの割合）*（オーバープロビジョニング係数）で、上限は100％です。 P = 0のエンドポイントはトラフィックの（レベル0のヘルススコア）パーセントを受け取り、残りはP = 1に流れます（P = 1が100％正常であると仮定します - 詳細は後述）。たとえば、P = 0のエンドポイントの50％が正常な場合、トラフィックの50 * 1.4 = 70％が受信されます。各優先順位レベルが受け取るトラフィックの整数パーセントは、まとめてシステムの「優先順位負荷」と呼ばれます。その他の例（優先度2レベル、P = 1 100％健全）：
P = 0の正常なエンドポイントP = 0へのトラフィックP = 1へのトラフィック
100％100％0％
72％100％0％
71％99％1％
50％70％30％
25％35％65％
0％0％100％

注意

負荷分散アルゴリズムと正規化された総合的な健全性の計算が正しく機能するためには、各優先度レベルがトラフィックの（100％*過剰プロビジョニング係数）を処理できなければなりません。 P = 0に10台のホストがあるがP = 1に2台のホストしかない場合、その仮定はおそらく成り立たないでしょう。

正常性スコアは、レベルが元々過剰プロビジョニングされていたこと、および現在いくつかのエンドポイントが異常であることを考慮した後の、レベルの現在のトラフィック処理能力を表します。したがって、すべてのレベルのヘルススコアの合計が100未満の場合、Envoyはトラフィックを完全に処理するのに十分なヘルスエンドポイントがないと考えます。この合計を「正規化された総合的な健全性」と呼びます。正規化された総合的な健全性が100を下回ると、トラフィックはレベルの正常性スコアをその100以下の合計に正規化した後に分配されます。例えば。 {20、30}の正常性（50の正常化された合計正常性が得られる）は正規化され、トラフィックの{40％、60％}の優先度の負荷になります。
P = 0正常なエンドポイントP = 1正常なエンドポイントPへのトラフィック= 0 Pへのトラフィック= 1
100％100％100％0％
72％72％100％0％
71％71％99％1％
50％50％70％30％
25％100％35％65％
25％25％50％50％

より多くの優先度が追加されると、それより上のレベルのヘルスが合計で100％にならない限り、各レベルはその正規化された有効ヘルスと等しい負荷を消費します。
P = 0正常なエンドポイントP = 1正常なエンドポイントP = 2正常なエンドポイントPへのトラフィック= 0 Pへのトラフィック= 1 Pへのトラフィック= 2
100％100％100％100％0％0％
72％72％100％100％0％0％
71％71％100％99％1％0％
50％50％100％70％30％0％
25％100％100％35％65％0％
25％25％100％35％35％30％
25％25％20％36％36％28％

これを擬似アルゴリズムでまとめると、

health（P_X）= min（100、1.4 * 100 * healthy_P_X_backends / total_P_X_backends）
normal_total_health = min（100、Σ（健康（P_0）...健康（P_X）））
priority_load（P_0）=分（100、正常性（P_0）/正規化総計ヘルス）
priority_load（P_X）= min（100 - Σ（priority_load（P_0）.. priority_load（P_X-1））、
健康（P_X）/正規化された総計健康）

注：このセクションでは健全な優先順位について説明しましたが、これは優先順位の低下にも当てはまります。

劣化したエンドポイント

Envoyは、特定のエンドポイントを劣化としてマーク付けすることをサポートしています。つまり、エンドポイントはトラフィックを受信できますが、使用可能なホストが十分になくなって初めてトラフィックを受信します。

劣化したホストへのルーティングは、優先順位の低いホストへのルーティングと考えることができます。優先順位の高いホストが正常でなくなると、トラフィックは優先順位の低いトラフィックに流れます。利用可能な健全なホストの量が負荷の100％を処理するのに十分ではなくなると、トラフィックは健全なホストの優先スピルオーバーと同じメカニズムを使用して劣化したホストにあふれます。これにより、トラフィックは必要に応じて徐々に劣化したホストにシフトされます。
P = 0正常/劣化/異常P = 0の正常ホストへのトラフィックP = 0の劣化ホストへのトラフィック
100％/ 0％/ 0％100％0％
71％/ 0％/ 29％100％0％
71％/ 29％/ 0％99％1％
25％/ 65％/ 10％35％65％
5％/ 0％/ 95％100％0％

アクティブヘルスチェックを使用し、アップストリームホストに特別なヘッダーを返させることで、エンドポイントを劣化としてマークすることができます。

局所性加重ロードバランシング

異なるゾーンおよび地理的位置にわたる割り当てに重み付けする方法を決定するための1つのアプローチは、LocalityLbEndpointsメッセージでEDSを介して提供される明示的な重みを使用することです。ローカリティ対応LBの場合、ゾーン対応ルーティングで使用されるEnvoy側のヒューリスティックではなく、ローカリティの重み付けを提供するために管理サーバーに依存しているため、このアプローチはゾーン対応ルーティングと相互排他的です。

すべてのエンドポイントが利用可能になると、地域の重み付けが重み付けに使用される重み付きラウンドロビンスケジュールを使用して地域が選択されます。地域内のいくつかの端点が利用できない場合は、これを反映するように地域の重みを調整します。優先順位レベルと同様に、オーバープロビジョニングファクタ（デフォルト値1.4）を想定しています。これは、ローカリティ内の少数のエンドポイントしか使用できない場合には、ウェイト調整を実行しないことを意味します。

２つのローカリティＸおよびＹを有する単純なセットアップを仮定する。ここで、Ｘは１のローカリティ重みを有し、Ｙは２のローカリティ重みを有し、Ｌ＝Ｙ１００％利用可能であり、デフォルトのオーバープロビジョニング係数１．４である。
L = Xの正常なエンドポイントLに対するトラフィックの割合L = X Lに対するトラフィックの割合Y =
100％33％67％
70％33％67％
69％32％68％
50％26％74％
25％15％85％
0％0％100％

これを擬似アルゴリズムでまとめると、

可用性（L_X）= 140 * available_X_upstreams / total_X_upstreams
effective_weight（L_X）= locality_weight_X * min（100、在庫状況（L_X））
L_Xへのロード=有効重量（L_X）/Σ_c（有効重量（L_c））

局所性加重選択は優先順位レベルが選択された後に行われることに注意してください。ロードバランサは次の手順に従います。

優先レベルを選択してください。
（このセクションで説明されているように）（1）から優先順位レベル内で地域を選択します。
（2）からローカリティ内のクラスター指定ロードバランサーを使用してエンドポイントを選択します。

ローカリティ加重ロードバランシングは、クラスタ設定でlocality_weighted_lb_configを設定し、load_balancing_weightを介してLocalityLbEndpointsにウェイトを提供することで設定されます。

この機能は、ローカルバランサーのサブセット化とは互換性がありません。ローカリティレベルの重み付けと個々のサブセットの適切な重み付けを調整するのは簡単ではないためです。

オーバープロビジョニング要因

優先順位と地域はこの割合で過剰にプロビジョニングされていると見なされます。使用可能なホストの割合にオーバープロビジョニング係数を掛けた値が100を下回るまで、Envoyは優先度レベルまたはローカリティを使用不可と見なしません。デフォルト値は1.4です。 72％以下

パニックしきい値

負荷分散の間、Envoyは一般的に上流のクラスタで利用可能な（健全なまたは劣化した）ホストのみを考慮します。ただし、クラスタ内の使用可能なホストの割合が低くなりすぎると、Envoyは正常性状態を無視し、すべてのホスト間のバランスを取ります。これはパニックしきい値として知られています。デフォルトのパニックしきい値は50％です。これは実行時およびクラスタ設定で設定可能です。パニックしきい値は、負荷が増加したときにホスト障害がクラスタ全体に及ぶという状況を回避するために使用されます。

パニックしきい値は優先順位と連動して機能します。与えられた優先度で利用可能なホストの数が減ると、Envoyはトラフィックをより低い優先度にシフトしようとします。低い優先順位で十分な数の利用可能なホストを見つけることに成功した場合、Envoyはパニックしきい値を無視します。数学的には、すべての優先度レベルにわたる正規化された総可用性が100％の場合、Envoyはパニックしきい値を無視し、ここで説明されているアルゴリズムに従ってトラフィック負荷を優先度全体に分散し続けます。ただし、正規化された総可用性が100％を下回ると、Envoyはすべての優先度レベルにわたって利用可能なホストが十分にないと見なします。トラフィックの負荷を優先度全体に分散し続けますが、特定の優先度レベルの可用性がパニックしきい値を下回ると、トラフィックはその優先度レベルにあるすべてのホストにその可用性に関係なく行きます。

次の例では、正規化された総可用性とパニックしきい値の関係について説明します。デフォルト値の50％がパニックしきい値に使用されると想定されます。

2つの優先レベル、P = 1 100％健全な単純な設定を想定してください。このシナリオでは、正規化されたトータルヘルスは常に100％で、P = 0はパニックモードに入ることはなく、Envoyは必要な量のトラフィックをP = 1にシフトすることができます。
P = 0健常エンドポイント

トラフィック
P = 0まで

P = 0〜P = 1 P = 1 P = 1パニック正規化トータルヘルス
72％100％いいえ0％いいえ100％
71％99％NO 1％NO 100％
50％70％NO 30％NO 100％
25％35％NO 65％NO 100％
0％0％いいえ100％いいえ100％

Ｐ＝１が不健康になった場合、健康状態Ｐ＝０＋Ｐ＝１の合計が１００％を下回るまで、パニック閾値は無視され続ける。この時点で、Envoyは優先度ごとにパニックしきい値のチェックを開始します。
P = 0健全なエンドポイントP = 1健全なエンドポイントP = 0へのトラフィックP = 0 P = 0へのトラフィックP = 1 P = 1へのトラフィック正規化された総合健康状態
72％72％100％NO 0％NO 100％
71％71％99％NO 1％NO 100％
50％60％50％NO 50％NO 100％
25％100％25％NO 75％NO 100％
25％25％50％YES 50％YES 70％
5％65％7％YES 93％NO 98％

パニックしきい値は優先度ごとに設定できます。

元の行き先

これは、元のデスティネーションクラスタでのみ使用できる特殊用途のロードバランサです。上流ホストは、下流接続メタデータに基づいて選択される、すなわち、接続は、接続がEnvoyにリダイレクトされる前の着信接続の宛先アドレスと同じアドレスに開かれる。ロードバランサによって新しい宛先がオンデマンドでクラスタに追加され、クラスタはクラスタから未使用のホストを定期的に削除します。他の負荷分散ポリシーを元の宛先クラスタで使用することはできません。
元の宛先ホスト要求ヘッダー

Envoyは、x-envoy-original-dst-hostというHTTPヘッダーから元の宛先を選ぶこともできます。完全に解決されたIPアドレスはこのヘッダで渡されるべきであることに注意してください。たとえば、リクエストをポート8888でIPアドレス10.195.16.237のホストにルーティングする必要がある場合、リクエストヘッダー値は10.195.16.237:8888に設定する必要があります。

ゾーンアウェアルーティング

以下の用語を使います。

発信側/上流側クラスタ：Envoyは、発信側クラスタから上流側のクラスタに要求をルーティングします。
ローカルゾーン：発信元クラスタとアップストリームクラスタの両方にあるホストのサブセットを含む同じゾーン。
ゾーン対応ルーティング：ローカルゾーン内のアップストリームクラスタホストへの要求のベストエフォート型ルーティング。

発信元クラスタとアップストリームクラスタ内のホストが異なるゾーンに属する配置では、Envoyはゾーン対応ルーティングを実行します。ゾーン対応ルーティングを実行する前に、いくつかの前提条件があります。

発信元クラスタとアップストリームクラスタの両方がパニックモードになっていません。
ゾーン対応ルーティングが有効になります。
発信元クラスタは、アップストリームクラスタと同じ数のゾーンを持ちます。
上流のクラスタに十分なホストがあります。詳しくはこちらをご覧ください。

ゾーン対応ルーティングの目的は、（ロードバランシングポリシーに応じて）すべてのアップストリームホストで1秒あたりの要求数をほぼ維持しながら、できるだけ多くのトラフィックをアップストリームクラスタのローカルゾーンに送信することです。

Envoyは、アップストリームクラスタ内のホストあたりのリクエスト数がほぼ同じである限り、できるだけ多くのトラフィックをローカルアップストリームゾーンにプッシュしようとします。 Envoyがローカルゾーンにルーティングするかクロスゾーンルーティングを実行するかは、発信元クラスタ内の健全なホストとローカルゾーン内のアップストリームクラスタの割合によって決まります。発信元クラスタとアップストリームクラスタ間のローカルゾーン内のパーセンテージ関係に関して、2つのケースがあります。

発信元クラスタローカルゾーンのパーセンテージが、アップストリームクラスタ内のパーセンテージよりも大きい。この場合、すべての要求を元のクラスタのローカルゾーンから上流のクラスタのローカルゾーンにルーティングすることはできません。これは、すべての上流のホストで要求の不均衡が発生するためです。代わりに、Envoyはアップストリームクラスタのローカルゾーンに直接ルーティングできる要求の割合を計算します。残りの要求はクロスゾーンにルーティングされます。特定のゾーンは、そのゾーンの残容量に基づいて選択されます（そのゾーンはローカルゾーンのトラフィックを取得し、Envoyがクロスゾーンのトラフィックに使用できる追加の容量がある場合があります）。
発信元クラスタのローカルゾーンのパーセンテージが、アップストリームクラスタのものよりも小さい。この場合、アップストリームクラスタのローカルゾーンは、発信側クラスタのローカルゾーンからすべての要求を取得し、発信側クラスタの他のゾーンからのトラフィックを許可するスペースを確保できます（必要な場合）。

複数の優先順位を使用する場合、ゾーン対応ルーティングは現在P = 0に対してのみサポートされていることに注意してください。

ロードバランササブセット

Envoyは、ホストに添付されたメタデータに基づいて、アップストリームクラスタ内のホストをサブセットに分割するように設定できます。ルートは、ロードバランサによって選択されるためにホストが一致しなければならないメタデータを指定することができ、任意のホストを含む定義済みのホストのセットにフォールバックすることができます。

サブセットは、クラスターで指定されたロードバランサーポリシーを使用します。上流のホストは前もって知られていないので、元の宛先ポリシーはサブセットでは使用されない可能性があります。サブセットはゾーン対応ルーティングと互換性がありますが、サブセットの使用は前述の最小ホスト条件に容易に違反する可能性があることに注意してください。

サブセットが設定され、ルートにメタデータが指定されていない、またはメタデータと一致するサブセットが存在しない場合、サブセットロードバランサはそのフォールバックポリシーを開始します。デフォルトのポリシーはNO_ENDPOINTです。この場合、クラスタにホストがない場合と同様に要求は失敗します。逆に、ANY_ENDPOINTフォールバックポリシーは、ホストメタデータに関係なく、クラスタ内のすべてのホスト間で負荷を分散します。最後に、DEFAULT_SUBSETにより、特定のメタデータセットに一致するホスト間でフォールバックによる負荷分散が行われます。

サブセットロードバランサがホストの正しいサブセットを効率的に選択できるように、サブセットを事前定義する必要があります。各定義はキーのセットであり、これは0個以上のサブセットに変換されます。概念的には、定義内のすべてのキーのメタデータ値を持つ各ホストは、そのキーと値のペアに固有のサブセットに追加されます。すべてのキーを持つホストが存在しない場合、定義からサブセットは生成されません。複数の定義を提供することができ、それが複数の定義と一致する場合、単一のホストが複数のサブセットに現れることがあります。

ルーティング中、ルートのメタデータ一致設定は特定のサブセットを見つけるために使用されます。ルートで指定された正確なキーと値を持つサブセットがある場合は、そのサブセットが負荷分散に使用されます。それ以外の場合は、フォールバックポリシーが使用されます。したがって、サブセットのロードバランシングを実行するには、クラスタのサブセット構成に特定のルートと同じキーを持つ定義を含める必要があります。

この機能は、V2設定APIを使用してのみ有効にできます。さらに、ホストメタデータは、クラスターにEDS検出タイプを使用している場合にのみサポートされます。サブセットロードバランシング用のホストメタデータは、フィルタ名 "envoy.lb"の下に配置する必要があります。同様に、経路メタデータ一致基準は、 "envoy.lb"フィルタ名を使用します。ホストメタデータは階層的であり得る（例えば、トップレベルキーの値は構造化された値またはリストであり得る）が、サブセットロードバランサはトップレベルキーおよび値を比較するだけである。したがって、構造化値を使用する場合、ルートの一致基準は、ホストのメタデータに同じ構造化値が表示されている場合にのみ一致します。
例

すべての値が文字列である単純なメタデータを使用します。次のホストが定義され、クラスタに関連付けられているとします。
ホストメタデータ
host1 v：1.0、ステージ：prod
host2 v：1.0、ステージ：prod
host3 v：1.1、stage：カナリア
host4 v：1.2-pre、ステージ：dev

クラスタは、次のようにサブセットロードバランシングを有効にします。

名前：クラスター名
タイプ：EDS
eds_cluster_config：
eds_config：
パス： '... / eds.conf'
connect_timeout：
秒：10
lb_policy：LEAST_REQUEST
lb_subset_config：
fallback_policy：DEFAULT_SUBSET
default_subset：
ステージ：プロッド
subset_selectors：
- キー：
- v
- ステージ
- キー：
- ステージ

次の表は、いくつかの経路とそのクラスタへの適用結果を示しています。通常、一致基準は、パスやヘッダー情報など、要求の特定の側面に一致するルートで使用されます。
一致基準の理由による残高
ステージ：カナリアホスト3選択したホストのサブセット
v：1.2-pre、stage：dev host4選択したホストのサブセット
v：1.0 host1、host2フォールバック： "v"だけのサブセットセレクタはない
other：x host1、host2フォールバック： "other"のサブセットセレクタはありません
（なし）host1、host2フォールバック：サブセット要求なし

メタデータの一致基準は、ルートの加重クラスタにも指定できます。選択された加重クラスターからのメタデータ一致基準は、経路からの基準とマージされ、それをオーバーライドします。
ルート一致基準加重クラスタ一致基準最終一致基準
ステージ：カナリアステージ：prodステージ：prod
v：1.0ステージ：prod v：1.0、ステージ：prod
v：1.0、ステージ：prodステージ：カナリアv：1.0、ステージ：カナリア
v：1.0、ステージ：prod v：1.1、ステージ：canary v：1.1、ステージ：canary
（なし）v：1.0 v：1.0
v：1.0（なし）v：1.0
メタデータを持つホストの例

ホストメタデータを含むEDS LbEndpoint：

終点：
住所：
socket_address：
プロトコル：TCP
アドレス：127.0.0.1
port_value：8888
メタデータ：
filter_metadata：
envoy.lb：
バージョン： '1.0'
ステージ： 'prod'

メタデータ基準を持つルートの例

メタデータ一致基準を持つRDSルート

一致：
接頭辞：/
ルート：
cluster：クラスタ名
metadata_match：
filter_metadata：
envoy.lb：
バージョン： '1.0'
ステージ： 'prod'

Envoy: ロードバランシング