なぜAPISIX Ingress ControllerはNGINX Ingress Controllerよりも優れているのか？

Ingress は Kubernetes のサービスを公開し、トラフィックのルーティングは Ingress リソース に設定されたルールによって制御されます。Ingress を満たすためには、Ingress コントローラー も必要です。

この記事では、2つの人気のある Ingress コントローラーを比較し、読者が Ingress コントローラーを選択する際の洞察を提供します。

• Ingress-NGINX は Kubernetes コミュニティによって実装された Ingress コントローラーで、コミュニティ内で広く使用されています。
• APISIX Ingress コントローラー は、ASF (Apache Software Foundation) のオープンソースプロジェクトである Apache APISIX をデータプレーンとして使用しています。

Ingress NGINX vs. APISIX Ingress

機能比較

以下の表は、Ingress NGINX と APISIX Ingress の基本的な機能を比較したものです。プロトコル、アップストリームプローブ/レジリエンシー、ロードバランサー戦略、認証、Kubernetes 統合などが含まれています。この表は learnk8s.io から抽出されています。

違い

以下の図から、APISIX Ingress には Ingress NGINX よりも多くの組み込み機能と特徴があることがわかります。プロトコルサポート、ヘルスチェックとサーキットブレーカー、認証、Kubernetes 統合などが含まれます。

サービスディスカバリー

マイクロサービス アーキテクチャでは、アプリケーションは多くのマイクロサービスに分割されます。マイクロサービスが失敗したり、サービスがスケールアップまたはダウンしたりするたびに、呼び出し元にできるだけ早く通知する必要があります。これにより、呼び出しの失敗を防ぐことができます。そのため、サービス登録とサービスディスカバリーメカニズムはマイクロサービスアーキテクチャにおいて非常に重要であり、通常はサービスレジストリによって維持されます。

プロトコルサポート

両方の Ingress は HTTP/HTTPS プロトコルをサポートしていますが、APISIX はより多くのプロトコルをサポートしています。TCP トラフィックを暗号化するための TLS もサポートしています。また、MQTT、Dubbo、kafka のプロキシもサポートしています。

アップストリームプローブ/レジリエンシー

ヘルスチェック

ノードが失敗したり、移行したりすると、そのノードが利用できなくなることは避けられません。大量のリクエストがこれらの利用できないノードにアクセスすると、トラフィックの損失やビジネスの中断を引き起こします。そのため、プローブを使用してノードのヘルスチェックを行い、リクエストを正常なノードに誘導することで、トラフィックの損失を減らす必要があります。

Ingress NGINX ではまだヘルスチェック機能がサポートされていませんが、APISIX Ingress はこの機能を提供しています：

• アクティブチェック: プローブを使用して、バックエンドの Pod が正常であることを確認します。ノードに送信された N 回の連続したプローブが失敗すると、そのノードは異常とマークされます。ロードバランサーは異常なノードを無視するため、リクエストを受信できなくなります。アクティブヘルスチェックを有効にすることで、異常な Pod を無効にし、トラフィックの損失を防ぐことができます。
• パッシブチェック: パッシブヘルスチェックでは、追加のプローブを開始する必要はありません。ノードに送信される各リクエストがプローブとして機能します。正常なノードへの N 回の連続したリクエストが失敗すると、そのノードは異常とマークされます。事前にノードの状態を感知できないため、一定量の失敗したリクエストが発生する可能性があります。この状況はローリングアップデート中に比較的よく見られ、サービスのダウングレードを使用して失敗したリクエストの量を減らすことができます。

APISIX Ingress が httpbin サービスのヘルスチェックを設定する例：

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

サーキットブレーカー

ゲートウェイはリクエストのエントリーポイントであり、バックエンドサービスへの呼び出しを開始します。トラフィックがピークに達し、負荷が重い場合、バックエンドサービスはタイムアウトや例外により呼び出しに失敗する可能性があります。失敗が発生した場合、リクエストをゲートウェイに積み上げることはできません。迅速に返す必要があり、そのためにはゲートウェイでブレークが必要です。

ヘルスチェック機能と同様に、Ingress NGINX ではサービスのサーキットブレーカー機能がサポートされていません。APISIX Ingress では、api-breaker プラグインがこれを実装するのに役立ちます。

APISIX Ingress でのサーキットブレーカーの設定例：

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

より多くのプラグインと認証方法のサポート

Ingress NGINX は主に Annotations と ConfigMap を使用して設定を行い、サポートされている プラグイン は比較的限られています。JWT、HAMC、またはその他の 認証 方法を使用したい場合、自分で統合する必要があります。

APISIX Ingress は、APISIX の 80以上のプラグイン をネイティブにサポートしており、JWT、HAMC、wolf-rbac などの複数の認証方法をサポートしています。これらのプラグインは、ほとんどの使用シナリオをカバーする多様な機能を提供します。

APISIX ルートでの HMAC 認証の例：

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Ingress NGINX と APISIX Ingress の拡張性

Ingress コントローラーの基本機能が企業ユーザーのニーズを満たせない場合、拡張によってのみカスタマイズできます。次に、Ingress NGINX と APISIX Ingress がどのように機能を拡張するかを説明します。

Ingress NGINX の機能拡張方法

Ingress NGINX は、Lua プログラムを組み込むことによってのみ拡張できます。

Ingress NGINX プラグイン開発 の例：

1. Lua プログラム example-plugin を作成
2. プラグインを ingress-nginx pod の /etc/nginx/lua/plugins/<your plugin name> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin にインストール
3. ConfigMap で example-plugin を有効にし、Ingress NGINX をインストールする際にこの ConfigMap オブジェクトを参照

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

APISIX Ingress の機能拡張方法

APISIX Ingress は、機能を拡張するためのさまざまな方法を提供しており、企業ユーザーは自分のニーズに応じて自由に方法を選択できます。APISIX は以下をサポートしています：

• Lua によるプラグイン開発：シンプルでパフォーマンスの損失がほとんどない
• プラグインランナーによる開発：JAVA/Python/Go などのプログラミング言語がサポートされており、新しい言語を学ぶことなくプラグインをカスタマイズできる
• WASM によるプラグイン：WASM をビルドできる言語であれば、プラグイン開発に使用可能

さらに、サーバーレスプラグインを通じて直接 Lua コードを記述することで、迅速にビジネスニーズを満たすことができます。

APISIX Ingress が CustomResourceDefinition (CRD) をサポートする理由

現在、APISIX Ingress は Ingress、CRD、Gateway API の3つの宣言的設定をサポートしています。ここでは主に Ingress と CRD を比較します。Gateway API については後で説明します。

Ingress は、Ingress NGINX から移行する企業ユーザーにとって移行コストが低いため、より適しています。その欠点も明らかで、セマンティック能力が弱く、標準仕様がないなどがあります。また、Ingress はアノテーションを通じてのみ拡張できますが、アノテーションは複雑なシナリオをサポートできません。一方、CRD には以下の利点があります：

• データプレーンの設計セマンティクスに合致しているため、使いやすい
• 設定の再利用性が高く、冗長性を減らす
• 機能と拡張性が向上
• APISIX のデータプレーンは活発なコミュニティを持ち、迅速な更新とリリースがあり、CRD はデータプレーンのより多くの機能を簡単にサポートできる

Ingress NGINX の課題：ホットリロードがサポートされていない

静的設定による問題

Ingress NGINX は主に NGINX 設定ファイルに基づいて実装されています。NGINX と Lua を使用して機能拡張を実現していますが、静的設定ファイルの問題を部分的に解決しているに過ぎません。ルーティングとリロードの能力において不十分さが見られます。例えば、ルールを追加または変更する際に NGINX 設定をリロードする必要があります。ルーティングルールと証明書が増えるにつれて、リロード操作には数秒から十数秒かかることがあります。NGINX のリロードごとにロードバランシングの状態がリセットされ、オンライントラフィックに悪影響を及ぼし、短い中断、応答遅延の増加、ロードバランシング品質の低下を引き起こします。

NGINX リロードを引き起こす状況

• 新しい Ingress リソースの作成
• 既存の Ingress に TLS セクションを追加
• Ingress アノテーションの変更（例：ロードバランスアノテーションはリロード不要）
• Ingress にパスを追加または削除
• Ingress、Service、または Secret リソースの削除
• Secret の更新

上記の状況は、Ingress コントローラーのほとんどの使用シナリオをカバーしています。アプリケーションが頻繁にデプロイされるクラスター環境では、Ingress や Secret などのリソースの操作（作成、更新、削除など）が継続的にトリガーされます。これにより、NGINX リロードの数が急増し、本番環境に大きな影響を与えます。

Ingress NGINX のアーキテクチャは、まず NGINX 設定を生成し、リロードして設定を更新する必要があることを決定しています。アーキテクチャを調整しない限り、リロードの問題を解決することはできません。この問題を解決するために、APISIX Ingress はルーティング実装において NGINX 設定に依存せず、純粋なメモリアーキテクチャに変更しました。ホットリロードを通じて動的ルーティングを実現し、NGINX を再起動する必要がなくなりました。

Gateway API

Kubernetes Gateway API の利点

Kubernetes Gateway API は Ingress よりも機能が豊富で、多くのベンダーによって実装され、業界全体で広くサポートされている表現力豊かで拡張可能なロール指向のインターフェースを通じて Kubernetes サービスネットワーキングを進化させることを目的としています。Gateway API には以下の特徴があります：

• ロール指向: Gateway は API リソースで構成されています。異なる API リソースは、Kubernetes ネットワークリソースの使用と設定における異なる役割を表します。

• 強力な表現力: Gateway API は、ヘッダーベースのマッチング、トラフィックの重み付けなど、Ingress ではカスタマイズされた非標準のアノテーションを通じてのみ可能だったコア機能をサポートしています。

• 拡張性: Gateway API は、異なるリソースをさまざまな API 層でリンクすることを可能にします。これにより、API 構造内で細かいカスタマイズが可能になります。

Gateway API のサポート状況

Kubernetes Gateway API は、Kubernetes サービスメッシュを拡張するための標準です。その Gateway リソースは、ゲートウェイのライフサイクルを管理するための Kubernetes API として使用でき、非常に強力です。Istio、Kong、Traefik など、多くの Ingress コントローラーが積極的にサポートしています。残念ながら、Ingress NGXIN はまだ Gateway API をサポートする予定はありません (Gateway API 実装状況)。一方、APISIX Ingress はすでに Gateway API のほとんどの機能をサポートしています：HTTPRoute、TCPRoute、TLSRoute、UDPRoute など。

まとめ

APISIX Ingress と Ingress NGINX を徹底的に比較した結果、両方のオープンソースソフトウェアが優れており、基本的な機能は似ていることがわかります。しかし、マイクロサービスアーキテクチャでは、APISIX Ingress はヘルスチェックとサーキットブレーカーを提供することで、サービスガバナンスとサービスディスカバリーのサポートにおいてより多くの利点を示しています。

Ingress NGINX はシンプルで使いやすいという特徴がありますが、機能拡張が難しいなどの明らかな欠点もあります。後発の APISIX Ingress は、NGINX のホットリロードの課題を解決し、より良い拡張性と機能を提供しています。例えば、Gateway API と CRD のサポートにより、Ingress コントローラーのプロジェクト開発における能力が豊かになっています。

要するに、より豊富な機能とより良い拡張性を持つ Ingress コントローラーを選択したい場合、APISIX Ingress を強くお勧めします。 Ingress コントローラーに慣れておらず、多くの機能要件がない場合、Ingress NGINX もそのシンプルさから良い選択肢です。