Kubernetes生態系の根幹を支えてきたIngress NGINX Controllerが、2026年3月31日をもって完全に引退する。Datadogの調査によればクラウドネイティブ環境の約50%がこのコントローラーに依存しており、影響範囲はKubernetes史上最大級である。本記事ではテクノロジーの視点から、この引退が単なるコンポーネントの世代交代ではなく、KubernetesエコシステムにおけるOSS統治モデルの構造転換と技術的負債の一斉清算であることを分析する。Ingress NGINX引退の基本経緯を踏まえた上で、実装レベルの移行設計と、背後にある生態系の力学変化を解説する。

1〜2名のボランティアが支えた「50%のインフラ」── OSS統治モデルの限界

Ingress NGINX Controllerは、Kubernetes SIG Networkの管理下にあるコミュニティプロジェクトである。しかしその実態は、わずか1〜2名のボランティアメンテナーが余暇時間で維持していた。2025年11月11日にKubernetes SIG NetworkとSecurity Response Committeeが公式に引退を発表し、2026年1月29日にはKubernetes Steering Committeeが正式声明を出した。

問題の本質は、クリティカルパス上のインフラコンポーネントがコミュニティの善意に依存していたという統治構造にある。RKE2、IBM Cloud、Alibaba ACKがデフォルトでIngress NGINXを同梱しており、1,000万回以上ダウンロードされたこのコントローラーの保守を、事実上2人が担っていた。これはOSSの持続可能性の問題であると同時に、Kubernetesエコシステム全体のガバナンス設計の欠陥である。

筆者は過去に全国規模のセキュリティサービスで技術主任を務めた経験があるが、「止められないという制約が技術的判断の全てを支配する」環境において、メンテナーが1〜2名という状態は設計上のSPOF（単一障害点）そのものである。Ingress NGINXの引退は、このSPOFが顕在化した結果に過ぎない。

対照的に、F5/NGINX Inc.が開発する商用NGINX Ingress Controller（nginxinc/kubernetes-ingress）は専任チームによるフルタイム開発を続けている。コミュニティ版と商用版は名前こそ似ているが、コードベースも設計思想も完全に別物である。この混同が移行現場で深刻な混乱を生んでいる。

比較項目コミュニティ版（kubernetes/ingress-nginx）商用版（nginxinc/kubernetes-ingress）
メンテナンス2026年3月終了（ボランティア1〜2名）F5専任チームが継続開発
ベースNGINX Open SourceNGINX OSS / NGINX Plus（商用）
設定方式Ingress + アノテーション（オーバーロードリスク）CRD（VirtualServer, Policy）
高度な機能限定的カナリア、A/Bテスト、JWT検証、mTLS
Gateway API対応なし（後継なし）NGINX Gateway Fabricとして移行パスあり
市場シェア約50%（引退予定）約40%（継続開発中）

セキュリティパッチ停止が意味するもの ── CVE-2025-1974からCVE-2026-24512への脆弱性連鎖

引退後の最大リスクは、セキュリティパッチの完全停止である。Ingress NGINXは近年、致命的な脆弱性が連続して発見されている。

CVE深刻度時期影響
CVE-2025-1974（IngressNightmare）CVSS 9.82025年未認証RCE＋全名前空間シークレット漏洩
CVE-2026-24512CVSS 8.82026年パス設定インジェクションによる任意コード実行
CVE-2026-1580Medium2026年auth-urlアノテーションの入力検証不備
CVE-2026-24514Medium2026年DoS脆弱性

特にCVE-2025-1974（通称IngressNightmare）はCVSS 9.8という最高レベルの深刻度で、認証なしにコントローラーでリモートコード実行が可能であった。2026年に入ってからもCVE-2026-24512（CVSS 8.8）が発見され、rules.http.paths.pathフィールドを通じた設定インジェクションでクラスタ全体の掌握が可能となる。

2026年3月31日以降、これらの脆弱性パターンに類似する新たなCVEが発見されても、パッチは提供されない。L7データパスに位置するIngress Controllerは、クラスタに入るすべてのHTTPトラフィックを処理するため、攻撃面は極めて広い。筆者は脆弱性診断の実務経験から、「プロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になり得る」ことを痛感しているが、Ingress NGINXのアノテーションベースの設定は、まさにそのリスクの温床であった。

コンプライアンスの観点でも影響は深刻である。2026年2月のサイバー攻撃面分析で指摘した通り、パッチラグが常態化する中でEOLソフトウェアをL7パスに残すことは、SOC 2、PCI-DSS、ISO 27001のいずれにおいても自動的な監査指摘事項となる。Azure AKS Application Routingは2026年11月までの延長サポートを表明しているが、これは例外的措置であり、大多数の環境では即座にリスクが顕在化する。

Gateway APIの設計思想 ── アノテーション地獄からロールベースガバナンスへ

Gateway APIは、従来のIngress APIの後継としてKubernetes SIG Networkが策定した公式仕様である。HTTPRoute、GatewayClass、GatewayのコアリソースはすでにGA（一般提供）ステータスに達しており、2025年10月にはv1.4.0がリリースされた。サービスメッシュとの統合を担うGAMMAイニシアチブもGA化している。

Ingress APIとGateway APIの設計思想の根本的な違いは、ロール分離にある。

設計要素Ingress APIGateway API
設定方式アノテーション（プロバイダ固有・非型安全）スキーマバックドCRD（型検証あり）
ロール分離なし（単一オーナー）インフラ提供者・クラスタ運用者・アプリ開発者の3層
ルーティング基本的なパス・ホストベースヘッダベースマッチング、トラフィック分割、リクエストミラーリング
プロトコルHTTP(S)中心HTTP/HTTPS、gRPC、TCP、UDP、TLS
マルチテナント困難（名前空間ごとに1 Ingress）複数の独立ルートが同一Gatewayにアタッチ可能
高度な機能プロバイダ固有アノテーションに依存カナリアデプロイ、A/Bテスト、JWT検証、レート制限をネイティブサポート

Ingress APIの最大の技術的負債は「アノテーション地獄」である。NGINX固有の機能を利用するにはnginx.ingress.kubernetes.io/プレフィックスのアノテーションを大量に付与する必要があり、これらはスキーマ検証がない文字列である。設定ミスはapply時に検出されず、ランタイムで初めて発覚する。Gateway APIはCRDベースの設計によりこの問題を構造的に解決し、kubectl applyの段階で型検証を実行する。

さらに重要なのは、Gateway APIの3層ロールモデルがKubernetesのマルチテナント運用に適合している点である。GatewayClassはインフラ提供者が定義し、Gatewayはクラスタ運用者が管理し、HTTPRouteはアプリ開発者が自律的に設定する。この分離により、Platform Engineeringが推進するセルフサービス型のインフラ提供モデルと自然に整合する。

ingress2gatewayの実態 ── 自動移行ツールの能力と限界

Kubernetes SIG-Networkが提供するingress2gatewayは、IngressリソースをGateway APIリソースに変換する公式ツールである。APISIX、Cilium、ingress-nginx、Istio、GCE、Kongなど主要プロバイダをサポートし、YAMLまたはJSONのマニフェストファイル、あるいは稼働中のクラスタから直接リソースを読み取って変換を実行する。

しかし、このツールには明確な限界がある。

変換されるもの:

  • 標準的なIngressリソースのホスト・パスルーティング
  • TLS設定（Secret参照）
  • 基本的なバックエンドサービス参照

変換されないもの:

  • プロバイダ固有のアノテーション（nginx.ingress.kubernetes.io/*の大半）
  • カスタムメタデータ
  • Snippets（NGINXの生設定埋め込み）
  • レート制限、認証、CORSなどのミドルウェア設定
  • セッションアフィニティ設定

つまり、ingress2gatewayは「スケルトン変換器」であり、完全な移行ツールではない。実運用環境では、アノテーションで実装していたミドルウェア層の設定を、Gateway APIのBackendTrafficPolicy、SecurityPolicy、あるいはGateway実装固有のCRDに手動で再実装する必要がある。

推奨される移行ワークフローは以下の通りである:

  1. インベントリ作成: 全Ingressリソースとアノテーションの棚卸し
  2. ingress2gateway実行: スケルトンのGateway APIマニフェストを生成
  3. ギャップ分析: 変換されなかったアノテーション・設定の一覧化
  4. 手動再実装: Gateway実装固有の方法でミドルウェア設定を再構築
  5. 並行運用: Ingress NGINXとGateway APIコントローラーを同一クラスタで並行稼働
  6. 段階的切替: トラフィックを段階的にGateway APIに移行
  7. 検証・完了: E2Eテストの通過後にIngress NGINXを撤去

筆者の経験上、レガシーシステムの刷新では「既存ロジックの暗黙知をいかに可視化するかが最大の課題」である。Ingress NGINXのアノテーションに埋め込まれたルーティングロジックは、まさにこの暗黙知に該当する。特にSnippetsを多用している環境では、NGINXの生設定がIngressリソース内に散在しており、これを体系的に棚卸しする作業は想像以上に工数がかかる。

Gateway API実装の選定 ── Envoy Gateway・Istio・Cilium・NGINX Gateway Fabricの実装比較

Gateway APIは仕様であり、実装は複数のプロジェクトが提供している。主要な選択肢を比較する。

実装データプレーン特徴適用シナリオ
Envoy GatewayEnvoy ProxyGateway API専用設計、豊富なポリシーCRD、即時設定反映純粋なIngress置換、新規構築
IstioEnvoy（Ambient: ztunnel + Waypoint）サービスメッシュ統合、GAMMA GA、最低CPU消費（Ambientモード）サービスメッシュ導入済み・検討中の環境
CiliumeBPF + Envoy（L7）CNI統合、ネットワークポリシー連携、eBPFによるL4高速処理Cilium CNI採用済みの環境
NGINX Gateway FabricNGINXNGINXベース、F5公式サポート、NGINX Ingressからの移行パスありNGINX運用ノウハウを活かしたい環境
KongNGINX/OpenRestyAPI管理機能統合、プラグインエコシステムAPIゲートウェイ統合が必要な環境

パフォーマンスの観点では、IstioのAmbientモードが最もCPU効率が高い。Envoy Gatewayはその約2.9倍、Ciliumは約7.5倍のCPU消費となる。ただしCiliumはeBPFによるL4処理で圧倒的なスループットを誇るため、L7ポリシーの複雑さに応じて最適解は変わる。

Kubernetes 1.34/1.35のeBPF統合が進む中、CiliumのGateway API実装はCNI・ネットワークポリシー・Ingressを単一のコントロールプレーンに統合できる点で、運用複雑性の削減に寄与する。一方、サービスメッシュへの段階的移行を視野に入れるなら、IstioのGAMMAイニシアチブによるGateway API統合が最も自然な選択肢となる。

NGINX Gateway FabricはF5が公式に提供するGateway API実装であり、既存のNGINX Ingress Controller（商用版）からの移行ドキュメントとツールが整備されている。コミュニティ版Ingress NGINXからの直接移行パスは公式には提供されていないが、NGINXの設定ノウハウを持つチームにとっては学習コストの最も低い選択肢である。

並行運用設計と技術的負債の清算戦略

2026年3月31日のデッドラインまで残りわずかである。現実的な戦略は、ビッグバン移行ではなく並行運用を前提とした段階的移行である。

並行運用のアーキテクチャ:

  • Ingress NGINXとGateway APIコントローラーを同一クラスタで稼働させる
  • 新規サービスはGateway APIで構築し、既存サービスは順次移行
  • IngressClassとGatewayClassによるトラフィック分離を実施
  • DNS切替またはロードバランサーレベルでの段階的トラフィック移行

移行優先度の判断基準:

  1. 最優先: 外部公開かつ機密データを扱うサービス（セキュリティリスク最大）
  2. 高優先: Snippetsアノテーションを使用しているIngress（技術的負債の温床）
  3. 中優先: カスタムアノテーションが少ない標準的なIngress（ingress2gatewayで大部分変換可能）
  4. 低優先: 内部専用サービス（攻撃面が限定的）

注意すべきは、並行運用期間中もIngress NGINXはセキュリティパッチが停止した状態で稼働し続ける点である。並行運用は移行の安全性を高めるが、EOLコンポーネントの稼働期間を延長するリスクとのトレードオフでもある。Azure AKSのように2026年11月まで延長サポートがある環境を除き、並行運用期間は最長でも3ヶ月を目安とすべきである。

この強制移行は、Broadcom×VMware買収が引き起こしたインフラ強制移行と構造的に類似している。両者に共通するのは、「依存先の一方的な決定により、利用者側が短期間での技術的判断を迫られる」という非対称性である。ただしIngress NGINXの場合、移行先のGateway APIが上位互換であるという点で、技術的には前向きな清算と言える。

Kubernetesエコシステムは、この引退劇を通じて重要な教訓を得ることになる。クリティカルパス上のコンポーネントは、個人の善意ではなく、持続可能な組織体制で支えなければならない。Gateway APIの標準化は、この教訓を仕様レベルで制度化する試みである。

FAQ

Ingress NGINX Controllerは2026年3月31日以降も動作するか？

動作する。既存のコンテナイメージとHelmチャートは引き続き利用可能である。ただし、セキュリティパッチ・バグフィックスは一切提供されない。新たな脆弱性が発見されても修正されないため、攻撃者にとっては格好の標的となる。SOC 2やPCI-DSSの監査ではEOLソフトウェアとして自動的に指摘事項となる。

コミュニティ版Ingress NGINXと商用NGINX Ingress Controllerの違いは何か？

コミュニティ版（kubernetes/ingress-nginx）はKubernetes SIG Network管理のOSSプロジェクトで、2026年3月に引退する。商用版（nginxinc/kubernetes-ingress）はF5/NGINX Inc.が開発する別製品で、NGINX PlusベースのエンタープライズサポートとGateway API移行パス（NGINX Gateway Fabric）を提供する。コードベースは完全に別である。

ingress2gatewayツールで完全に移行できるか？

できない。ingress2gatewayは基本的なホスト・パスルーティングとTLS設定のみを変換する。プロバイダ固有のアノテーション（レート制限、認証、CORS、Snippetsなど）は手動での再実装が必要である。ツールは移行の出発点であり、完了点ではない。

Gateway API実装はどれを選ぶべきか？

環境依存で最適解は異なる。Cilium CNI採用済みならCilium Gateway API、サービスメッシュ導入済み・予定ならIstio、新規構築ならEnvoy Gateway、NGINX運用ノウハウを活かしたいならNGINX Gateway Fabricが推奨される。パフォーマンス最優先ならIstio Ambientモードが最もCPU効率が高い。

移行期間はどの程度を見込むべきか？

環境の複雑さによるが、中規模クラスタ（Ingressリソース50〜100件）で1〜3ヶ月が目安である。アノテーション棚卸し（1〜2週間）、ingress2gateway変換とギャップ分析（1〜2週間）、手動再実装（2〜4週間）、並行運用テスト（2〜4週間）を想定する。Snippetsを多用している環境ではさらに期間を要する。

参考文献