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

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

はじめに

Kubernetes クラスタにサービスを外部公開するとき、ほぼすべてのチームが最初にぶつかる問いがあります。「Ingress コントローラーに何を使うか」です。そしてその答えを探す過程で、最も頻繁に比較対象に挙がる二つの候補が、まさに Traefik と ingress-nginx です。

この二つは表面的には同じ仕事をします。外部から入ってくる HTTP/HTTPS トラフィックを受け取り、クラスタ内部の適切なサービスへルーティングする仕事です。しかし少し深く入ると、二つのプロジェクトは出発点から、設計思想、設定を表現する方式、動的変更を処理するメカニズム、そしてエコシステムにおける位置づけまで、かなり異なります。

私は金融系顧客のオンプレミスクラスタと、クラウドベースの AI サービングプラットフォームを運用する中で、両方のコントローラーを本番に投入した経験があります。その過程で「どちらがより良いか」という問いが、実は誤った問いだと学びました。より正確な問いは「私たちのチームの運用方式と要件にどちらがより合うか」です。

特に 2026 年現在は、この比較に重要な文脈がもう一つ加わりました。Kubernetes の Ingress API は機能的に凍結（frozen）され、もう新しい機能が追加されません。後継標準である Gateway API が GA に到達し、事実上の次世代標準として定着しました。さらに ingress-nginx プロジェクトはメンテナンスモードへ移行し、過去に何度もセキュリティ問題を経験した経緯があります。こうした変化はコントローラー選択の重心を変えつつあります。

本記事では二つのコントローラーを設計思想から実運用のディテールまで深く比較し、同じ要件を両者でどう実装するかを YAML 例で並べて示したうえで、最後にシナリオ別の推奨と意思決定テーブルで整理します。

二つのコントローラーのアイデンティティ

ingress-nginx — 実績ある NGINX の上の薄い制御層

まず用語から整理します。「nginx Ingress」という言葉は、実は二つの異なるプロジェクトを指しうるため混乱を招きます。

- **ingress-nginx**: Kubernetes プロジェクト（コミュニティ）が管理するコントローラーです。本記事で扱う対象であり、最も広く使われています。

- **nginx-ingress**: NGINX（F5）社が管理する別の商用/オープンソースコントローラーです。アノテーション体系と CRD が異なります。

本記事で「ingress-nginx」と言う場合は前者、すなわち kubernetes.github.io/ingress-nginx で管理されるコミュニティプロジェクトを意味します。

ingress-nginx の核となる発想は「すでに数十年検証された NGINX をデータプレーンとして使い、その上に Kubernetes リソースを監視して nginx.conf を生成する薄い制御層を載せる」ことです。コントローラーは Ingress リソースの変更を検知すると、テンプレートを通じて新しい nginx.conf を作り、NGINX に reload を指示します。

この設計の長所は明確です。NGINX は性能と安定性の面で業界標準であり、運用者がすでに慣れています。短所も明確です。きめ細かな動作制御が Ingress リソースのアノテーションに依存することになり、複雑な要件は結局 nginx.conf スニペットを直接注入する方式へ流れやすくなります。

Traefik — クラウドネイティブのために最初から設計されたプロキシ

Traefik は最初から動的でコンテナ中心の環境のために Go で書かれたリバースプロキシです。Docker の頃から「サービスが立ち上がり消える環境で、人が設定ファイルを書き直さなくても自動的にルーティングを更新する」という目標を核心的な価値として掲げてきました。

Traefik の設定は静的設定（static configuration）と動的設定（dynamic configuration）に分かれます。静的設定は EntryPoint（リスニングポート）、プロバイダー、ログなどプロセス起動時に決まる部分であり、動的設定は Router、Service、Middleware などランタイムで変わり続けるルーティング規則です。Kubernetes ではこの動的設定を Ingress リソースでも、あるいは Traefik 固有の CRD（IngressRoute、Middleware など）でも表現できます。

核心的な差別化点は、Traefik が動的設定を**無停止で反映**することです。ルーティング規則が変わってもプロセスの reload や再起動は不要です。これが二つのコントローラーを分ける最も根本的な設計上の違いです。

設計思想の比較

二つのコントローラーの違いを一枚の表に圧縮すると次のとおりです。

| 項目 | ingress-nginx | Traefik |

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

| データプレーン | NGINX（C ベース） | 自前の Go プロキシ |

| 出発点 | 既存 NGINX 上の K8s アダプター | クラウドネイティブ専用設計 |

| 設定の表現 | Ingress + アノテーション + スニペット | Ingress または CRD（IngressRoute/Middleware） |

| 設定の反映 | nginx.conf 生成後に reload | 無停止の動的反映 |

| ミドルウェアモデル | アノテーション/スニペットベース | 宣言的な Middleware チェーン |

| 自動 TLS | cert-manager を別途構成 | 内蔵 ACME（Let's Encrypt） |

| 可観測性 | メトリクス/ログ（別途構成の比重大） | メトリクス/トレーシング/ダッシュボード内蔵 |

| 設定思想 | 命令型に近い | 宣言型志向 |

この表だけでも、二つのプロジェクトが同じ問題を非常に異なる考え方で扱うことが見えてきます。ingress-nginx は「強力で慣れたエンジンを Kubernetes に接続する」ことに集中し、Traefik は「Kubernetes の宣言型モデルにプロキシ自体を同化させる」ことに集中します。

設定方式 — アノテーション vs CRD/ミドルウェア

ここが日々の運用で体感差が最も大きい領域です。

ingress-nginx のアノテーションモデル

ingress-nginx では Ingress リソース本体は単純なホスト/パスのルーティングのみを表現し、それ以外のほぼすべての付加動作（リダイレクト、リライト、認証、レートリミット、タイムアウトなど）はアノテーションで指定します。

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/rewrite-target: /$2

nginx.ingress.kubernetes.io/ssl-redirect: 'true'

nginx.ingress.kubernetes.io/proxy-body-size: 50m

nginx.ingress.kubernetes.io/rate-limit-rps: '20'

nginx.ingress.kubernetes.io/configuration-snippet: |

more_set_headers "X-Custom: hello";

spec:

ingressClassName: nginx

rules:

- host: app.example.com

http:

paths:

- path: /web(/|$)(.*)

pathType: ImplementationSpecific

backend:

service:

port:

number: 80

この方式は単純なケースでは非常に速く直感的です。しかし要件が複雑になるほどアノテーションキーが長く並び、結局 configuration-snippet や server-snippet で生の nginx.conf 断片を注入することになります。このスニペット注入は強力であると同時に最も危険な部分です。誤ったスニペット一つが reload 全体を失敗させたり、過去にはセキュリティ回避の経路になったこともあります。実際に 2025 年に報告された ingress-nginx の深刻な脆弱性は、このスニペット/設定注入の経路と深く関係しています。

Traefik の CRD と Middleware モデル

Traefik は付加動作をアノテーションではなく、独立した宣言的リソースである Middleware で表現します。そしてルーティング自体も IngressRoute という CRD でより豊かに表現できます。

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

rateLimit:

average: 20

burst: 40

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

headers:

customRequestHeaders:

X-Custom: hello

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

spec:

entryPoints:

- websecure

routes:

- match: Host(`app.example.com`) && PathPrefix(`/web`)

kind: Rule

middlewares:

- name: rate-limit

- name: custom-header

services:

- name: web-svc

port: 80

違いが見えるでしょうか。Traefik では rate-limit というポリシーが再利用可能なオブジェクトであり、複数のルートから参照でき、RBAC で権限を分離することもできます。ルーティングのマッチ規則も Host と PathPrefix を論理演算子で組み合わせる式で記述します。これはアノテーション文字列より検証とテストが容易で、GitOps 環境で変更履歴を追跡するのに有利です。

代わりにコストもあります。CRD をクラスタにインストールする必要があり、チームメンバーが Ingress 標準ではなく Traefik 固有リソースを学ぶ必要があります。標準 Ingress リソースでも Traefik を使えますが、そうすると Traefik の強みの相当部分を手放すことになります。

自動 TLS

HTTPS 証明書の発行/更新は運用で欠かせないテーマです。二つのコントローラーのアプローチが大きく異なります。

Traefik の内蔵 ACME

Traefik は Let's Encrypt のような ACME プロバイダーとの連携をコントローラー自体に内蔵しています。静的設定に証明書リゾルバを定義すると、EntryPoint に到達したドメインに対して自動的に証明書を発行・更新します。

Traefik 静的設定（values.yaml の一部）

certificatesResolvers:

letsencrypt:

acme:

email: ops@example.com

storage: /data/acme.json

httpChallenge:

entryPoint: web

IngressRoute でこのリゾルバを指定すれば完了です。別途のコントローラーインストールは不要です。

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

spec:

entryPoints:

- websecure

routes:

- match: Host(`secure.example.com`)

kind: Rule

services:

- name: secure-svc

port: 80

tls:

certResolver: letsencrypt

ただしこの内蔵 ACME は単一インスタンスのストレージ（acme.json）を前提とする場合が多く、複数レプリカへスケールアウトするには分散ストレージや外部の証明書管理が必要です。高可用性構成ではこの点が落とし穴になりえます。

ingress-nginx + cert-manager

ingress-nginx は証明書発行機能を自前で内蔵しません。代わりに事実上の標準である cert-manager と組み合わせます。cert-manager は Certificate/Issuer CRD で証明書を宣言し、発行された証明書を Secret として保存し、ingress-nginx はその Secret を参照します。

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

spec:

acme:

server: https://acme-v02.api.letsencrypt.org/directory

email: ops@example.com

privateKeySecretRef:

solvers:

- http01:

ingress:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

cert-manager.io/cluster-issuer: letsencrypt-prod

spec:

ingressClassName: nginx

tls:

- hosts:

- secure.example.com

secretName: secure-app-tls

rules:

- host: secure.example.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

一見すると構成要素が一つ増えて複雑に見えますが、実務ではむしろこの分離が長所になります。cert-manager は HA 環境、ワイルドカード証明書、DNS-01 チャレンジ、社内 PKI（Vault、プライベート ACME CA）連携まで幅広く対応します。証明書管理の責務がコントローラーと分離されているため、コントローラーを入れ替えても証明書インフラはそのまま再利用できます。

性能とリソース

性能は最も頻繁に議論されますが、最も一般化が難しい領域です。正確な数値はワークロード、コネクションパターン、設定によって大きく変わるため、絶対値より傾向と特性を理解することが重要です。

| 特性 | ingress-nginx | Traefik |

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

| データプレーン言語 | C（NGINX） | Go |

| 静的高負荷処理 | 非常に強い（検証済み NGINX） | 強い |

| コネクションあたりメモリ | おおむね低い | GC 特性により変動しうる |

| 設定変更のコスト | reload が発生 | 無停止（reload なし） |

| 大量ルート変更 | reload 頻発時に負担 | ほぼ無コスト |

ingress-nginx のデータプレーンである NGINX は、静的で安定した高負荷環境で長年検証された性能を示します。一方 Traefik は Go のガベージコレクション特性上、極端な高負荷でわずかな遅延変動がありうるものの、ほとんどの実務ワークロードでは差を体感しにくいです。

むしろ実務でより重要な性能差は「設定変更のコスト」です。ingress-nginx は Ingress が頻繁に変わる環境で reload が頻発します。マイクロサービスが数百個あり、デプロイが多い環境、あるいは動的にルートが生成/削除されるマルチテナントプラットフォームでは、reload 自体が負担になりえます。次節でこの差を詳しく扱います。

動的設定と reload の違い

この違いは二つのコントローラーの最も本質的な区分点なので、別途深く見ていきます。

ingress-nginx の reload モデル

ingress-nginx は Ingress/Service/Endpoint の変更を検知すると次の流れで動作します。

[K8s API] --watch--> [ingress-nginx controller]

新しい nginx.conf 生成（テンプレート）

NGINX reload (nginx -s reload)

新しいワーカープロセスが新設定を適用

NGINX の reload は graceful です。既存ワーカーは進行中のコネクションを完了して終了し、新しいワーカーが新設定でトラフィックを受けます。しかし reload が非常に頻繁だと、ワーカープロセスが生成/消滅を繰り返してメモリ使用量が揺れ、長寿命コネクション（WebSocket、gRPC ストリーム）が reload 時点で影響を受けることがあります。これを緩和するため、ingress-nginx はエンドポイント変更のみの場合に Lua ベースで reload なしに反映する最適化を一部導入しましたが、Ingress 構造自体が変わると依然として reload が必要です。

Traefik の無停止反映

Traefik は動的設定をメモリ内のルーティングテーブルとして管理します。CRD や Ingress が変わると、新しいルーティング規則を原子的に入れ替えるだけで、プロセスの reload やワーカーの再生成はありません。

[K8s API] --watch--> [Traefik provider]

動的設定の更新（メモリ）

ルーティングテーブルの原子的スワップ

（コネクション影響なし、reload なし）

ルートが毎秒数十回変わる環境、たとえば関数単位でルートが生成/削除されるサーバーレスプラットフォームや大規模マルチテナント SaaS では、この無停止特性が決定的な長所になります。

可観測性

運用の半分は「今何が起きているかを見ること」です。

Traefik の内蔵可観測性

Traefik は Prometheus メトリクス、分散トレーシング（OpenTelemetry）、アクセスログ、そして Web ダッシュボードをコントローラー自体に内蔵しています。設定一、二行でメトリクスエンドポイントとダッシュボードを有効化できます。

Traefik 静的設定の一部

metrics:

prometheus:

addEntryPointsLabels: true

addServicesLabels: true

tracing:

otlp:

grpc:

endpoint: otel-collector:4317

api:

dashboard: true

ダッシュボードで現在登録されているルーター、サービス、ミドルウェア、ヘルス状態を一目で確認でき、「自分のルーティング規則が実際にどう反映されたか」を素早く確認できます。ただしダッシュボードは本番環境では必ず認証で保護する必要があります。

ingress-nginx の可観測性

ingress-nginx も Prometheus メトリクスを提供し、NGINX の豊富なログ変数を活用できます。ただしトレーシングとダッシュボードはデフォルト内蔵ではなく、別途構成（例: トレーシングモジュールの有効化、Grafana ダッシュボードのインポート）の比重が大きいです。代わりに NGINX エコシステムの成熟したロギング/モニタリング資産をそのまま活用できる点は強みです。VirtualServer/Upstream 単位のメトリクス、応答時間ヒストグラムなどは SRE が慣れた形で扱えます。

エコシステムとガバナンス

Gateway API との関係

2026 年現在、最も重要な文脈です。Kubernetes Ingress API は凍結され新機能が追加されず、Gateway API が次世代標準として定着しました。Gateway API は役割ベースの分離（Infrastructure Provider / Cluster Operator / Application Developer）、表現力のあるルーティング、L4/L7 統合モデルを提供します。

- **Traefik**: Gateway API をプロバイダーの形で対応し、自前の CRD（IngressRoute）と併用できます。クラウドネイティブ標準を積極的に受け入れる方向です。

- **ingress-nginx**: プロジェクトがメンテナンスモードへ移行したことで、Kubernetes 陣営の Gateway API ベースの後継プロジェクト（例: NGINX Gateway Fabric などの Gateway API 実装）への移行の流れが形成されつつあります。新規導入であれば、Gateway API ベースの実装を真剣に検討すべき時です。

つまり長期的には両陣営とも Gateway API へ収束しつつあり、新規プロジェクトであればコントローラー選択と同時に「Ingress か Gateway API か」を一緒に考える必要があります。

メンテナンス状態とセキュリティ

ingress-nginx は非常に広く使われてきましたが、プロジェクト管理リソースの不足、メンテナンスモードへの移行、そして設定注入の経路に関連する深刻なセキュリティ脆弱性（例: 2025 年に公開された一連の CVE）の経緯があります。これは ingress-nginx が悪いという意味ではなく、新規導入時にセキュリティ運用の負担と長期ロードマップを必ず評価すべきという意味です。Traefik は活発に開発される商用バック（Traefik Labs）のあるプロジェクトで、機能追加とドキュメント化が着実です。

学習曲線

| 観点 | ingress-nginx | Traefik |

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

| 初期参入 | 易しい（Ingress 標準を知れば十分） | 普通（CRD 概念の学習が必要） |

| 単純なルーティング | 非常に速い | 速い |

| 複雑なポリシー | アノテーション/スニペット累積で急になる | Middleware で緩やかに拡張 |

| トラブルシューティング | nginx.conf デバッグ知識が必要 | ダッシュボードで直感的に把握 |

| 標準親和性 | Ingress 標準そのまま | Ingress または CRD を選択 |

ingress-nginx は標準 Ingress さえ知ればすぐ始められるため参入障壁が低いです。しかし要件が複雑になるほどアノテーションとスニペットが積み上がり、難易度が急に上がります。Traefik は初期に CRD と静的/動的設定の概念を学ぶ必要があり、ある程度の学習コストがありますが、いったん習得すれば複雑なポリシーも緩やかに拡張できます。

同一要件の実装比較

理論は十分です。同じ要件を両者でどう実装するかを並べて見ます。要件は次のとおりです。

1. app.example.com の /api パスを api-svc へ、残りを web-svc へルーティング

2. HTTP を HTTPS へ強制リダイレクト

3. /api パスに基本認証（Basic Auth）を適用

4. 秒あたりのリクエスト数を制限

ingress-nginx の実装

apiVersion: v1

kind: Secret

metadata:

type: Opaque

data:

htpasswd で生成したユーザー/パスワード（base64）

auth: dXNlcjokYXByMSRleGFtcGxlaGFzaA==

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/ssl-redirect: 'true'

nginx.ingress.kubernetes.io/limit-rps: '20'

spec:

ingressClassName: nginx

tls:

- hosts:

- app.example.com

secretName: app-tls

rules:

- host: app.example.com

http:

paths:

- path: /api

pathType: Prefix

backend:

service:

port:

number: 80

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

Basic Auth は /api パスのみに適用すべきなので、ingress-nginx では認証が必要なパスを別の Ingress オブジェクトに分離し、そのオブジェクトにのみ認証アノテーションを付けるパターンが一般的です。

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

nginx.ingress.kubernetes.io/auth-type: basic

nginx.ingress.kubernetes.io/auth-secret: api-basic-auth

nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required'

nginx.ingress.kubernetes.io/ssl-redirect: 'true'

spec:

ingressClassName: nginx

rules:

- host: app.example.com

http:

paths:

- path: /api

pathType: Prefix

backend:

service:

port:

number: 80

ポリシーがパスごとに異なると、Ingress オブジェクトを分割するか、アノテーションが複雑になることが分かります。

Traefik の実装

apiVersion: v1

kind: Secret

metadata:

type: Opaque

data:

users: dXNlcjokYXByMSRleGFtcGxlaGFzaA==

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

basicAuth:

secret: api-basic-auth

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

rateLimit:

average: 20

burst: 40

apiVersion: traefik.io/v1alpha1

kind: Middleware

metadata:

spec:

redirectScheme:

scheme: https

permanent: true

次にルーティングでミドルウェアをパスごとに組み合わせます。HTTPS リダイレクトは HTTP EntryPoint（web）で、認証とレートリミットはパスごとに適用します。

apiVersion: traefik.io/v1alpha1

kind: IngressRoute

metadata:

spec:

entryPoints:

- websecure

routes:

- match: Host(`app.example.com`) && PathPrefix(`/api`)

kind: Rule

middlewares:

- name: api-auth

- name: ratelimit

services:

- name: api-svc

port: 80

- match: Host(`app.example.com`)

kind: Rule

middlewares:

- name: ratelimit

services:

- name: web-svc

port: 80

tls:

certResolver: letsencrypt

違いは明確です。Traefik ではポリシー（認証、レートリミット、リダイレクト）が再利用可能なオブジェクトに分離されており、ルートで必要なポリシーを組み合わせて付けます。パスごとに異なるポリシーを適用しても Ingress オブジェクトを分割する必要はありません。一方 ingress-nginx は単純なケースではより簡潔ですが、パスごとのポリシー分岐が増えるほどオブジェクト分割とアノテーション累積が避けられません。

運用とチューニング

ingress-nginx の運用ポイント

- **worker-processes / worker-connections**: ConfigMap で NGINX のワーカー設定を調整します。ノードリソースに合わせてワーカー数をチューニングします。

- **proxy バッファ/タイムアウト**: 大容量アップロードや遅いバックエンドへの対応のため、proxy-body-size、proxy-read-timeout などを調整します。

- **reload 頻度の管理**: デプロイが多い場合、エンドポイント変更が Lua の経路で処理されるか確認し、不要な Ingress 変更を減らします。

- **keepalive**: アップストリーム keepalive を調整してコネクション再利用を高めます。

apiVersion: v1

kind: ConfigMap

metadata:

data:

worker-processes: 'auto'

max-worker-connections: '16384'

proxy-body-size: '100m'

upstream-keepalive-connections: '320'

use-gzip: 'true'

Traefik の運用ポイント

- **EntryPoint チューニング**: タイムアウト（readTimeout、writeTimeout、idleTimeout）を EntryPoint 単位で設定します。

- **レプリカと ACME**: 内蔵 ACME を使いながらスケールアウトするには、証明書ストレージ共有の戦略が必要です。HA では cert-manager や外部発行を検討します。

- **プロバイダー throttle**: 設定変更が殺到するときは providersThrottleDuration で更新をまとめて処理します。

- **ダッシュボードのセキュリティ**: 本番環境ではダッシュボードを認証/ネットワークポリシーで必ず保護します。

Traefik 静的設定の一部

entryPoints:

websecure:

address: ':443'

transport:

respondingTimeouts:

readTimeout: 60s

writeTimeout: 60s

idleTimeout: 180s

providers:

kubernetesCRD:

allowCrossNamespace: false

providersThrottleDuration: 2s

落とし穴とトラブルシューティング

運用していて実際にぶつかった落とし穴を整理します。

ingress-nginx でよく出会う落とし穴

- **スニペット注入の無効化**: セキュリティ強化で allow-snippet-annotations がデフォルト無効化される傾向です。スニペットに依存していた設定が突然無視され、障害につながることがあります。アップグレード時に必ず確認します。

- **rewrite-target と正規表現**: rewrite-target とパスキャプチャグループの組み合わせはよくミスを誘発します。pathType と正規表現の動作を正確に理解する必要があります。

- **reload の殺到**: 大規模環境で頻繁なデプロイが reload を誘発し、メモリが揺れ、長寿命コネクションが切れることがあります。

- **CVE 対応**: セキュリティパッチリリースに素早く追随する必要があります。メンテナンスモードの状況で、パッチ周期を運用ポリシーに反映する必要があります。

Traefik でよく出会う落とし穴

- **CRD バージョンの不一致**: traefik.io API バージョンとチャートバージョンが食い違うと IngressRoute が無視されます。CRD のインストールバージョンを常にチャートに合わせます。

- **ACME ストレージの競合**: 複数レプリカで acme.json を共有すると発行の競合が発生します。HA では別の証明書戦略が安全です。

- **クロスネームスペース参照**: ミドルウェアを別のネームスペースから参照するには明示的な許可設定が必要です。デフォルトはブロックです。

- **ダッシュボードの露出**: ダッシュボードを認証なしで外部に露出する事故がよくあります。必ず保護します。

共通のデバッグフロー

コントローラーのログ確認

kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

kubectl logs -n traefik deploy/traefik

実際に適用された設定の確認 (ingress-nginx)

kubectl exec -n ingress-nginx deploy/ingress-nginx-controller -- cat /etc/nginx/nginx.conf

ルート状態の確認 (Traefik ダッシュボードまたは API)

kubectl port-forward -n traefik deploy/traefik 8080:8080

Ingress リソースとイベントの確認

kubectl describe ingress example-ingress

kubectl get events --sort-by=.lastTimestamp

マイグレーションの考慮事項

一方から他方へ移すときに考慮する点です。

- **アノテーション vs CRD のマッピング**: ingress-nginx のアノテーションを Traefik Middleware へ一対一でマッピングしにくい場合があります。rewrite、auth、rate-limit などのポリシーをミドルウェアとして再設計する必要があります。

- **IngressClass による分離運用**: 二つのコントローラーを同時に立ち上げ、IngressClass でトラフィックを段階的に移すと無停止マイグレーションが可能です。

- **TLS インフラの再利用**: cert-manager を使っていたなら、Traefik でも cert-manager が作った Secret をそのまま参照するよう構成すれば、証明書を再発行せずに移せます。

- **Gateway API の同時検討**: マイグレーションするなら、この機会に Ingress ではなく Gateway API へ直行する選択肢も一緒に評価するのが長期的に有利です。

意思決定テーブル

| 状況/要件 | 推奨 |

| --- | --- |

| 標準 Ingress だけで単純なルーティング | ingress-nginx または Gateway API 実装 |

| パスごとに複雑で再利用可能なポリシーが多い | Traefik（Middleware） |

| 無停止の動的ルーティングが頻繁（サーバーレス/マルチテナント） | Traefik |

| 内蔵の自動 TLS とダッシュボードが欲しい | Traefik |

| HA ワイルドカード/DNS-01/社内 PKI 証明書 | ingress-nginx + cert-manager |

| NGINX 運用経験が豊富なチーム | ingress-nginx |

| 新規グリーンフィールドプロジェクト（長期標準志向） | Gateway API を優先検討 |

| セキュリティ運用負担の最小化が最優先 | メンテナンスが活発な選択肢（Traefik/Gateway 実装） |

おわりに

最初に戻りましょう。「Traefik と ingress-nginx のどちらがより良いか」という問いには正解がありません。二つのコントローラーは同じ問題を異なる思想で解きます。

シナリオ別に整理すると次のとおりです。

- **NGINX に慣れていて単純なルーティングが主力のチーム**なら、ingress-nginx は依然として速く慣れた選択です。ただしメンテナンスモードとセキュリティパッチの負担を運用ポリシーに反映する必要があります。

- **パスごとに精緻なポリシー、無停止の動的ルーティング、内蔵の TLS/可観測性**が必要なら、Traefik がより自然に合います。CRD の学習コストを一度支払えば、複雑さを緩やかに扱えます。

- **HA 証明書管理、ワイルドカード、社内 PKI** が核心なら、どのコントローラーを使っても cert-manager を証明書層に置く構成が安定します。

- **2026 年に新たに始めるグリーンフィールドプロジェクト**なら、Ingress API が凍結された事実を直視し、Gateway API ベースの実装を第一候補として検討することをお勧めします。Traefik は Gateway API に対応し、ingress-nginx 陣営も Gateway API 実装へ移行しつつあります。

結局のところ核心は「私たちのチームの運用モデル、要件の複雑さ、そして長期の標準戦略」の交差点で選ぶことです。コントローラーは道具にすぎず、良い選択は道具の優劣ではなく、文脈との適合性から生まれます。

参考資料

- [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/)

- [ingress-nginx アノテーションリファレンス](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)

- [Traefik Proxy 公式ドキュメント](https://doc.traefik.io/traefik/)

- [Traefik Kubernetes IngressRoute プロバイダー](https://doc.traefik.io/traefik/providers/kubernetes-crd/)

- [Gateway API 公式ドキュメント](https://gateway-api.sigs.k8s.io/)

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

- [Helm 公式ドキュメント](https://helm.sh/docs/)

- [Let's Encrypt 公式ドキュメント](https://letsencrypt.org/docs/)