Traefik vs ingress-nginx — 何をいつ選ぶか

• はじめに
• 二つのコントローラーのアイデンティティ
  • ingress-nginx — 実績ある NGINX の上の薄い制御層
  • Traefik — クラウドネイティブのために最初から設計されたプロキシ
• 設計思想の比較
• 設定方式 — アノテーション vs CRD/ミドルウェア
  • ingress-nginx のアノテーションモデル
  • Traefik の CRD と Middleware モデル
• 自動 TLS
  • Traefik の内蔵 ACME
  • ingress-nginx + cert-manager
• 性能とリソース
• 動的設定と reload の違い
  • ingress-nginx の reload モデル
  • Traefik の無停止反映
• 可観測性
  • Traefik の内蔵可観測性
  • ingress-nginx の可観測性
• エコシステムとガバナンス
  • Gateway API との関係
  • メンテナンス状態とセキュリティ
• 学習曲線
• 同一要件の実装比較
  • ingress-nginx の実装
  • Traefik の実装
• 運用とチューニング
  • ingress-nginx の運用ポイント
  • Traefik の運用ポイント
• 落とし穴とトラブルシューティング
  • ingress-nginx でよく出会う落とし穴
  • Traefik でよく出会う落とし穴
  • 共通のデバッグフロー
• マイグレーションの考慮事項
• 意思決定テーブル
• おわりに
• 参考資料

はじめに

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 は「強力で慣れたエンジンを Kubernetes に接続する」ことに集中し、Traefik は「Kubernetes の宣言型モデルにプロキシ自体を同化させる」ことに集中します。

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

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

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

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app
  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:
                name: web-svc
                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:
  name: rate-limit
spec:
  rateLimit:
    average: 20
    burst: 40
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: custom-header
spec:
  headers:
    customRequestHeaders:
      X-Custom: hello
---
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: web-app
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:
  name: secure-app
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:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            class: nginx
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-app
  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:
                name: secure-svc
                port:
                  number: 80

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

性能とリソース

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

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]
                            |
                            v
                  新しい nginx.conf 生成（テンプレート）
                            |
                            v
                  NGINX reload (nginx -s reload)
                            |
                            v
                  新しいワーカープロセスが新設定を適用

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

Traefik の無停止反映

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

[K8s API] --watch--> [Traefik provider]
                            |
                            v
                  動的設定の更新（メモリ）
                            |
                            v
                  ルーティングテーブルの原子的スワップ
                            |
                  （コネクション影響なし、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 は標準 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:
  name: api-basic-auth
type: Opaque
data:
  # htpasswd で生成したユーザー/パスワード（base64）
  auth: dXNlcjokYXByMSRleGFtcGxlaGFzaA==
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  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:
                name: api-svc
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-api-auth
  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:
                name: api-svc
                port:
                  number: 80

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

Traefik の実装

apiVersion: v1
kind: Secret
metadata:
  name: api-basic-auth
type: Opaque
data:
  users: dXNlcjokYXByMSRleGFtcGxlaGFzaA==
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: api-auth
spec:
  basicAuth:
    secret: api-basic-auth
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: ratelimit
spec:
  rateLimit:
    average: 20
    burst: 40
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: https-redirect
spec:
  redirectScheme:
    scheme: https
    permanent: true

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

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: example-route
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:
  name: ingress-nginx-controller
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 へ直行する選択肢も一緒に評価するのが長期的に有利です。

意思決定テーブル

おわりに

最初に戻りましょう。「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 公式ドキュメント
• Kubernetes Ingress Controllers の概要
• ingress-nginx 公式ドキュメント
• ingress-nginx アノテーションリファレンス
• Traefik Proxy 公式ドキュメント
• Traefik Kubernetes IngressRoute プロバイダー
• Gateway API 公式ドキュメント
• cert-manager 公式ドキュメント
• Helm 公式ドキュメント
• Let's Encrypt 公式ドキュメント