2025年11月11日、Kubernetes SIG Networkは衝撃的な発表を行った。Kubernetesクラスタの40〜50%で使用されているIngress NGINXコントローラーが、2026年3月をもってEnd-of-Life（EOL）を迎える。メンテナー1〜2名という脆弱な体制が限界に達した結果であり、後継のGateway APIへの移行は全Kubernetesユーザーにとって避けられない課題となった。本稿では、EOLに至った経緯、Gateway APIの技術的優位性、そして代替コントローラーの選定基準を実装レベルで解説する。

Ingress NGINX EOLの経緯 ── 1〜2名のメンテナーが支えた巨大インフラ

Ingress NGINXは、Kubernetesにおける外部トラフィック制御の事実上の標準として長年君臨してきた。Datadogの調査によれば、Kubernetesクラスタの40〜50%がIngress NGINXを使用しており、ダウンロード数は1,000万回を超える。しかし、その巨大な利用規模とは裏腹に、開発を支えていたのはわずか1〜2名のボランティアメンテナーだった。

彼らは「業務時間外、週末」に個人の時間を割いて開発を続けていた。Kubernetesプロジェクトはこの状況を打開すべく、後継プロジェクト「InGate」を立ち上げたが、十分な進展を見せることなく頓挫した。追加メンテナーの確保も叶わず、2025年11月11日、SIG Networkとセキュリティレスポンス委員会は正式にIngress NGINXの引退を発表した。

2026年1月29日にはKubernetes Steering Committeeが追加声明を出し、Ingress NGINXの「snippets」機能がNGINXの任意設定を許可するアーキテクチャ上のセキュリティリスクであると指摘した。EOL後もHelm ChartやコンテナイメージはGitHub上で参照可能だが、リポジトリはリードオンリーとなりアーカイブされる。新たなリリース、バグ修正、セキュリティパッチは一切提供されない。

Gateway APIとは何か ── Ingress APIの構造的限界を超える新標準

Gateway APIは、Ingress APIの後継としてKubernetes SIG Networkが策定したトラフィック管理の新標準である。2023年10月31日にv1.0がGA（一般提供）に達し、2025年10月にはv1.4.0がリリースされている。Ingress APIが抱えていた構造的限界を根本から解決する設計となっている。

Ingress APIの最大の問題は、単一のフラットなリソースにすべての設定を押し込む構造にあった。ベンダー固有のアノテーションでしか機能を拡張できず、コントローラー間でのポータビリティは事実上存在しなかった。対してGateway APIは、GatewayClass（インフラプロバイダーのテンプレート）、Gateway（ロードバランサーのインスタンス）、HTTPRoute/TCPRoute（ルーティング設定）という階層構造を採用する。

この階層設計は、マルチテナント環境での運用を劇的に改善する。インフラチームがGatewayを管理し、アプリケーションチームがHTTPRouteを管理するという役割分離が標準仕様として組み込まれている。クロスネームスペースのルーティングもネイティブサポートされる。

機能面でも差は大きい。Gateway APIはHTTP/HTTPSに加え、TCP/UDPのL4トラフィック、gRPC、WebSocket（v1.2でGA）をネイティブサポートする。v1.3ではパーセンテージベースのリクエストミラーリングが追加され、v1.4ではBackendTLSPolicy（ゲートウェイとバックエンド間のTLS暗号化）が標準チャネルに昇格した。カナリアデプロイメント、重み付きトラフィック分割、ヘッダベースマッチングもすべて標準仕様である。

Gateway APIの適合実装 ── 5つの選択肢を比較する

Gateway API v1.4.0のコンフォーマンステストに合格した主要実装は5つある。それぞれの特性を理解し、ワークロードの要件に応じた選定が重要である。

Envoy Gateway

Envoyプロキシをベースとした軽量でベンダーニュートラルな実装である。mTLS、JWT検証、レート制限をサポートし、ルート変更の伝播はミリ秒レベルで完了する。Gateway APIのファーストクラスサポートを謳い、North-South（ゲートウェイコントローラー）プロファイルに特化している。新規構築でしがらみのない環境には最適な選択肢である。

Istio

包括的なサービスメッシュとしてGateway APIをサポートする。ゲートウェイとメッシュの両方のプロファイルに対応し、セキュリティポリシーとの統合が強力である。Ambientモードによりデータプレーンのオーバーヘッドも削減された。ルート変更伝播はミリ秒レベルであり、大規模なマイクロサービス環境に適する。

Cilium

eBPFベースのデータプレーンを持ち、L4トラフィック処理では他の追随を許さないパフォーマンスを発揮する。カーネルオーバーヘッドを最小化し、スループットはハードウェア性能のみに制約される。CNI（Container Network Interface）の観点からGateway APIにアプローチしており、cilium-operator/agentに直接組み込まれている。ネットワーク性能が最優先のワークロードに最適である。

Kong Ingress Controller

Gateway APIコンフォーマンスレポートを最初に提出した実装であり、コアテストに100%合格している。TCP、UDP、TLS、gRPC、HTTP/HTTPSをネイティブサポートし、Gateway APIリソースをKong Gatewayの設定に直接変換する。既存のKong利用者にとっては自然な移行先である。

NGINX Gateway Fabric（NGF）

NGINX（F5）が開発するオープンソースのGateway API実装である。HTTPRoute、GRPCRoute、TCPRoute、TLSRoute、UDPRouteなど幅広いルートタイプをサポートする。Ingress NGINXからの移行において、NGINXの設定ノウハウを活かせるという点で親和性が高い。最新バージョンは2.4.1である。

移行戦略 ── 段階的アプローチとフォールバック設計

Ingress NGINXからGateway APIへの移行は、一括切り替えではなく段階的に進めるべきである。Kubernetes Gateway APIの公式ドキュメントでは、Ingressからの移行ガイドが提供されている。

第一段階は、既存のIngressリソースと並行してGateway APIリソースをデプロイし、一部のトラフィックをGateway API経由に切り替えるカナリア方式である。HTTPRouteの重み付きバックエンドリファレンスを活用すれば、旧経路と新経路の比率を10:90から段階的に移行できる。

第二段階では、Gateway APIのBackendTLSPolicy（v1.4で標準化）を適用し、ゲートウェイとバックエンド間のTLS暗号化を有効化する。これにより、Ingress NGINXでは実現が困難だったエンドツーエンドのセキュアな通信が標準設定で可能になる。

第三段階は、IngressリソースのDNSレコードをGateway APIに完全移行し、Ingress NGINXのデプロイメントを削除する。この段階に至るまでに、すべてのルーティングルールがGateway APIのHTTPRouteに移植されていることが前提である。

また、Gateway APIへ移行せずIngress互換のコントローラーに乗り換えるという選択肢もある。F5が開発するNGINX Ingress Controller（Ingress NGINXとは別プロジェクト）は、Apache 2.0ライセンスのオープンソースであり、150名以上のコントリビューターと専任の開発チームを擁する。VirtualServer、Policy、TransportServerなどのカスタムリソースに加え、標準Ingressもサポートしており、アノテーションの直接マッピングによるスムーズな移行が可能である。

2026年3月以降のリスクと対応優先度

EOL後にIngress NGINXを使い続けることの最大リスクは、セキュリティ脆弱性の放置である。Kubernetes Steering Committeeは「Ingress NGINXを使い続けることは、システムを攻撃に対して脆弱な状態に置く」と明確に警告している。過去にはIngress NGINXに重大な脆弱性（CVE）が複数報告されており、メンテナンスが停止すれば新たな脆弱性が発見されても修正されない。

対応の優先度は、本番環境でIngress NGINXを使用しているクラスタが最も高い。特にインターネット向けのトラフィックを処理するIngress NGINXは、攻撃の入口となるため最優先で移行すべきである。内部ネットワークのみで使用している場合でも、コンプライアンスやセキュリティ監査の観点からEOL後のソフトウェアの使用は問題となる。

Gateway APIのコンフォーマンスレビューは、各リリース後（少なくとも月次）で実施されている。2025年6月にv1.3後の初回レビューが行われ、v1.5（2026年中盤予定）以降は更新のない「stale」な実装がリストから削除される。実装の選定においては、アクティブなメンテナンスが継続されているかどうかも重要な判断基準である。

FAQ

Ingress NGINXのEOL後も既存のデプロイメントは動作するのか？

動作は継続する。ただし、新規リリース、バグ修正、セキュリティパッチは一切提供されない。GitHubリポジトリはリードオンリーとなりアーカイブされるため、既存のHelm Chartやコンテナイメージは参照可能だが、脆弱性が発見されても修正されない点に留意が必要である。

Gateway APIへの移行にはどの程度の工数がかかるのか？

規模やカスタマイズの程度に依存するが、基本的なHTTPルーティングであればIngressリソースからHTTPRouteへの変換は比較的単純である。公式の移行ガイドが提供されており、段階的な並行運用による移行が推奨される。アノテーションで独自拡張を多用している場合は、Gateway APIの標準機能への置き換え設計が必要となる。

Gateway APIの実装としてどれを選ぶべきか？

ワークロードの特性による。ネットワーク性能最優先ならCilium、フルサービスメッシュが必要ならIstio、軽量でベンダーニュートラルな構成ならEnvoy Gateway、NGINX資産を活かしたいならNGINX Gateway Fabricが候補となる。いずれもGateway API v1.4.0のコンフォーマンステストに合格している。

Ingress NGINXとF5 NGINX Ingress Controllerは別物なのか？

別プロジェクトである。Ingress NGINXはKubernetesコミュニティが管理するOSSで今回EOLとなる。F5 NGINX Ingress ControllerはF5社が専任チームで開発・メンテナンスするApache 2.0ライセンスのOSSであり、150名以上のコントリビューターが参加している。両者は設定方法やカスタムリソースが異なる。

参考文献