Skip to content
Published on

2026 Ingress Controller 総合比較 — 8種ベンチマークと選定ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに

Kubernetesクラスタを運用していると、最初に直面する選択肢の一つが「どのIngress Controllerを使うか」です。外部トラフィックをクラスタ内部のサービスへルーティングするこのコンポーネントは、一度選ぶと数年間付き合う中核インフラです。しかしいざ比較しようとすると候補が多すぎます。ingress-nginx、Traefik、HAProxy、Contour、Envoy Gateway、Kong、APISIX、Emissaryまで、それぞれ異なるデータプレーンと思想を持っています。

2026年現在、この選択は単に「どれが速いか」という問題ではありません。Ingress API自体がfrozen状態となり新機能が追加されなくなり、Gateway APIが後継標準として定着したことで、「このコントローラがGateway APIをどれだけ成熟して対応しているか」が将来コストを左右する重要な変数になりました。さらに最も広く使われていたingress-nginxが保守モードへ移行し、複数のセキュリティ問題(CVE)が報告されたことで、多くの組織が代替案を真剣に検討し始めました。

本記事では8種のコントローラを、設定方式、CRDモデル、TLS自動化、性能、可観測性、Gateway API対応、エコシステム、ライセンスの観点で総合比較します。単なるスペックの羅列ではなく、「どの状況で何を選ぶべきか」という意思決定の観点で整理しました。

Ingress Controllerの基本アーキテクチャ

Ingress Controllerは2つの部分に分かれます。一つはKubernetes APIを監視しながらIngress/CRDリソースの変化を読み取り設定を生成するコントロールプレーン、もう一つは実際にトラフィックを処理する**データプレーン(プロキシエンジン)**です。

                  外部トラフィック
                      │
                      ▼
            ┌───────────────────┐
            │  LoadBalancer/    │   (クラウドLBまたはNodePort)
            │  Service          │
            └─────────┬─────────┘
                      │
                      ▼
      ┌───────────────────────────────┐
      │     Ingress Controller Pod     │
      │  ┌──────────┐   ┌───────────┐  │
      │  │ Control  │──▶│  Data     │  │
      │  │ Plane    │   │  Plane    │  │
      │  │ (watch)  │   │  (proxy)  │  │
      │  └────┬─────┘   └─────┬─────┘  │
      └───────┼───────────────┼────────┘
              │               │
       watch Ingress/CRD      ▼
              │        ルーティング → backend Service/Pod
              ▼
        Kubernetes API

データプレーンが何かによってコントローラの性格は大きく分かれます。大きく3系統に分けられます。

  • nginx系: ingress-nginx。実績あるnginxエンジン。設定reloadベース。
  • Envoy系: Contour、Envoy Gateway、Emissary。xDSベースの動的設定、hot reload不要。
  • 独自/その他エンジン: Traefik(Go独自エンジン)、HAProxy(haproxyエンジン)、Kong(nginx+Lua/OpenRestyベース)、APISIX(nginx+Luaベース)。

エンジンの差は、動的設定の反映速度、メモリ使用量、機能拡張の方式に直接影響します。たとえばnginxベースは設定変更時にreloadが必要で、接続が多い環境では一時的な負荷が生じうる一方、EnvoyベースはxDSにより無停止の動的更新が可能です。

8種総合比較テーブル

まず主要項目を一目で比較します。

コントローラデータプレーン設定方式専用CRDTLS自動化Gateway API
ingress-nginxnginxIngress + アノテーションほぼ無しcert-manager連携別プロジェクト(ingate)へ分離
TraefikTraefik(Go)CRD(IngressRoute) + アノテーション豊富(Middleware等)内蔵ACME成熟
HAProxyHAProxyIngress + アノテーション + ConfigMap一部CRDcert-manager連携対応(成長中)
ContourEnvoyCRD(HTTPProxy)HTTPProxycert-manager連携成熟
Envoy GatewayEnvoyGateway APIネイティブGateway API中心cert-manager連携ネイティブ(第一級)
Kongnginx/OpenRestyCRD + アノテーションKongPlugin等cert-manager連携対応
APISIXnginx/OpenRestyCRD(ApisixRoute)ApisixRoute等cert-manager連携対応
EmissaryEnvoyCRD(Mapping)Mapping等内蔵ACME対応(一部)

続いて性能・運用項目を比較します。

コントローラ動的reload可観測性APIゲートウェイ機能エコシステム/成熟度ライセンス
ingress-nginxreload必要Prometheusメトリクス限定的非常に大(保守モード)Apache 2.0
Traefik無停止ダッシュボード + メトリクス + トレーシング中大MIT
HAProxy部分無停止豊富なstats + メトリクス限定的大Apache 2.0
Contour無停止(xDS)Envoyメトリクス/トレーシング低中(CNCF)Apache 2.0
Envoy Gateway無停止(xDS)Envoyメトリクス/トレーシング中(ポリシーCRD)成長中(CNCF)Apache 2.0
Kong部分豊富(プラグイン)非常に高大Apache 2.0 + エンタープライズ
APISIX無停止(etcd)豊富(プラグイン)非常に高中(ASF)Apache 2.0
Emissary無停止(xDS)Envoyメトリクス/トレーシング高中Apache 2.0

表のとおり、「APIゲートウェイ機能が必要か」と「Gateway APIをどれだけ重視するか」の2軸が選択を大きく分けます。

コントローラ別の詳細

ingress-nginx

最も広く使われてきたコントローラです。実績あるnginxエンジンを使い、多くのチュートリアルや運用事例がこのコントローラを基準に書かれています。設定はIngressリソース + アノテーションで行います。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

2026年の重要な注意点は、ingress-nginxが保守モードへ移行しつつあることです。過去、アノテーションによる任意設定注入(snippet)機能で複数のセキュリティ問題(CVE)が報告され、snippet機能はデフォルト無効化の流れになりました。後継のGateway API実装は別プロジェクトとして進められる形のため、長期的には他のコントローラやGateway APIネイティブ実装への移行を検討するのが合理的です。

Traefik

Goで書かれた独自エンジンを使い、動的設定と豊富なCRDが強みです。ACME(Let's Encrypt)証明書の自動発行が内蔵されており、cert-managerなしでもTLS自動化が可能です。IngressRoute、MiddlewareといったCRDで表現力のあるルーティングを構成します。

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: web
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`app.example.com`) && PathPrefix(`/api`)
      kind: Rule
      services:
        - name: api
          port: 80
      middlewares:
        - name: rate-limit

ダッシュボードが直感的で、ミドルウェアチェーンのモデルが整理されています。ただし無料版とエンタープライズ(Traefik Hub)で機能差があるため、必要な機能がどちらに属するか確認が必要です。

HAProxy

長年実績のあるHAProxyエンジンを使います。安定性と細やかな負荷分散制御が強みで、豊富なstatsページとメトリクスを提供します。Ingress + アノテーション + グローバルConfigMapの組み合わせで設定します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    haproxy.org/load-balance: "roundrobin"
    haproxy.org/timeout-client: "30s"
spec:
  ingressClassName: haproxy
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

L4/L7の両方で強力な負荷分散アルゴリズムとヘルスチェックを提供するため、シビアなトラフィック制御が必要な環境に適します。

Contour

CNCFプロジェクトで、Envoyをデータプレーンとして使います。HTTPProxyというCRDで委譲(delegation)ベースのマルチテナンシーを優雅に表現できるのが特徴です。xDSベースのため設定変更時にreloadなしで動的に反映されます。

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: web
spec:
  virtualhost:
    fqdn: app.example.com
    tls:
      secretName: app-tls
  routes:
    - conditions:
        - prefix: /
      services:
        - name: web
          port: 80

HTTPProxyのinclude機能で、ルートドメインはプラットフォームチームが、配下のパスは各チームが管理する構造を作れるため、マルチテナンシーに強いです。

Envoy Gateway

Envoy陣営がGateway APIを第一級市民として実装したプロジェクトです。Ingressアノテーションモデルではなく、最初からGateway API(GatewayClass、Gateway、HTTPRoute)を中心に設計されています。2026年の新規設計なら最も有望な選択肢の一つです。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web
spec:
  parentRefs:
    - name: eg
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web
          port: 80

ポリシー(タイムアウト、リトライ、レートリミット等)はGateway APIの拡張ポリシーCRDで表現します。Ingressがfrozenとなった流れに最も適したモデルです。

Kong

OpenResty(nginx+Lua)ベースで、単純なIngressを超えた本格的なAPIゲートウェイ機能を提供します。認証、レートリミット、変換など数多くのプラグインをKongPlugin CRDで付与できます。

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit
plugin: rate-limiting
config:
  minute: 100
  policy: local

API製品化(開発者ポータル、キー管理、従量課金)が必要なら強力な選択肢です。ただしフル機能はエンタープライズ領域が多いです。

APISIX

Apache財団プロジェクトで、こちらもnginx+Luaベースであり、etcdで動的設定を管理します。ApisixRoute CRDと豊富なプラグイン、Admin APIが特徴です。動的ルーティングの更新が速く、プラグインエコシステムが活発です。

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: web
spec:
  http:
    - name: rule1
      match:
        hosts:
          - app.example.com
        paths:
          - /*
      backends:
        - serviceName: web
          servicePort: 80
      plugins:
        - name: limit-count
          enable: true
          config:
            count: 100
            time_window: 60

オープンソースだけでもAPIゲートウェイ機能を幅広く使えるのが利点です。

Emissary (Ambassador)

Envoyベースの初期のAPIゲートウェイの一つで、Mapping CRDでルーティングを表現します。開発者フレンドリーな宣言的モデルと内蔵ACMEが特徴です。

apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: web
spec:
  hostname: app.example.com
  prefix: /
  service: web:80

Envoyの機能を比較的単純なCRDで公開するため、Envoy機能は欲しいがraw Envoy設定は負担というチームに合います。

選定基準

スペック比較だけでは決めにくいです。次の軸で判断するとよいでしょう。

規模

  • 小規模/単純ルーティング: ingress-nginx(既存資産があれば)またはTraefik。参入障壁が低く資料が多いです。
  • 中大規模/マルチチーム: Contour(HTTPProxy委譲)またはEnvoy Gateway(Gateway APIの役割分離)がマルチテナンシーに有利です。
  • 大規模/API製品化: KongまたはAPISIX。プラグインベースのポリシーとAPI管理が必要なとき。

チーム能力

Envoyベース(Contour、Envoy Gateway、Emissary)はEnvoyの概念(xDS、リスナー、クラスタ)をある程度理解すれば強力ですが、学習曲線があります。一方ingress-nginxとTraefikは入りやすいです。チームがnginxに慣れていればAPISIX/Kongのデバッグも比較的容易です。

API管理の要否

単にトラフィックをルーティングするのが目的ならContour/Envoy Gateway/Traefikで十分です。認証、レートリミット、変換、開発者ポータル、従量課金といったAPIゲートウェイ機能が中核ならKongまたはAPISIXが適します。

オンプレ環境

クラウドLBがないオンプレでは、MetalLBのようなLB実装との相性、そして自前の証明書運用(cert-manager)との連携が重要です。ほとんどのコントローラはよく動作しますが、HAProxy/ingress-nginxはオンプレ運用の実績が長く、参考資料を見つけやすいです。

ワークロード別おすすめ

ワークロードおすすめ理由
単純なWebサービスTraefik, ingress-nginx素早い開始、豊富な資料
マルチテナントプラットフォームContour, Envoy Gateway役割分離/委譲モデル
新規グリーンフィールド(2026)Envoy GatewayGateway APIネイティブ
API製品/ポータルKong, APISIXプラグインベースのAPI管理
シビアなL4/L7制御HAProxy細やかな負荷分散/ヘルスチェック
Envoy機能 + 単純CRDEmissaryEnvoyを易しいCRDで

移行の難易度

既存コントローラから別のコントローラへ移すときの難易度は、「設定モデルがどれだけ異なるか」に比例します。

  • Ingressアノテーション → 別のIngressアノテーション(例: ingress-nginx → HAProxy): アノテーションのマッピングだけで済むため比較的容易です。ただしrewriteやパスマッチングの動作差を検証する必要があります。
  • Ingress → CRDモデル(例: ingress-nginx → Traefik IngressRoute、Contour HTTPProxy): リソースを新たに書き起こす必要があるため変換作業が大きいです。
  • Ingress → Gateway API(例: ingress-nginx → Envoy Gateway): ingress2gatewayのような変換ツールがありますが、ポリシー部分は手動マッピングが必要です。

肝心なのは、いずれの場合もIngressClassを分離して2つのコントローラを共存させ、DNSやトラフィック重み付けで段階移行することです。

総所有コスト(TCO)の観点

表面的なコンテナコスト以外に、次を考慮すべきです。

  • ロードバランサコスト: クラウドでコントローラごとにLoadBalancerサービスを別々に持つと、LBコストが掛け算で増えます。共有LB + 単一Ingress入口がコスト効率的です。
  • 運用人員コスト: 学習曲線が急なコントローラは初期導入コストが大きいです。資料が豊富なコントローラはトラブルシュート時間が短くなります。
  • エンタープライズライセンス: Kong/Traefik等の一部機能は商用ライセンスが必要な場合があります。オープンソースの範囲を明確に確認すべきです。
  • 移行コスト: 保守モードのコントローラに留まると、後で移行コストが一度に発生します。長期TCOではこの点が大きいです。

2026トレンド: Ingress frozen → Gateway API

最も重要な流れはIngress APIがfrozen状態であることです。つまりIngress APIには新機能が追加されず、すべての新機能はGateway APIへ入ります。Gateway APIはGatewayClass/Gateway/HTTPRouteの3層の役割分離、マルチプロトコル(HTTP、gRPC、TCP、UDP、TLS)、標準化されたポリシーモデルを提供します。

   過去(Ingress)             未来(Gateway API)
   ──────────────            ─────────────────────
   Ingress + アノテーション    GatewayClass (プラットフォーム/インフラ)
   (ベンダー別の非標準)             │
                              Gateway (クラスタ運用者)
                                   │
                              HTTPRoute/GRPCRoute (アプリ開発者)

したがって2026年の新規導入なら、Gateway APIを第一級で対応するコントローラ(Envoy Gateway等)を優先的に検討するのが将来コストを下げる道です。既存Ingress資産が大きい組織も、ingress2gatewayのようなツールで段階移行の経路を計画しておくのがよいでしょう。

意思決定フロー

最後に選定プロセスをフローチャートで整理します。

                    開始: Ingress Controllerの選定
                              │
              ┌───────────────┴───────────────┐
              │ APIゲートウェイ機能(認証/      │
              │ レートリミット/ポータル)が中核か?│
              └───────────────┬───────────────┘
                  はい │            │ いいえ
                      ▼             ▼
              ┌──────────────┐   ┌──────────────────────┐
              │ Kong / APISIX │   │ マルチテナンシー/役割  │
              └──────────────┘   │ 分離が重要か?         │
                                 └──────────┬───────────┘
                            はい │                │ いいえ
                                 ▼                ▼
                      ┌────────────────┐   ┌────────────────────┐
                      │ Gateway API     │   │ 素早い開始/豊富な   │
                      │ ネイティブが欲しい?│   │ 資料が重要か?       │
                      └───────┬────────┘   └─────────┬──────────┘
                     はい│       │いいえ          はい │
                          ▼       ▼                  ▼
                 ┌──────────┐ ┌─────────┐   ┌───────────────────┐
                 │ Envoy    │ │ Contour │   │ Traefik /         │
                 │ Gateway  │ │         │   │ ingress-nginx     │
                 └──────────┘ └─────────┘   └───────────────────┘

おわりに

Ingress Controllerの選定に正解はありません。ただし2026年には2つの大きな流れを必ず考慮すべきです。第一に、Ingress APIはfrozenとなりGateway APIが標準的な未来であること。第二に、ingress-nginxが保守モードへ移行することで、安定性とセキュリティの面から代替案の検討が必要になったことです。

既存資産が大きく単純ルーティングならTraefikや既存のingress-nginxで十分ですが、新規グリーンフィールドならEnvoy GatewayのようなGateway APIネイティブ実装を第一候補として検討することをおすすめします。マルチテナンシーが重要ならContour、API製品化が中核ならKongやAPISIXが答えになります。何を選ぶにせよ、IngressClass分離による共存戦略を事前に身につけておくと、後で移行するときに大きく役立ちます。

参考資料

Discuss on Twitter • View on GitHub