2026.07.27 インフラ

NGINX Ingressとは？退役したingress-nginxとF5版の違い・移行判断

「NGINX Ingress」という呼び名は、別々の2つのプロダクトに使われています。ひとつはKubernetesコミュニティが開発してきた kubernetes/ingress-nginx で、2026年3月に退役し、リポジトリは同月24日にアーカイブされました。もうひとつはF5のNGINX Ingress Controllerで、2026年7月16日の5.5.4まで版を重ねている商用製品です。動いているのがどちらかで、いま取るべき行動は正反対になります。両者の見分け方と移行の実際をたどります。

まとめ：NGINX Ingressの2つの実装と2026年3月退役後の進路

最初に確認するのは、クラスタで動いているコントローラーの出自です。kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx でPodが返るなら、それは退役したコミュニティ版だと判断できます。Kubernetes Steering CommitteeとSecurity Response Committeeは2026年1月29日の共同声明で、退役後も使い続ける選択は「あなたと利用者を攻撃に晒す」と明言しました。

進路は2つです。Gateway APIの実装へ移るか、F5のNGINX Ingress Controllerへ横移動するか。前者は工数が大きい代わりに標準APIへ収束し、後者はNGINX由来の設定を残せる代わりに商用サポート契約とアノテーション書き換えが発生します。

着手はどちらも同じです。ingress2gateway 1.0でIngressを変換にかけ、翻訳できない設定を洗い出してください。ここで挙がる量が、移行工数の見積もり根拠になります。

NGINX Ingressが指す2つの実装｜コミュニティ版とF5版の違い

混同が起きるのは、どちらもNGINXをデータプレーンに使い、ingressClassNameに nginx を指定する運用が広まっていたためです。

コミュニティ版ingress-nginxの開発体制と最終版1.15.1

kubernetes/ingress-nginxは、Kubernetesプロジェクト配下で開発されてきたIngressコントローラーです。NGINXの設定ファイルを動的に生成し、L7の振り分けを担います。振り分け方式そのものの前提はロードバランサーの仕組みと種類・振り分け方式の解説で整理しています。

リリース履歴は2026年3月9日のcontroller-v1.15.0、3月19日のcontroller-v1.15.1・v1.14.5・v1.13.9で止まりました。リポジトリは3月24日にアーカイブされ、1.15.1が事実上の最終版です。退役の理由は技術面ではありません。Steering Committeeの声明によれば保守は1〜2名の空き時間に依存しており、一方でDatadogの調査ではクラウドネイティブ環境の約50%がこのコントローラーに依存していたとされます。

F5版NGINX Ingress ControllerのNGINX Plus依存機能

F5のNGINX Ingress Controller（リポジトリはnginx/kubernetes-ingress）は商用製品として保守が続いています。2026年7月16日の5.5.4はF5 WAFを5.13.4へ更新した版で、前日の5.5.3ではNGINX Plus R37.0.3.1とNGINX OSS 1.31.3を取り込みました。5月29日の5.5.0では外部認証、WAFのIP Intelligence、mTLSが入っています。

注意したいのは機能の二層構造です。NGINX OSSベースでも動きますが、JWT検証やアクティブヘルスチェックはNGINX Plusのサブスクリプションが前提になります。「F5版へ移れば同等以上」と考えて計画を立てると、Plus前提の機能を無償版で使えず設計をやり直す羽目になります。7月15日の5.5.2がテンプレートインジェクションの緊急修正だったように、この種の修正が今後も出る点が退役版との決定的な差です。

アノテーション接頭辞の非互換とnginx.org形式への書き換え範囲

両者を分ける最も実務的な差はアノテーションの接頭辞です。コミュニティ版は nginx.ingress.kubernetes.io/ で始まる名前を使い、F5版は nginx.org/ と nginx.com/ の2系統を使います。名前空間が違うだけでなく、対応する設定項目も一対一ではありません。

F5版では nginx.org/ がNGINX OSSとNGINX Plusの双方で効き、nginx.com/ はPlus限定です。nginx.org/proxy-connect-timeout、nginx.org/client-max-body-size、nginx.org/ssl-redirect はOSSでも使えますが、nginx.com/jwt-key と nginx.com/health-checks はPlus専用です。さらにF5版は、Ingressを超えた設定をVirtualServerやVirtualServerRouteという独自CRDで表現します。機械的な置換が効くのは単純な設定までだと見ておいてください。

IngressリソースとコントローラーをつなぐingressClassNameの仕組み

どこが書き換え対象になるかは、Ingressリソースとコントローラーの責務の分かれ目で決まります。

Ingressリソースが標準で担う範囲とアノテーション拡張の限界

Ingressリソースが持つ情報は素朴です。どのホスト名の、どのパスへ来たリクエストを、どのServiceのどのポートへ渡すか。あとはTLS証明書を格納したSecretの名前。標準APIの規定はおおむねこの範囲に限られます。

タイムアウト、ボディサイズ上限、書き換え、CORS、認証といった実務で必要な設定はすべて標準の外にあり、各コントローラーがアノテーションで独自に拡張してきました。この「標準が薄く拡張が厚い」構造がIngressの移植性を下げ、Gateway APIが作られる動機になっています。クラスタ内でIngressがServiceやPod間通信とどう噛み合うかはKubernetesネットワーク設計におけるService・Ingress・CNI選定の判断で扱っています。

pathTypeとingressClassNameに残る実装依存の設定の見分け方

ingressClassName フィールドは、そのルールをどのコントローラーが処理するかを指定します。この仕組みがあるため、移行を一括切り替えにする必要はありません。新旧2つのコントローラーを同一クラスタで動かし、Ingressを1本ずつ付け替えていけます。古い kubernetes.io/ingress.class アノテーションで指定している定義は、下準備としてフィールド形式へ寄せてください。

pathType には Prefix、Exact、ImplementationSpecific の3つがあり、前2つは仕様で挙動が決まっています。問題はImplementationSpecificで、文字どおりコントローラー任せのため、同じマニフェストでも実装を替えると振り分けが変わります。コミュニティ版では正規表現的な解釈が入り、それを前提にした設定が現場に大量に残りました。棚卸しはここから着手してください。PrefixとExactだけで書かれたものは変換ツールでほぼそのまま通ります。

ingress-nginx退役の経緯と2026年3月アーカイブ後の運用リスク

退役は突然決まったものではなく、2025年秋から段階的に告知されてきました。

2025年11月の退役告知から2026年3月24日のアーカイブまでの経緯

最初の告知は2025年11月12日のKubernetes Contributorsブログでした。2026年3月に保守を停止して退役させること、以後はリリースもバグ修正も脆弱性への対応も行わないこと、既存のデプロイは動き続け配布物も残ることが示されています。

後継として立ち上がっていたInGateについても、同じ告知で「成熟した代替に至らなかったため退役する」と結論が出ました。移行先候補にInGateを置いていたなら、その計画は白紙にしてください。2026年1月29日に両委員会の共同声明、3月19日に最終リリース群、3月24日にリポジトリのアーカイブという順で進みました。

CVE-2025-1974が示した管理コンポーネントの攻撃面と教訓

共同声明が引き合いに出した過去の事例が CVE-2025-1974 です。ingress-nginxのアドミッションコントローラーに起因する脆弱性で、公開時には広範な影響が指摘されました。

この一件が示したのは、Ingressコントローラーがクラスタの入口であると同時に、それ自体が高い権限を持つ管理コンポーネントだという事実です。Secretの読み取り権限を持ち、全名前空間のIngressを監視し、クラスタ内への経路を持ちます。破られたときの被害は入口だけに留まりません。退役したソフトウェアを入口に置き続ける判断が、通常のライブラリの塩漬けと危険度が違うのはそのためです。

退役後に新たなCVEが出た場合に残る3つの選択肢と実際のコスト

アーカイブ後に脆弱性が見つかったとき、選べる道は3つです。第一に、自前でフォークを維持する道。C言語のNGINXモジュール、Goのコントローラー、Luaのランタイムが絡む構成を読み解き、パッチを当ててビルドし、自組織のレジストリで配布し続ける体制が要ります。常設できるのは社内にプラットフォームチームを抱える規模の組織だけです。

第二に、修正せず運用を続ける道。これは声明が名指しで否定した選択で、監査やセキュリティ調達要件がある事業では通りません。残る第三の移行が実質唯一の現実解です。フォーク維持を検討する場合も、人件費と移行工数を並べて比べてください。

移行先4種の比較｜F5版・Gateway Fabric・Envoy系・Cilium

移行先は「Ingress APIのまま別コントローラーへ移る」か「Gateway APIへ移る」かで二分されます。

F5版へ横移動する場合の設定書き換え範囲と商用ライセンスの扱い

Ingress APIを維持したまま移るなら、F5のNGINX Ingress Controllerが最も設定資産を引き継ぎやすい選択です。NGINXの設定モデルが同じなので、proxy系のタイムアウトやボディサイズ上限は接頭辞の置換で通ります。

引き継げないものもはっきりしています。canaryリリース系のアノテーション、configuration snippets、Lua依存の拡張はそのままでは動かず、VirtualServerリソースの機能へ読み替えるか要件を見直すことになります。ライセンスも先に決めてください。NGINX OSSベースなら無償ですが、JWT検証やアクティブヘルスチェックはNGINX Plus契約が前提です。既存設定でこれらを使っていたなら、横移動は実質的な有償化を意味します。

Gateway API実装へ移る場合のHTTPRouteとGatewayの分離

Gateway APIは、Ingressが1つのリソースに詰め込んでいた責務を役割ごとに分割したAPIです。インフラ担当がGatewayでリスナーと証明書を定義し、アプリ担当が HTTPRoute で経路を定義します。名前空間をまたぐ参照はReferenceGrantで明示的に許可する形です。

仕様の成熟も進みました。v1.4.0は2025年10月6日にGAとなりBackendTLSPolicyがStandardチャネルへ入り、2026年2月27日のv1.5ではListenerSet、TLSRoute、CORSフィルタ、クライアント証明書検証、ReferenceGrantがStandardへ移っています。ListenerSetにより1つのGatewayに64を超えるリスナーを載せる構成も標準になりました。

実装の選択肢は広く、F5のNGINX Gateway Fabric（2.6系・Gateway API v1.5.1対応・2026年7月時点）、Envoy Gateway、kgateway、Istio、そしてCNI側で完結させるeBPFベースのCilium CNIの仕組みとCalico比較のGateway API実装があります。振り分け自体をNGINX以外へ寄せるなら、HAProxyのL4／L7ロードバランサーとしての設定とnginxとの違いも比較対象に入ります。

移行先4種の比較表｜運用主体・API種別・既存設定資産の引き継ぎ

代表的な移行先を、判断に効く軸だけで並べます。

移行先 API 運用主体 NGINX設定の引き継ぎ 費用
F5 NGINX Ingress Ingress＋独自CRD F5（商用） 接頭辞の置換で大半可 Plus機能は有償
NGINX Gateway Fabric Gateway API F5（OSS） 書き直し 無償（WAFは別）
Envoy Gateway・kgateway Gateway API CNCF系OSS 書き直し 無償
Cilium Gateway API Gateway API CNCF卒業プロジェクト 書き直し 無償

NGINX由来の設定を残したいだけならF5版、データプレーンを問わず標準へ寄せたいならGateway API実装という切り分けになります。すでにCiliumをCNIに採っているクラスタなら、コントローラーを1つ減らせるCilium Gateway APIが構成上は最も素直です。

ingress2gateway 1.0による移行手順と翻訳できない設定

Gateway APIへ移ると決めたら、手作業でHTTPRouteを書き起こす前に変換ツールを通してください。

ingress2gateway 1.0が変換する30種超のアノテーション

ingress2gatewayはKubernetes公式が提供する移行支援ツールで、2026年3月20日に1.0がリリースされました。1.0未満ではIngress-NGINXのアノテーションを3種類しか解釈できませんでしたが、1.0で30種類超へ拡大しています。

対応が入ったのはCORS、バックエンドTLS、正規表現マッチ、パス書き換え、proxy body size、proxy timeouts、configuration snippetsといった頻出の設定群です。IngressをGatewayと HTTPRoute の組へ変換し、変換できなかった設定は翻訳不能として提示したうえで代替案を出します。公式も一発置換ではなく補助役と位置づけているため、出力をそのまま適用せず、翻訳不能項目を1つずつ設計判断にかけてください。

変換コマンドの実行順とprint出力を検証する手順の組み立て方

安全に進めるなら、次の順序で回します。

  1. 対象名前空間のIngressを棚卸しし、pathTypeがImplementationSpecificのものに印を付ける
  2. ingress2gateway をprintモードで実行し、生成されるGatewayとHTTPRouteを標準出力で確認する
  3. 翻訳不能として報告された設定を一覧化し、要件として残すか捨てるかを判断する
  4. 新コントローラーを別のingressClassName（またはGatewayClass）で並行稼働させる
  5. 経路を1本ずつ切り替え、応答コードとレイテンシを見ながら旧Ingressを削除する

切り替え中は新旧の経路が同時に生きます。監視側でどちらを通ったか判別できるようにしておくと、障害時の切り分けが速くなります。

use-regex指定の前方一致と大文字小文字の扱いで壊れる経路の例

変換ツールが構文的に正しい出力を返しても、挙動が変わる箇所があります。Kubernetes公式が2026年2月27日に注意喚起した筆頭が、nginx.ingress.kubernetes.io/use-regex を true にしたときの挙動です。

この設定下では、正規表現は完全一致ではなく前方一致で評価され、しかも大文字小文字を区別しません。公式が挙げた例では、3文字の大文字だけに一致させるつもりで書いた /[A-Z]{3} が /uuid にも /UuId にも一致します。

Gateway APIのRegularExpression型のパスマッチは、IstioやEnvoy Gatewayといった主要実装で完全一致かつ大文字小文字を区別します。これまで意図せず拾えていたリクエストが移行後に落ちるということです。use-regexを使っているIngressは、変換前にアクセスログから実パスを抽出し、新旧どちらでも同じ経路に乗るかを突き合わせてください。飛ばすと、切り替え直後に一部のURLだけ404になる形で表面化します。

移行先を決める4つの判断基準と、退役版を当面残してよい条件の線引き

ここからは条件を示したうえで結論を書きます。

Gateway APIへ直行すべき条件とF5版へ横移動すべき条件

Gateway APIへ直行してください。該当するのは、Ingressの本数が概ね30本以内、canaryやconfiguration snippetsといった独自拡張を使っていない、クラスタの作り直し予定が2年以内にない場合です。この条件なら変換ツールの出力がほぼ通り、標準APIへ収束させる利点が移行工数を上回ります。

F5版へ横移動すべきなのは、Ingressが100本を超え全社の入口を兼ねている、NGINX Plusの機能を既に使っている、監査要件で商用サポート窓口が必須、のいずれかに当てはまる場合です。どれかがあるなら一足飛びは避け、まずIngress APIのまま保守されている実装へ退避するほうが安全です。

逆に、見送るべき組み合わせもあります。NGINX Plusを契約する予定がないのにF5版へ横移動する構成は勧めません。使えない機能を前提にした設計が残り、二度目の移行が発生します。無償で行くなら最初からGateway API側を選んでください。

ingress-nginxの移行を急がなくてよい唯一の場面と期限の置き方

急がなくてよい場面は1つだけです。そのクラスタが外部公開されておらず、社内ネットワークからのみ到達可能で、かつクラスタ自体を1年以内に廃止する予定が確定している場合。攻撃面が閉じており寿命も切れているなら、移行工数を投じる合理性がありません。

この例外に当てはまらないなら、期限を先に切ってください。目安は退役から1年となる2027年3月です。それ以降も残す判断をするなら、脆弱性が公表された時点で誰が判断し何時間で遮断するかを運用手順として文書化する必要があります。「様子を見る」は手順ではありません。インターネットに面したクラスタなら、期限を待たずに着手してください。

Ingress移行を外部委託する際に見積もりで確認すべき項目5点

社内に手が空かず外部へ出す場合、見積書で確認すべき項目は決まっています。Ingressの棚卸し本数と、そのうちImplementationSpecificおよびuse-regexを使っている本数。翻訳不能アノテーションの扱い（代替設計まで含むのか、報告までか）。並行稼働中の切り戻し手順。切り替え後の監視項目とアラート閾値の設定範囲。GatewayClassやIngressClassの命名規約を誰が決めるか。

この5点が曖昧なまま総額だけ提示された見積もりは、翻訳不能設定の設計が「追加作業」として後から積み上がりがちです。Kubernetes基盤の設計から移行・監視までを相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援で現行構成の棚卸しから対応しています。

よくある質問

NGINX Ingressの呼称と移行判断について、検索で頻出する質問に答えます。

NGINX IngressとNGINX Ingress Controllerは別物ですか？

呼び分けが定着しておらず、文脈で判断します。一般に「NGINX Ingress」や「ingress-nginx」はコミュニティ版（kubernetes/ingress-nginx、2026年3月退役）を、「NGINX Ingress Controller」はF5の商用製品（nginx/kubernetes-ingress、5.5系が継続）を指します。確実な見分け方はアノテーションの接頭辞で、nginx.ingress.kubernetes.io/ ならコミュニティ版、nginx.org/ か nginx.com/ ならF5版です。

ingress-nginxは退役後も動き続けますか？

動きます。退役告知でも「既存のデプロイは動作を続け、インストール用の配布物も残る」と明記されました。止まるのは開発側で、新しいリリース、バグ修正、脆弱性への対応がなくなります。次に脆弱性が公表されたときに修正版が出ない、という形でリスクが顕在化する点に注意してください。

ingress2gatewayを使えば移行は自動で終わりますか？

終わりません。1.0で30種類超のアノテーションに対応しましたが、公式も一発置換ではなく移行の補助と位置づけています。担うのは変換できる設定の生成と、変換できない設定の可視化まで。翻訳不能として報告された項目は、要件として作り直すか捨てるかを人が判断します。use-regexのような挙動差は構文が通っても結果が変わるため、実トラフィックでの突き合わせが別途必要です。

Gateway APIへ移るとIngressリソースは使えなくなりますか？

使えます。Ingress APIそのものはKubernetesから削除されておらず、退役したのはingress-nginxというコントローラー実装です。移行はingressClassNameで新旧を並行稼働させ、Ingressを1本ずつHTTPRouteへ置き換える形が現実的になります。両APIが同一クラスタに共存できるため、期限を区切った段階移行が組めます。

NGINX Gateway FabricとF5版NGINX Ingress Controllerはどちらを選ぶべきですか？

扱うAPIが違うため、移行方針で決まります。Ingressリソースを維持して工数を抑えたいならF5版NGINX Ingress Controller、Gateway APIへ移ってHTTPRouteで書き直す前提ならNGINX Gateway Fabric（2.6系、Gateway API v1.5.1対応、2026年7月時点）です。NGINX Plusの機能を使っていないなら、二度手間を避ける意味でGateway Fabric側を先に検討してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る