ingress-nginx廃止2026年3月、Gateway API移行で見落としがちな罠

Kubernetes（コンテナ運用の標準基盤）でHTTPルーティングにingress-nginxを使っているクラスタは、2026年3月までに移行判断を迫られます。Kubernetesプロジェクトがingress-nginxの引退（開発終了）を発表したためです。この記事は、クラスタ運用を担うインフラ・SREエンジニアが「自分のクラスタは該当するか」を確認し、次の一手を判断できる状態を目指します。

何が起きるか

ingress-nginxは2026年3月以降、パッチもアップデートも提供されなくなります。既存のHelmチャートやコンテナイメージは引き続き使えるため、アプリケーションが即日停止するわけではありません。

問題は緩やかに蓄積するリスクです。新しい脆弱性が見つかっても修正されません。稼働は続くのに、セキュリティ上の危険度だけが時間とともに積み上がっていきます。

後継ソフトウェアは指定されませんでした。当初はGateway APIコミュニティと共同でInGateという後継コントローラーを開発する計画がありましたが、開発を担う人が現れず、InGate自体も引退しています。後継が示されなかったのは、示せなかったからです。

なぜ起きるか

直接の原因は、メンテナー不足です。長年、実質1〜2人がボランティアでingress-nginxを維持してきました。特定少数の担当者に依存する体制は、担当者が離脱した瞬間に維持コストを払える人がいなくなる構造的な弱さを持っています。

もう一段深い原因は、「Ingress」というKubernetesの標準仕様とingress-nginxという実装がほぼ一体化していたことです。Ingressリソースを書けばingress-nginxが動く、という一対一対応が長く続いたため、「仕様」と「実装」を分けて考える必要がありませんでした。

Gateway APIはこの前提を崩します。Gateway APIはKubernetesの仕様であり、ソフトウェアではありません。HTTPRouteというリソースを書いても、それを読み取って実際にトラフィックを処理するコントローラー（実装）を別途インストールしなければ何も起こりません。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: my-service
          port: 8080

このマニフェストは、Gateway実装がクラスタに入っていなければ「適用できたのに何も起きない」という状態になります。Ingress時代には存在しなかった「どの実装を選ぶか」という判断が、新たに全チームに課されることになりました。

さらに厄介なのが、実装の選択肢が多すぎることです。Envoyベースの系列だけでもEnvoy Gateway、kgateway、Istio、Contour、Ciliumがあります。Envoy系以外にもTraefik、Kong、NGINX Gateway Fabricがあり、クラウド各社も自社実装を提供しています。すべてが「Gateway API conformant（適合）」を名乗りますが、この言葉は思ったほど強い保証ではありません。

Gateway APIの機能はCore（全実装が必須で対応する最小機能）、Extended（推奨だが任意）、Implementation-specific（各ベンダー独自拡張）の3段階に分かれています。「conformant」を名乗るために必要なのはCoreの対応だけです。認証・レート制限・サーキットブレーカーといった本番運用で実際に必要になる機能は、たいていExtended以上に位置します。

「Gateway API conformant」という表示は実装間の互換性を保証しません。Extended以上の機能を使った時点で、その実装固有のCRD（カスタムリソース）に縛られます。

Envoy GatewayはSecurityPolicyというCRDで認証やレート制限を設定し、IstioはAuthorizationPolicyという別のCRDを使います。どちらか一方のリソースを書き始めた瞬間、実質的にその実装からの乗り換えコストが発生します。これは技術的負債の典型的な発生パターンで、「標準に沿っているつもり」で特定実装への依存が静かに積み上がっていく点が見落とされやすい部分です。

自分のプロジェクトが該当するか確認する

最初に確認すべきは、クラスタで実際にingress-nginxが動いているかどうかです。

kubectl get pods -n ingress-nginx
kubectl get ingressclass

ingress-nginxという名前空間やIngressClassが存在していれば対象です。Helmでインストールしている場合は、以下でリリース状況とバージョンを確認できます。

helm list -A | grep ingress-nginx
helm get values <release-name> -n ingress-nginx

次に確認したいのは、Ingressリソースに書かれているアノテーション（nginx.ingress.kubernetes.io/で始まる設定項目）の数と種類です。

kubectl get ingress -A -o yaml | grep "nginx.ingress.kubernetes.io"

この出力が多いほど、移行時の設定移し替え作業が大きくなります。アノテーションは大きく「Gateway APIのCoreで代替できるもの（パス・ホストベースのルーティングなど）」「Extendedで代替できるもの（リダイレクト・ヘッダー書き換えなど）」「実装固有の拡張が必要なもの（レート制限・独自の認証連携など）」の3種類に分類して洗い出すと、移行の見積もりが立てやすくなります。

対策の手順

手順1: 引退スケジュールを社内で共有する

2026年3月というデッドラインと、「動き続けるがパッチが来なくなる」というリスクの性質を、まずチーム内で認識合わせします。停止ではなく「脆弱性放置リスクの蓄積」である点が伝わりにくいため、明文化しておくと判断が早くなります。

手順2: 実装を1つに絞る前に要件を洗い出す

認証・レート制限・サーキットブレーカーなど、現在ingress-nginxのアノテーションで実現している機能をリストアップします。サービスメッシュ（マイクロサービス間通信の制御基盤）をIstioなどで既に使っているなら、Istio Gateway APIサポートとの統合を優先候補にする根拠になります。逆に単純なHTTPルーティングだけなら、移行の容易さを優先してNGINX Gateway FabricやTraefikを検討する余地があります。

手順3: 小規模なクラスタか非本番環境で試験導入する

いずれの実装もHelmチャートやOperatorでインストールできます。まずステージング環境でHTTPRouteを1つ作り、既存Ingressと並行稼働させて挙動を比較します。

手順4: アノテーションを3分類に沿って書き換える

Core相当（パスマッチ・ホストルーティング）はHTTPRouteの標準フィールドに直接移せます。Extended相当（リダイレクト・ヘッダー操作）はGateway APIの拡張フィールドまたはBackendPolicy系リソースを確認します。実装固有の機能は、選んだ実装のCRDドキュメントを個別に当たる必要があります。

手順5: ロールバック手順を用意してから切り替える

IngressとHTTPRouteは同じクラスタ内で共存できます。同一サービスに対して両方のリソースを一時的に残し、DNSやロードバランサーの向き先を切り替える形にしておくと、問題発生時に旧経路へ戻せます。

まとめ

ingress-nginxの引退は、稼働停止ではなく修正パッチ停止という緩やかなリスクの始まりです。放置するほど脆弱性対応の負債が積み重なります。

まずkubectl get ingressclassとkubectl get ingress -Aで自分のクラスタの依存度を数値で把握してください。次にアノテーションをCore・Extended・実装固有の3分類で仕分け、移行コストの見積もりに使ってください。

実装選定では「conformant」という表示だけで互換性を判断せず、実際に使う機能がどの段階に属するかを個別に確認する視点が欠かせません。