Emissary-Ingress

Envoy Proxy を基盤に、CRD だけで設定する Kubernetes ネイティブな API ゲートウェイ兼 Ingress。

カテゴリ: API Gateway
CNCF 成熟度: Incubating
言語: Go と Python
ライセンス: Apache-2.0
リポジトリ: emissary-ingress/emissary
ドキュメント基準コミット: 65b0dd9ae (タグ v4.0.1 付近、2026-05-01)

何をするものか

Emissary-Ingress は Kubernetes 向けの Ingress コントローラ兼 API ゲートウェイである。データプレーンとして Envoy Proxy を動かし、それを Kubernetes のカスタムリソースから設定する。ルーティングは Listener・Host・Mapping リソースで宣言し、Emissary がそれを Envoy 設定に変換する。source of truth は Kubernetes であり、専用のデータベースは持たない。

1 つのコンテナの中で 4 つの要素が協調して動く。Go の entrypoint プロセス、Python の diagd 設定エンジン、Envoy プロセス、そして ambex という Go の ADS サーバである。Go 側がクラスタを watch して snapshot を組み立て、Python 側がその snapshot を Envoy 設定にコンパイルし、ambex が結果を xDS の集約ディスカバリサービス (ADS) で Envoy に流す。

OSS のこのプロジェクトは商用 Ambassador Edge Stack のコアであり、Edge Stack は同じエンジンの上に ACME/TLS 自動化、OAuth/OIDC、レート制限、開発者ポータルを追加する。

いつ使うか

アノテーションではなく CRD で宣言的に設定する Envoy ベースの edge ゲートウェイが欲しいとき。
プレーンな NGINX Ingress より細かい L7 制御 (ヘッダベースのルーティング、トラフィック分割、レート制限フック) が必要なとき。
大量のリクエストを捌き、プロキシを再起動せずに Envoy の動的な xDS 更新を使いたいとき。
すでに独自ゲートウェイを同梱するサービスメッシュを運用している場合や、最小限の単一 Ingress バイナリで足りる場合は向かない。

このディープダイブの構成

歴史: 起源・マイルストーン・存在理由。
アーキテクチャ: コンポーネントとリクエストの流れ。
採用事例・エコシステム: 誰が動かし、周囲に何があるか。
内部実装: ソースから読んだ重要なコードパス。
はじめに: インストールと最初の動く構成。

Emissary-Ingress ​

何をするものか ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

Emissary-Ingress

何をするものか

いつ使うか

このディープダイブの構成

出典