Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに

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種総合比較テーブル

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

|---|---|---|---|---|---|

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

|---|---|---|---|---|---|

| Traefik | 無停止 | ダッシュボード + メトリクス + トレーシング | 中 | 大 | MIT |

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

コントローラ別の詳細

ingress-nginx

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

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

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:

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:

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:

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:

port:

number: 80

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

Contour

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

apiVersion: projectcontour.io/v1

kind: HTTPProxy

metadata:

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:

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:

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:

spec:

http:

- name: rule1

match:

hosts:

- app.example.com

paths:

- /*

backends:

- serviceName: web

servicePort: 80

plugins:

- name: limit-count

enable: true

config:

time_window: 60

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

Emissary (Ambassador)

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

apiVersion: getambassador.io/v3alpha1

kind: Mapping

metadata:

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 Gateway | Gateway APIネイティブ |

| API製品/ポータル | Kong, APISIX | プラグインベースのAPI管理 |

| シビアなL4/L7制御 | HAProxy | 細やかな負荷分散/ヘルスチェック |

| Envoy機能 + 単純CRD | Emissary | Envoyを易しい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分離による共存戦略を事前に身につけておくと、後で移行するときに大きく役立ちます。

参考資料

- Kubernetes Ingress 公式ドキュメント: https://kubernetes.io/docs/concepts/services-networking/ingress/

- Kubernetes Ingress Controllers: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

- ingress-nginx 公式ドキュメント: https://kubernetes.github.io/ingress-nginx/

- Traefik 公式ドキュメント: https://doc.traefik.io/traefik/

- HAProxy Kubernetes Ingress ドキュメント: https://www.haproxy.com/documentation/kubernetes-ingress/

- Project Contour 公式ドキュメント: https://projectcontour.io/docs/

- Envoy Gateway 公式ドキュメント: https://gateway.envoyproxy.io/docs/

- Kong Ingress Controller ドキュメント: https://docs.konghq.com/kubernetes-ingress-controller/

- Apache APISIX Ingress ドキュメント: https://apisix.apache.org/docs/ingress-controller/getting-started/

- Gateway API 公式サイト: https://gateway-api.sigs.k8s.io/

- cert-manager 公式ドキュメント: https://cert-manager.io/docs/

- Emissary-ingress 公式ドキュメント: https://www.getambassador.io/docs/emissary/