Envoy は、クラウドネイティブアプリケーション向けに作られた、高性能で拡張可能なプロキシです。レイヤー 3/4 とレイヤー 7 の両方で動作し、通過するトラフィックのロードバランシング、サービスディスカバリー、リトライ、サーキットブレーキング、可観測性を担います。また、最近のほとんどのサービスメッシュや API ゲートウェイの根底にある、データプレーンのプロキシでもあります。

仕組み

Envoy は通常、各アプリケーションインスタンスの隣のサイドカーとして、またはスタンドアロンのエッジプロキシとしてデプロイされます。ディスカバリー API の集合（総称して「xDS」）によって動的に設定されます。コントロールプレーンがリスナー、ルート、クラスター、エンドポイントの設定をプッシュし、Envoy は再起動せずにそれを適用します。高速で汎用的なデータプレーンと、差し替え可能なコントロールプレーンを分離するこの設計が、Istio などのツールが Envoy の上に完全なサービスメッシュを構築できる理由です。

主要な概念

• Listener（リスナー） — Envoy が接続を受け付ける、名前付きのネットワーク上の場所（IP とポート）です。
• Route（ルート） — 受信リクエストに一致させ、どのアップストリームクラスターが処理するかを決定する設定です。
• Cluster（クラスター） — Envoy がトラフィックをロードバランスできる、アップストリームエンドポイントのグループで、ヘルスチェックとコネクションプールの設定も含みます。
• xDS API — コントロールプレーンが Envoy に動的に設定をプッシュするために使う、ディスカバリープロトコルの一群です（LDS、RDS、CDS、EDS など）。

チームが Envoy を採用する理由

• 豊富なレイヤー 7 機能。 HTTP/2、gRPC、リトライ、タイムアウト、サーキットブレーキング、きめ細かなトラフィック分割をネイティブにサポートします。
• 深い可観測性。 詳細なメトリクス、ログ、分散トレーシングが、後付けではなく組み込まれています。
• 動的な設定。 ルーティングやエンドポイントの変更は、再起動や接続の切断なしに適用されます。
• 共通の基盤。 Istio、いくつかの API ゲートウェイ、多くのマネージドな ingress コントローラーの基盤であるため、スキルがツール間で転用できます。

はじめに

Kubernetes のコンテキストでは、Envoy が単独で実行されることはまれです。ほとんどのチームは、Istio のようなサービスメッシュのサイドカープロキシとして、あるいは ingress コントローラーや API ゲートウェイの背後のエンジンとして、これに出会います。以降のガイドでは、そうした一般的なコンテキストでの Envoy の設定方法を説明します。