ingress-nginx の保守終了後：Gateway API への並行移行を検証する

概要

2026年10月25日時点の情報である。Kubernetes コミュニティによる Ingress NGINX の保守終了告知では、ベストエフォートでの保守終了を2026年3月とし、その後はリリース、バグ修正、セキュリティ更新を行わないとしている。既存のデプロイ環境とインストール用成果物は引き続き使用できる。変更を計画する前に、保守終了の告知と、選んだ代替コントローラーのサポートおよび仕様適合性の文書を再確認する。対象はコミュニティの ingress-nginx プロジェクトである。NGINX という名前のものを一律に分類せず、実際のコントローラーを特定する。保守終了の告知。

重要な理由

イメージを入手できることやエンドポイントが動作することは、保守が続いている証拠にはならない。Gateway API では設定モデルが変わり、Gateway は入口を、HTTPRoute はアプリケーションのルーティングを記述する。コントローラー固有のアノテーションは、対応先を明確にする必要がある。一般的な移行ガイドは変換方法を説明しているが、稼働中環境を移行する完全な手順は提供しないと明記している。移行モデル。

以下の段階的な手順は、運用計画の提案である。受け入れ基準には、アプリケーションの既存のルーティング要件とセキュリティ要件を含めなければならない。

適用方法

• 調査を許可されたすべてのクラスターでコントローラーを洗い出す。保守終了の告知では kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx を提案している。コントローラーのデプロイとイメージも確認する。ラベルの照会だけでは、名称変更やカスタマイズが施された導入環境の存在を否定できない。Ingress リソース、クラス、アノテーション、TLS の参照、コントローラー設定を記録する。

• 必要な機能を仕様適合性と拡張機能の対応範囲で満たす、保守中の Gateway API 実装を選ぶ。入口とルートの管理責任者を決める。公式の導入ガイドは、別の外部 IP を使って新しいコントローラーを ingress-nginx と並行稼働させる方法を示している。そのため、公開トラフィックを変更する前に、検証用の独立したエンドポイントを用意する。並行移行のガイド。

• 確認済みの ingress2gateway を使い、エクスポートしたマニフェストから下案を生成する。公式の 1.0 発表では、次の形式を示している。

  ingress2gateway print --input-file ingress.yaml --providers=ingress-nginx > gateway-draft.yaml
  

  何かを適用する前に、生成されたリソースとすべての警告を確認する。実際に移行先で使う GatewayClass を選び、名前、名前空間、バックエンドへの参照を確認する。変換のガイド。

• 未対応の機能にはすべて明示的に対処する。この発表では、未変換の設定スニペット、近似的なタイムアウトの変換、例示の中で標準の対応機能がない本文サイズ制限、URL 正規化の違いを挙げている。現在の API と選択した実装に照らして、それらの対応関係を再確認する。過去の変換ツールの制約を、仕様の恒久的な制約として扱ってはならない。

• 想定するホスト名と TLS の識別情報を使い、独立したエンドポイントを検証する。リダイレクト、認証要件、ルートの優先順位、アップロード、長時間のリクエスト、期待する拒否動作をテストする。攻撃用ペイロードを使わず、通常のアプリケーションテストとして行う。両方のエンドポイントが成功応答を返すかだけでなく、文書化された要件と結果を比較する。

• サイトで管理されている DNS またはロードバランサーの変更手順でトラフィックを移す。アプリケーションのエラーとアクセスログを観測し、期限を決めたロールバック経路を維持する。観測期間を問題なく終えたら、古いコントローラーと未使用リソースを削除する。

落とし穴

生成された YAML がアクセス制御を維持することや、独自拡張を別のコントローラーに移植できることを前提にしてはならない。並行デプロイでも、DNS と証明書自動化の責任の所在を明確にする必要がある。保守が終了したコントローラーを、文書化されていない予備として無期限に公開し続けない。変換の成功、コントローラーの準備完了、アプリケーションの正しい動作は、それぞれ別に確認する事項である。