2026年3月、Kubernetesプロジェクトは「Ingress NGINX（ingress-nginx）」のメンテナンスを停止し、引退（retire）させる。Kubernetes Steering Committee と Security Response Committee は2026年1月29日付の声明で、Ingress NGINXが「クラウドネイティブ環境のおよそ半数」にとって重要インフラである一方、引退後はバグ修正もセキュリティパッチも一切提供されない、と強い言葉で移行を促した。運用担当がこの問題を先送りすると、脆弱性が発見された瞬間に「直せない入口（North-Southの要）」を抱えたまま事業を継続する状態になる。

本稿は、Ingress NGINXの引退が意味する技術的リスク、Gateway APIへの移行パス、そしてF5/NGINXやTraefik等の代替コントローラーを選定する際の評価軸を整理し、2026年3月までに現実的に完了させるための移行計画（最小実行単位）を提示する。なお本稿は2026年2月15日時点の公開情報に基づく。

1. 2026年3月に「何が」引退するのか

引退対象は、Kubernetesコミュニティが提供してきたIngressコントローラー kubernetes/ingress-nginx（通称 ingress-nginx、しばしば Ingress NGINX と表記）である。Kubernetesブログは2025年11月11日、「2026年3月まで best-effort で保守し、その後はリリース・バグ修正・セキュリティ更新を提供しない」と明記した。既存デプロイが直ちに動かなくなるわけではないが、引退後はGitHubリポジトリが read-only になり、実質的に“止まった”状態のソフトウェアとして残る。

重要なのは、ここで言う「Ingress NGINX」が、一般名詞の NGINX（Webサーバ/リバースプロキシ）そのものではなく、Kubernetes上でIngressリソースを解釈してNGINX設定を生成・配備するコントローラーである点である。さらに、商用/ベンダー製品の「NGINX Ingress Controller（F5/NGINX）」等とは別系統であり、引退の影響範囲やサポート契約は一致しない（利用者は自組織がどの実装を使っているかを識別する必要がある）。

引退が決まった背景は、単なる「人気の低下」ではない。Kubernetesブログは、長年にわたる慢性的なメンテナー不足（実質1〜2名が休日や業務時間外に対応してきた）、柔軟性のために許容してきた機能（例: snippets系アノテーション）が現在の脅威環境では「深刻なセキュリティ負債」へ転化したことなどを挙げ、エコシステムの安全性を優先して退役させる方針を説明している。

2. 先送りが致命傷になり得る理由（セキュリティと運用）

Ingressコントローラーはインターネット境界に立つことが多い。しかも ingress-nginx はクラスタ内の広範なSecretへアクセスできる構成が一般的であり、侵害時の爆発半径が大きい。2025年3月24日、Kubernetes Security Response Committee は ingress-nginx の重大脆弱性群（CVE-2025-1974 ほか）について、Podネットワーク到達性だけでクラスタ乗っ取りにつながり得る、と警告しつつ、パッチ版（v1.12.1 / v1.11.5）をリリースした。こうした経緯は「境界コンポーネントは、止まった瞬間に“負債”ではなく“未修正の入口”になる」ことを示している。

2026年3月以降、同種の問題が再発した場合、アップストリームはもう修正を提供しない。結果として企業が取れる選択肢は、(1) フォークを自前で保守する、(2) ベンダー/コミュニティの継続保守フォークを採用する、(3) 別実装へ移行する、のいずれかに収束する。実務上、(1) は人員・検証・リリース体制まで含めた継続コストが重く、(3) を軸に置きつつ、移行期限に間に合わない一部を (2) で短期延命する、という組み合わせが現実的になりやすい。

なお、クラウド各社が“自社アドオン範囲に限って”延長サポートを表明するケースもある。例えばAKS Engineering Blogは2025年11月13日、Application Routing add-on に関するIngress NGINXリソースを「2026年11月まで（重大セキュリティパッチのみ）サポートする」と記した。ただしこれは「コミュニティ版 ingress-nginx の延命」ではなく、あくまで特定アドオンのサポート範囲の話であり、汎用的な免罪符にはならない。

3. 移行先の全体像: Gateway APIを中心に、代替コントローラーを現実で選ぶ

結論から言えば、戦略は二層に分けるべきである。

  • API戦略（上位）: アプリが依存する“入口の表現”を、Ingress特有のアノテーション文化から脱却させ、Gateway API（または同等の抽象）へ寄せる。
  • 実装戦略（下位）: どのコントローラー/データプレーンで受けるかは、要件と組織体制で選ぶ（Envoy系、NGINX系、クラウドLB統合など）。

Gateway APIはKubernetes SIG Networkが推進する「Ingressの後継となる、より表現力が高く、役割分離（運用者と開発者の境界）を前提とした」APIである。Kubernetesブログは2025年11月6日、Gateway API v1.4.0（GAリリースチャネル）を紹介し、BackendTLSPolicyや機能宣言（supportedFeatures）などが標準化の方向に進んでいる点を示した。移行の中核をGateway APIに据える利点は、コントローラーの入れ替え（実装の差し替え）を将来にわたりやりやすくすることにある。

一方で、現場の意思決定では「Gateway APIに対応しているか」だけで十分ではない。選定時は少なくとも以下を評価する。

  • 適合性: Gateway APIの標準チャネルへの準拠度（Conformance）と、必要な機能（TLS終端、HTTPヘッダ操作、リトライ/タイムアウト、認証連携、WAF連携等）の提供形態。
  • 運用分離: GatewayClass/Gateway/Routeの役割分離が、組織（平台チームとアプリチーム）にフィットするか。マルチテナンシー（namespace境界）で破綻しないか。
  • データプレーン: NGINX/Envoy/クラウドLB等、性能・mTLS・拡張（フィルタ）・観測性のトレードオフ。
  • リスク管理: 既知の危険な機能（例: 任意設定注入に近い仕組み）をどう封じるか。ポリシー/Admissionで統制できるか。
  • 商用サポート: 監査要件（SLA、責任分界、長期保守）の有無。コミュニティ版の継続性。

この枠組みで見ると、移行先は大別して次の3系統である。

  • Gateway API対応のゲートウェイ実装: Envoy Gatewayなど。標準APIに寄せ、将来の交換可能性を上げる。
  • Ingress代替（Ingressを継続）: Traefik等のIngressコントローラーへ乗り換え、APIは当面Ingressのままにする。短期で移行しやすいが、Ingressアノテーション依存が残る。
  • クラウドLB統合: マネージドKubernetesのL7/L4機能へ寄せ、クラウドの実装に依存する。標準化より運用安定を優先する選択である。

4. Gateway API移行の技術設計: 「二重運用」で事故を減らす

移行の難所は、Ingressの“暗黙”をどれだけ明示化できるかにある。ingress-nginx のアノテーションは強力である一方、機能の出どころが実装依存で、セキュリティ境界を壊しやすい。Gateway APIはその反省として、表現力を上げつつも、役割分離とポリシー適用（どのRouteがどのGatewayにバインドできるか等）を前提に設計されている。

推奨する移行アプローチは「二重運用（parallel run）」である。すなわち、IngressとGateway APIを同時に稼働させ、段階的にトラフィックを切り替える。

  1. 棚卸し: どのIngressがどの機能（TLS、Rewrite、Header、Auth、Rate limit、IP allowlist、Websocket等）に依存しているかを列挙し、アノテーションを分類する。
  2. 表現の置換: Ingressの仕様で表せる部分はHTTPRouteへ機械的に変換し、実装依存の部分は「ポリシー/外部認証/サービスメッシュ/アプリ修正」のどれで代替するか決める。
  3. 二重配備: 既存LB（またはDNS）配下に新Gatewayをぶら下げ、特定ホスト名/パスから新系へ流す。SLO/エラーレート/レイテンシで差分を監視する。
  4. 切替と片付け: 全トラフィックを新系へ移し、Ingress側を段階的に削除する。運用Runbookも同時に更新する。

最小構成の例を示す（実装やフィールドは利用するGatewayコントローラーに依存する）。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge-gw
  namespace: gateways
spec:
  gatewayClassName: example-gateway-class
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: example-com-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: app
spec:
  parentRefs:
  - name: edge-gw
    namespace: gateways
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: app-svc
      port: 80
---

IngressからGateway APIへ移す際、運用上の落とし穴になりやすい点は次の通りである。

  • TLSと証明書: 既存がcert-manager前提なら、Secret参照の責務（どのnamespaceで管理するか）を再設計する。
  • 外部DNS: Gatewayのアドレス取得とDNS同期（external-dns等）をどう連携するか。LBの作り方が変わるため、IaCの更新が必要になる。
  • 実装依存機能の置換: ingress-nginxのsnippets類は、まず“禁止”を検討し、必要なら専用のポリシー機構や外部認証基盤へ逃がす。
  • マルチテナンシー: どのnamespaceのRouteがどのGatewayにバインドできるか（ReferenceGrant等）を設計し、権限境界を壊さない。

5. 2026年3月までに終わらせる移行計画（最小実行単位）

Kubernetes側の公式情報は「2026年3月に引退」であり、日付の詳細は明示されていない。本稿執筆時点（2026年2月15日）では、実質的に“残り数週間”である。従って、計画は大規模刷新ではなく、期限内に安全側へ着地することを目的化すべきである。

  1. 48時間以内: 全クラスタで ingress-nginx の有無を検出し、バージョンと公開範囲（LB、NodePort、内部のみ）を集計する。Kubernetesブログが提示するselectorで確認できる。
  2. 1週間以内: 依存アノテーションを「標準置換可能」「設計が必要」「禁止/削除」の3区分に分け、最優先サービス（売上/顧客影響が最大）から順に移行対象を確定する。
  3. 2週間以内: Gateway APIの採用可否を決める。要件が単純（L7ルーティング中心）ならGateway APIへ。どうしてもIngress前提の運用資産が多い場合は、まずIngress代替へ逃がして期限を切る。
  4. 3〜4週間以内: 二重運用で段階的に切替する。トラフィックをホスト名/パス単位で移し、観測性（4xx/5xx/レイテンシ）で差分を監視する。
  5. 期限前: ingress-nginx を残すクラスタをゼロにする。例外が残る場合は、継続保守フォークやベンダーサポートなど“責任主体が明確な”短期延命策へ切り替え、リスク受容を文書化する。

ポイントは、API（Ingress vs Gateway API）と実装（どのコントローラーか）を分離して意思決定することである。短期の目標は「引退後に未保守ソフトを露出させない」こと、長期の目標は「実装差し替え可能な表現（Gateway API）へ寄せ、入口の技術負債を減らす」ことである。

FAQ

Q1. 2026年3月に、既存のIngressは突然動かなくなるのか

直ちに動かなくなるわけではない。Kubernetesブログは、既存デプロイは機能し続け、既存のHelm chartやイメージ等のアーティファクトも残ると説明している。ただし、引退後は修正やセキュリティ更新が提供されないため、運用リスクは時間とともに増大する。

Q2. 「Ingress NGINX」と「NGINX Ingress Controller（F5/NGINX）」は同じか

同じではない。本稿の引退対象はKubernetesコミュニティの ingress-nginx（kubernetes/ingress-nginx）である。商用/別配布のNGINX系コントローラーは別プロジェクトであり、サポートやEOLは個別に確認が必要である。

Q3. Gateway APIへ移行すれば将来も安泰か

APIが標準化されるほど、実装差し替えの自由度は上がる。一方で、実装（Gatewayコントローラー）の成熟度や対応機能は製品ごとに異なる。Gateway API採用は「設計の持続性」を上げる選択であり、実装選定と運用統制（ポリシー、権限分離、観測性）は別途必要である。

Q4. 期限に間に合わない場合、フォークの採用は現実的か

短期延命としては現実的になり得る。例えばChainguardは2025年12月22日、EmeritOSSプログラムで ingress-nginx を継続保守するフォーク方針を公開した。ただし、フォーク採用は「移行をしない理由」ではなく、「移行を完了させるまでの時間を買う策」と位置づけるべきである。

Q5. ingress-nginx の危険なアノテーション（snippets等）はどう扱うべきか

まず必要性を再評価し、原則として禁止・削除を検討する。それでも必要な場合は、Gateway APIの標準機能や、外部認証、ポリシー機構（実装依存）へ移す。任意設定注入に近い仕組みを境界に置き続けることは、脅威モデル上の負債になりやすい。

参考文献