tldr

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

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

目次はこちらです。

動的構成

Envoyは、さまざまなタイプの構成管理アプローチが可能であるように設計されています。展開で採用されるアプローチは、実装者のニーズに依存します。完全に静的な構成で簡単な展開が可能です。より複雑なデプロイメントでは、より複雑な動的構成を徐々に追加することができますが、欠点は実装者が1つ以上の外部RESTベースの構成プロバイダーAPIを提供する必要があることです。このドキュメントは現在利用可能なオプションの概要を説明します。

トップレベルの設定参照
参照設定
Envoy v2 APIの概要

完全に静的

完全に静的な設定では、実装者は一連のリスナ（およびフィルタチェーン）、クラスタ、およびオプションでHTTPルート設定を提供します。動的ホスト検出は、DNSベースのサービス検出を介してのみ可能です。設定のリロードは、内蔵のホットリスタートメカニズムを介して行わなければなりません。

単純ではありますが、静的な設定と適切なホットリスタートを使用して、かなり複雑な展開を作成できます。

EDSのみ

Endpoint Discovery Service（EDS）APIは、Envoyがアップストリームクラスタのメンバーを検出するためのより高度なメカニズムを提供します。 EDSは静的な設定の上に階層化されているため、Envoyの展開でDNSの制限（応答の最大レコード数など）を回避したり、負荷分散やルーティングに使用される情報（カナリアステータス、ゾーンなど）を消費したりできます。。）

EDSとCDS

Envoyがルーティング中に使用されるアップストリームクラスタを検出できるメカニズムに、CDS（Cluster Discovery Service）API層があります。 Envoyは、APIの指定に従って、クラスタを適切に追加、更新、削除します。このAPIにより、実装者は初期構成時にEnvoyがすべてのアップストリームクラスタを認識する必要がないトポロジを構築できます。通常、CDSと共にHTTPルーティングを実行する場合（ただし、経路探索サービスは含まない）、実装者はHTTP要求ヘッダーで指定されたクラスタに要求を転送するルーターの機能を利用します。

完全に静的なクラスターを指定することでEDSなしでCDSを使用することは可能ですが、CDSで指定されたクラスターにはEDS APIを使用することをお勧めします。内部的には、クラスター定義が更新されると、操作は正常に行われます。ただし、既存の接続プールはすべて排出され、再接続されます。 EDSはこの制限を受けません。ホストをEDSで追加および削除しても、クラスタ内の既存のホストは影響を受けません。

EDS、CDS、およびRDS

Envoyが実行時にHTTP接続マネージャフィルタのルート設定全体を検出できるようにするメカニズムのルートディスカバリサービス（RDS）APIレイヤ。既存のリクエストに影響を与えることなく、ルート設定は適切に入れ替えられます。このAPIをEDSおよびCDSと組み合わせて使用すると、実装者は複雑なルーティングトポロジ（トラフィックシフト、青/緑の展開など）を構築できます。

EDS、CDS、RDS、およびLDS

リスナー検出サービス（LDS）は、Envoyが実行時にリスナー全体を検出できるようにするメカニズムに基づいています。これには、RDSへの埋め込み参照を含むHTTPフィルタまでのすべてのフィルタスタックが含まれます。 LDSをミックスに追加することで、Envoyのほぼすべての側面を動的に構成することができます。ホットリスタートは、非常にまれな設定変更（管理者、トレースドライバなど）、証明書のローテーション、またはバイナリアップデートにのみ必要です。

EDS、CDS、RDS、LDS、およびSDS

Envoyがリスナーの暗号化秘密（証明書と秘密鍵、TLSセッションチケット鍵）を検出できるメカニズム、およびピア証明書検証ロジック（信頼されたルート証明書、失効など）のシークレット検出サービス（SDS）レイヤ）