なぜAPISIX Ingress ControllerはEmissary-ingressよりも優れた選択肢なのか？
Xin Rong
March 17, 2023
背景情報
Kubernetes Ingressは、クラスター内の外部トラフィックを内部サービスにルーティングするためのルールを定義するために使用されるAPIオブジェクトです。Ingress Controllerは、Ingressリソースのロジックを実装し、これらのトラフィックルールを一元管理するために一般的に使用されます。
実際には、企業ユーザーは通常、mTLS、リトライ、レートリミット、認証などのトラフィック管理機能を必要としますが、Ingressリソースのセマンティクスではこれを満たすことができません。そのため、Ingress Controllerの実装では、通常、追加のCRDを追加することで機能を拡張します。以下では、APISIX Ingress ControllerとEmissary-Ingressの実装の違いについて詳細に比較します。
Apache APISIX Ingress Controllerとは
Apache APISIX Ingress Controllerは、ASF（Apache Software Foundation）の下にあるオープンソースプロジェクトです。そのコントロールプレーンはKubernetes内のリソースを設定および配信し、APISIXが実際のビジネストラフィックを処理します。セキュリティを向上させるために、デプロイメントプロセス全体で完全に分離されたデータプレーンとコントロールプレーンのアーキテクチャを使用しており、データプレーンへの攻撃によるKubernetesクラスターの権限漏洩のリスクを効果的に回避しています。
Emissary-Ingressとは
Emissary-Ingressは、CNCF（Cloud Native Computing Foundation）のインキュベーションプロジェクトです。Envoyプロキシのコントロールプレーンとして、Kubernetesリソースを解析し、すべてのトラフィックはデータプレーン上のEnvoyによって直接処理されます。コントロールプレーンとデータプレーンを1つのコンテナにパッケージ化することで、全体がよりアクセスしやすく、デプロイしやすくなっています。
APISIX Ingress ControllerとEmissary-Ingressの違い
APISIX Ingress ControllerとEmissary-Ingressは、Ingressリソースをサポートするだけでなく、CRDとGateway APIを通じて設定をサポートし、Ingressのセマンティクスの制限を補完することができます。
以下のセクションでは、基本的な機能、サービスディスカバリ、拡張性の観点から、両者の違いと利点を分析します。
基本的な機能
| 機能 | APISIX Ingress | Emissary-ingress | |
| プロトコル | HTTP/HTTPS | ✓ | ✓ |
| gRPC | ✓ | ✓ | |
| TCP | ✓ | ✓ | |
| UDP | ✓ | ✕ | |
| Websockets | ✓ | ✓ | |
| ロードバランシング | ラウンドロビン | ✓ | ✓ |
| リングハッシュ | ✓ | ✓ | |
| 最小接続数 | ✓ | ✓ | |
| Maglev | ✕ | ✓ | |
| 認証 | 外部認証 | ✓ | ✓ |
| 基本認証 | ✓ | ✓ | |
| JWT | ✓ | ✕ | |
| OAuth | ✓ | ✕ | |
| OpenID | ✓ | ✕ | |
| トラフィック管理 | サーキットブレーカー | ✓ | ✓ |
| レートリミット | ✓ | ✓ | |
| カナリア | ✓ | ✓ | |
| フォルトインジェクション | ✓ | ✕ | |
| ヘルスチェック | ✓ | ✓ | |
一般的なゲートウェイ機能には、トラフィック管理、ロードバランシング、認証が含まれます。ただし、Emissary-Ingressは認証のサポートが比較的限られており、Basic AuthとExternal Authの機能しか含まれていないことに注意が必要です。
サービスディスカバリ
マイクロサービスアーキテクチャでは、アプリケーションは通常、特定のビジネスロジックを達成するために協力する複数のマイクロサービスに分解されます。マイクロサービスのインスタンス数は常に変化するため、サービスが互いを発見し、位置を特定するためのメカニズムが必要です。
サービスディスカバリとは、サービス名を通じてサービスディスカバリの情報を取得し、リクエストがどのインスタンスにルーティングされるかを決定する方法を指します。
従来のマイクロサービスフレームワークでは、レジストリの選択は特定のビジネス要件に基づいて行われることが多いです。しかし、既存のサービス登録およびディスカバリコンポーネントをKubernetesベースのDNSサービスディスカバリメカニズムに移行するには、変更に伴うコストがかかることがあります。
一方、ゲートウェイが現在のサービス登録およびディスカバリコンポーネントをサポートしている場合、そのような変更は必要なく、マイクロサービスフレームワークのサポートが向上します。
以下は、両者のサービスディスカバリコンポーネントのサポート状況です：
| サービスディスカバリ | Apache APISIX Ingress Controller | Emissary-Ingress |
|---|---|---|
| Kubernetes | ✓ | ✓ |
| DNS | ✓ | ✓ |
| Nacos | ✓ | ✕ |
| Eureka | ✓ | ✕ |
| Consul | ✓ | ✓ |
サービスディスカバリエコシステムに関して、APISIX Ingress Controllerはより強力なサポートを提供しており、ユーザーはIngressコントローラーを通じて既存のマイクロサービスフレームワークに簡単に統合できます。
拡張性
Kubernetes Ingressコントローラーの機能が特定の要件を満たさない場合、ユーザーはカスタム開発を通じてその機能を拡張できます。より個別化されたニーズは、カスタムプラグインの開発や既存のコードの変更によって満たすことができます。拡張性が高いIngressコントローラーは、機能の開発とカスタマイズを容易にし、特定のシナリオに対するより良いサポートとソリューションを提供します。
Emissary-Ingress
Emissary-Ingressの拡張性は比較的低く、カスタムEnvoy Filterによる拡張をサポートしていません。データプレーンとコントロールプレーンが統合されているため、システム全体のカスタム開発が必要です。データプレーンEnvoyのカスタム開発の複雑さは高く、開発者にとって大きな負担となります。
さらに、ユーザーがより強力なEmissary-Ingressを必要とする場合、Ambassadorの商用製品Edge Stackにアップグレードする必要があります。一部の独自機能は、サポートを得るために支払いが必要です。
APISIX Ingress Controller
APISIXのデータプレーンは、主にプラグインを通じて機能を拡張し、80以上のすぐに使えるプラグインを提供しています。APISIX Ingress Controllerは、APISIXが提供するすべてのプラグインをサポートしており、ほとんどの日常的なユースケースを満たすことができます。
特定のビジネスシナリオに基づいてカスタマイズが必要な場合、APISIXは複数の拡張オプションを提供しており、ユーザーは状況に応じて自由に選択および組み合わせることができます。現在サポートされている拡張方法は以下の通りです：
- Lua言語を使用してプラグインを開発することは比較的簡単で、ほとんどパフォーマンスの低下がありません。さらに、サーバーレスプラグインを使用してLuaコードを直接記述することができ、ビジネス要件を迅速に満たすことができます。
- ネイティブのLua言語に加えて、
Plugin RunnerまたはWASMプラグインを使用して拡張することもでき、Java、Python、Goなどのコーディング言語でカスタムプラグインを開発することができます。これにより、ユーザーは既存のビジネスロジックを活用し、会社の技術スタックや開発の好みに基づいて選択することができ、新しい言語を学ぶ必要はありません。
APISIX Ingress Controllerは、上記の拡張方法を完全にサポートしており、追加の開発は必要ありません。
パフォーマンス
Kubernetes Ingressトラフィックプロキシコンポーネントとして、プラットフォームへのすべての着信トラフィックを管理し、さまざまなトラフィックルールを一元管理するため、プロキシのパフォーマンスに対する要求が高くなります。
この記事では、APISIX Ingress Controller（APISIX: 3.1.0）とEmissary-Ingress 3.4.0を同じインスタンス（4C 8G）でパフォーマンステストを行います。
QPS
QPS（Queries-per-second）は、サービスが1秒間に処理できるクエリの数を表します。数値が高いほど、パフォーマンスが良いことを示します。
- 5000 IngressリソースのQPS
レイテンシ
応答レイテンシ：サーバーが応答するのにかかる時間。遅延が小さいほど、パフォーマンスが良いことを示します。
グラフから、APISIX Ingress Controllerは異なるリソーススケールで一貫したパフォーマンスを維持し、バランスの取れたパフォーマンスを示しています。
一方、Emissary-Ingressは、大規模なリソーススケールや異なるルーティングマッチングを処理する際にQPSとレイテンシに大きな影響を受け、リソース数が増えるにつれてパフォーマンスが低下します。そのため、実際の生産環境でビジネス量が増加するにつれて、APISIXの高性能がより顕著になります。
結論
Emissary-Ingressは、シンプルで統合が容易であることが特徴ですが、カスタム開発が難しいです。さらに、追加の機能要件はプラットフォームの関連コンポーネントに依存しています。
一方、APISIX Ingress Controllerは、拡張性とサービスディスカバリ統合において優位性があり、強力な拡張性とシンプルな開発を提供します。さらに、APISIX Ingress Controllerは特にビジネス規模が拡大し続けるシナリオで優れたパフォーマンスを示し、大きな利点があります。