tldr
勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。
原文としたのEnvoyのドキュメントはこちらのディレクトリ以下にあります（ライセンス：Apache License 2.0, NOTICE）。
静的状態
Envoyは、フィルタ、フィルタ間、および他のコアサブシステムへの設定、メタデータ、および要求/接続ごとの状態の転送について、次のようなメカニズムを提供します（アクセスログなど）。
静的状態は、構成ロード時に（例えば、xDS を介して）指定された不変状態である。静的状態には3つのカテゴリがあります。
メタデータ
Envoyの設定のいくつかの部分（リスナー、ルート、クラスタなど）には、任意のキーと値のペアをエンコードできるメタデータが含まれています。一般的なパターンは、キーとしてリバース DNS 形式のフィルタ名を使用し、値にフィルタ固有の設定メタデータをエンコードすることです。このメタデータは不変であり、すべての要求/接続にわたって共有されます。このような設定メタデータは通常、ブートストラップ時または xDS の一部として提供されます。たとえば、HTTP ルートの加重クラスタは、加重クラスタに対応するエンドポイントのラベルを示すためにメタデータを使用します。別の例では、サブセットロードバランサは、重み付けされたクラスタに対応するルートエントリからのメタデータを使用して、クラスタ内の適切なエンドポイントを選択します。
型付きメタデータ
メタデータ自体は型指定されていません。メタデータを処理する前に、呼び出し側は通常、それを型付きクラスオブジェクトに変換します。変換コストは、（例えば、各要求ストリームまたは接続に対して）繰り返し実行されると無視できなくなる。型付きメタデータは、フィルタが特定のキーに対して1回限りの変換ロジックを登録できるようにすることで、この問題を解決します。 （ xDS を介した）受信設定メタデータは、設定ロード時にクラスオブジェクトに変換されます。フィルタは実行時に（要求または接続ごとに）型指定されたメタデータを取得できるため、要求/接続処理中に ProtobufWkt :: Struct から何らかの内部オブジェクトに繰り返し変換するフィルタが不要になります。
たとえば、ClusterInfo のキー xxx.service.policy を持つ不透明なメタデータの上にコンビニエンスラッパークラスを持つことを望むフィルタは、ClusterTypedMetadataFactory から継承するファクトリ ServicePolicyFactory を登録できます。ファクトリは ProtobufWkt :: Struct を ServicePolicy クラスのインスタンスに変換します（ FilterState :: Object から継承）。クラスタが作成されると、関連付けられた ServicePolicy インスタンスが作成されキャッシュされます。型付きメタデータはメタデータの新しいソースではないことに注意してください。構成の一部として指定されているメタデータから取得されます。
HTTP ルート別フィルタの設定
HTTP ルートでは、per_filter_config を使用すると、HTTP フィルタはすべての仮想ホストに共通のグローバルフィルタ設定に加えて、仮想ホスト/ルート固有の設定を持つことができます。この設定は変換され、ルートテーブルに組み込まれます。ルート固有のフィルタ設定をグローバル設定または機能拡張の代わりとして扱うのは、HTTP フィルタの実装次第です。たとえば、HTTP 障害フィルタはこの手法を使用して、ルートごとの障害構成を提供します。
per_filter_configは マップ<文字列、ProtobufWkt :: Struct>です。接続マネージャはこのマップを繰り返し処理し、フィルタファクトリインタフェース createRouteSpecificFilterConfig を呼び出して構造体の値を解析/検証し、それをルート自体に格納されている型付きクラスオブジェクトに変換します。 HTTP フィルタは、リクエスト処理中にルート固有のフィルタ設定を問い合わせることができます。