公開2026.07.27更新2026.10.25 Kubernetes・コンテナ

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

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

まとめ：稼働中の実装を判別してから2026年3月退役後の進路を選ぶ

最初に確認するのは、クラスタで動いているコントローラーの出自です。kubectl get pods をラベルセレクタ付きで打ち、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 -T の確認

「NGINX Ingressが動いている」という報告だけでは、退役版か商用版かが決まりません。3つの角度から実物を確かめます。

kubectlでingress-nginxのPodとラベルを確認する2つのコマンド

コミュニティ版の判別方法は、退役告知そのものに書かれています。Kubernetes Contributorsブログの退役告知が示すセレクタをそのまま打ってください。続けて全名前空間のIngressからアノテーションのキーを集めると、どの接頭辞に依存しているかが一覧で出ます。

# コミュニティ版 ingress-nginx が動いているかを確認する
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 全 Ingress が使っているアノテーション接頭辞を集計する
kubectl get ingress --all-namespaces -o json \
  | jq -r '.items[].metadata.annotations | keys[]' \
  | cut -d '/' -f 1 | sort | uniq -c | sort -rn

Podが1つも返らないなら、動いているのはF5版か別実装です。2つ目のコマンドの出力で nginx.ingress.kubernetes.io の件数が多いほど、書き換え対象が広いという読み方になります。クラスタ内でIngressがServiceやPod間通信とどう噛み合うかはKubernetesネットワーク設計におけるService・Ingress・CNI選定の判断で扱っています。

アノテーション接頭辞でコミュニティ版とF5版を切り分ける確認手順

両者を分ける最も実務的な差はアノテーションの接頭辞です。コミュニティ版は公式のアノテーション一覧にある通り nginx.ingress.kubernetes.io を既定の接頭辞とし、--annotations-prefix 引数で変更できる作りでした。

F5版は nginx.org と nginx.com の2系統を使います。F5のアノテーション仕様では、前者がNGINX OSSとNGINX Plusの双方で効き、後者はPlus限定と明記されています。名前空間が違うだけでなく、対応する設定項目も一対一ではありません。

nginx -T で生成済み設定とnginx本体の版を突き合わせる手順

どちらの実装も、L7の振り分けを担うデータプレーンはnginx本体です。コントローラーはIngressの内容を nginx.conf へ書き出し、nginxをリロードする役に徹します。実際に生成された設定と本体の版は、Podの中で直接確かめられます。

# コントローラーPod内の nginx 本体の版と生成済み設定を見る
POD=$(kubectl -n ingress-nginx get pod \
  -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{.items[0].metadata.name}')

kubectl -n ingress-nginx exec "$POD" -- nginx -v
kubectl -n ingress-nginx exec "$POD" -- nginx -T | head -60

ここで出た版は、nginx公式のCHANGESと突き合わせて脆弱性修正の取り込み状況を判断します。退役後のコミュニティ版はコントローラー側の更新が止まるため、同梱されたnginxの版も1.15.1の時点で固定されます。データプレーン側の版と脆弱性の追い方はnginx 1.30.3が修正した脆弱性とCVSS v4.0スコアの読み解き方で整理しました。振り分け方式そのものの前提はロードバランサーの仕組みと種類・振り分け方式の解説で扱っています。

コミュニティ版とF5版の開発体制・最新版・機能差を並べて確認する

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

コミュニティ版ingress-nginxの最終版1.15.1とアーカイブ日

kubernetes/ingress-nginxは、Kubernetesプロジェクト配下で開発されてきたIngressコントローラーです。公式のリリース一覧を見ると、2026年3月9日のcontroller-v1.15.0、3月19日のcontroller-v1.15.1・v1.14.5・v1.13.9で履歴が止まっています。Helmチャートも同日の helm-chart-4.15.1 が最後で、リポジトリは3月24日にアーカイブされ読み取り専用になりました。

退役の理由は技術面ではありません。共同声明によれば保守は少人数の空き時間に依存しており、一方で同声明が引くDatadogの内部調査では、クラウドネイティブ環境の約50%がこのコントローラーに依存していたとされます。依存の広さと保守体制の細さが釣り合わなくなった結果の判断でした。

F5版の最新5.6系とNGINX Plus限定機能の二層構造の見極め

F5のNGINX Ingress Controller（リポジトリはnginx/kubernetes-ingress）は商用製品として保守が続いています。F5公式のchangelogによれば、2026年9月時点の最新は5.6系で、NGINX OSS 1.31.4系とNGINX Plus R37.1系を取り込んでいます。5月29日の5.5.0では外部認証、WAFのIP Intelligence、mTLSが入り、7月15日の5.5.2はテンプレートインジェクションの緊急修正でした。この種の修正が今後も出る点が退役版との決定的な差になります。

注意したいのは機能の二層構造です。NGINX OSSベースでも動きますが、JWT検証（nginx.com/jwt-key）やアクティブヘルスチェック（nginx.com/health-checks）はNGINX Plusのサブスクリプションが前提になります。「F5版へ移れば同等以上」と考えて計画を立てると、Plus前提の機能を無償版で使えず設計をやり直す羽目になります。動作要件はF5のtechnical specificationsで対応Kubernetes版とあわせて先に確認してください。

nginx.org/とnginx.com/へ書き換える範囲をコードで確かめる

書き換えの当たりを付けるには、実物を並べるのが早いです。proxy系のタイムアウトやボディサイズ上限は、名前が変わるだけで意味が通ります。

# コミュニティ版（退役）での書き方
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 20m
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

# F5版（nginx.org 接頭辞）へ寄せた書き方
metadata:
  annotations:
    nginx.org/client-max-body-size: 20m
    nginx.org/proxy-connect-timeout: 30s
    nginx.org/ssl-redirect: "true"

一対一で移せるのはこの層までです。F5版はIngressを超えた設定をVirtualServerやVirtualServerRouteという独自CRDで表現するため、canaryリリース系やconfiguration snippetsに相当する要件はCRD側の機能へ読み替えることになります。機械的な置換が効くのは単純な設定までだと見ておいてください。

IngressリソースとingressClassNameの責務分担を棚卸しする

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

Ingress標準APIが担う範囲とアノテーション拡張に寄せた限界

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

タイムアウト、ボディサイズ上限、書き換え、CORS、認証といった実務で必要な設定はすべて標準の外にあり、各コントローラーがアノテーションで独自に拡張してきました。この「標準が薄く拡張が厚い」構造はIngressの移植性を下げ、Gateway APIが作られる直接の開発動機です。公式が並べる実装一覧の数だけ拡張の方言があると考えると、移植性の低さの理由が掴めます。Kubernetes自体の全体像はKubernetes（クバネティス）の仕組みとDockerとの違いで解説しています。

pathTypeとuse-regexを使うIngressを抽出する2つのコマンド

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

pathType には Prefix、Exact、ImplementationSpecific の3つがあり、前2つは仕様で挙動が決まっています。問題はImplementationSpecificで、文字どおりコントローラー任せのため、実装を替えると同じマニフェストでも振り分けが変わる点です。棚卸しは次の2本で機械的に済みます。

# pathType が ImplementationSpecific の Ingress を洗い出す
kubectl get ingress -A -o json | jq -r '
  .items[]
  | select(.spec.rules[]?.http.paths[]?.pathType == "ImplementationSpecific")
  | "\(.metadata.namespace) \(.metadata.name)"' | sort -u

# use-regex を true にしている Ingress を洗い出す
kubectl get ingress -A -o json | jq -r '
  .items[]
  | select(.metadata.annotations["nginx.ingress.kubernetes.io/use-regex"] == "true")
  | "\(.metadata.namespace) \(.metadata.name)"' | sort -u

ここに挙がった本数が、移行の難所そのものです。PrefixとExactだけで書かれたものは変換ツールでほぼそのまま通るため、危険度の高い順に並べ替える作業として使えます。

ingress-nginx退役の経緯とアーカイブ後に残る運用リスクの見積もり

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

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

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

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

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

共同声明が引き合いに出した過去の事例が CVE-2025-1974 です。ingress-nginxのアドミッションコントローラーに起因する脆弱性で、2025年3月24日の公式解説とNVDの登録内容のとおり、公開時には広範な影響が指摘されました。

この一件が示したのは、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のGatewayとHTTPRouteへ責務を分けて書き直す

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

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
    - name: prod-gateway
      namespace: infra
  hostnames:
    - shop.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: shop-api
          port: 8080

仕様の成熟も進みました。v1.4.0は2025年10月6日にGAとなりBackendTLSPolicyがStandardチャネルへ入り、2026年2月27日リリースのv1.5ではListenerSet、TLSRoute、CORSフィルタ、クライアント証明書検証、ReferenceGrantがStandardへ移っています。さらに2026年6月30日のv1.6でTCPRouteとUDPRouteがStandardへ昇格し、実験的リソースは別APIグループへ切り離されました。標準の範囲がL4まで広がった形です。Gateway API自体の仕組みとCRDの導入からHTTPRouteの設定例までは、Gateway APIとは：Kubernetesの設定手順とHTTPRoute・Ingressからの移行で解説しています。

実装の選択肢は広く、F5のNGINX Gateway Fabric（2.7系・2026年9月時点・外部認証とF5 WAF統合を追加）、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を導入しprintモードで変換出力を確かめる手順

ingress2gatewayはKubernetes公式が提供する移行支援ツールで、2026年3月に1.0がリリースされました。1.0未満ではIngress-NGINXのアノテーションを3種類しか解釈できませんでしたが、ingress-nginxプロバイダのREADMEにある通り、1.0でCORS、バックエンドTLS、正規表現マッチ、パス書き換え、proxy body size、proxy timeouts、configuration snippetsなど30種類超へ拡大しています。導入と実行は3行で済みます。

# 1.0 を導入する（Go か Homebrew のいずれか）
go install github.com/kubernetes-sigs/[email protected]
brew install ingress2gateway

# クラスタへ適用せず、変換結果を標準出力で確認する
ingress2gateway print --providers=ingress-nginx

# 名前空間を絞って差分を追いやすくする
ingress2gateway print --providers=ingress-nginx --namespace=shop

printはkubeconfigの認証情報でIngressを読み、GatewayとHTTPRouteの組を出力します。変換できなかった設定は翻訳不能として提示され、代替案が添えられます。公式も一発置換ではなく補助役と位置づけているため、出力をそのまま kubectl apply に流さず、翻訳不能項目を1つずつ設計判断にかけてください。

変換から並行稼働・経路切り替えまでを5つの手順で回す組み立て方

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

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

切り替え中は新旧の経路が同時に生きます。障害時の切り分けを速めるには、監視側でどちらを通ったか判別できる状態が必要です。切り戻し前提で束ごと入れ替える進め方を採る場合はブルーグリーンデプロイメントの仕組みと他方式との違いが設計の型として使えます。見るべき指標の置き方はKubernetes監視・モニタリングの設計にまとめました。

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

変換ツールが構文的に正しい出力を返しても、挙動が変わる箇所があります。筆頭が nginx.ingress.kubernetes.io/use-regex を true にしたときの挙動です。公式のアノテーション一覧は、この指定で「case insensitive regular expression の location 修飾子がそのホストの全パスへ強制される」と説明しています。

つまり大文字小文字を区別しないうえ、nginxのlocation修飾子の性質から評価は完全一致になりません。公式のpath matching解説が挙げる例では、3文字の大文字だけに一致させるつもりで書いた正規表現が、小文字混じりのパスにも一致します。

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、2026年9月時点で5.6系）を指します。確実な見分け方はアノテーションの接頭辞で、nginx.ingress.kubernetes.io ならコミュニティ版、nginx.org か nginx.com ならF5版です。

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

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

コントローラーの版とnginx本体の版はどう対応していますか？

コントローラーの版に、同梱するnginxの版が紐づく形です。F5版はchangelogでNGINX OSSとNGINX Plusの版を明記しており、2026年9月時点の5.6系はOSS 1.31.4系を含みます。コミュニティ版は最終版1.15.1の時点で固定されるため、以後nginx本体に脆弱性修正が出ても取り込まれません。稼働中の版は nginx -v をPod内で実行すれば確認できます。

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

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

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

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