こんにちは
近所のスーパーではクリスマスソングが流れ、正月飾りも売られ始め、いよいよ年末になってきたなと思える季節になりました。
仕事では、ingress-nginxが2026年3月をもってEOLを迎えるという噂を聞きつけ、少し本ブログで簡単に紹介したいと思います。
まあ、ほぼほぼ以下公式で紹介されている内容になります。
https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
—
ingress-nginxとはなんぞ
・KubernetesでIngressリソースを使って、クラスタ内のサービスへHTTP/HTTPS外部アクセスを可能にするOSS
・クラウドベンダーに依存せずに、NGINXの設定をカスタムしたり、サードパーティ拡張が可能
結構案件で利用される方も多いのではないでしょうか。
EOLを迎える背景として、以下のようなことが紹介されていました。
なせEOLに至るか
・保守運用体制の限界
→多機能故に、メンテナンス工数が多く取られていたみたいです
・技術的負債の蓄積
→例として、NGINX の “snippets（任意の構成を注入できる）” 注釈のような機能が、「昔は便利だったが今ではセキュリティ・運用観点からはリスク」になっている、との指摘があり、またその機能の肥大化による改修負担も増えてきた
・よりモダンな代替技術の成熟
→代替として Gateway API を強く推奨されている
→Kubernetes のネットワーキングにおける次世代 API／標準化が進む中、古い方式（Ingress + Ingress-NGINX）を維持するよりも、新しい方式への移行を促す判断されている
では、ingress-nginx を利用しているエンジニアはどうすれば良いか？
ingress-nginx移行アプローチ
・Gateway API を採用する
・他の Ingress コントローラー（例：クラウドベンダー提供型、または CNCF で活発なプロジェクト）に切り替える
・Ingress-NGINX を当面維持するが、セキュリティリスクを許容／限定的に運用し、将来的には移行計画を立てる
あたりになりそうです。
LBの再作成などで、24/365 なシステムでは、結構切り替えプロセスに工数がかかりそうな気配です。クラウドエンジニアの宿命というやつでしょうか、、
時期的にはEOLまでまだ数ヶ月先ですが、そろそろ移行プロセスについて整理していきたいところ。
機会があれば、実際に移行する上でどのようなことを実施したのか、ブログで紹介できればと思います。
入会申込
ログイン
