AKS Ingress Networkingの2026年5月14日更新で最も重要なのは、「Ingressが消える」のではなく、AKSのIngress/L7トラフィック管理の軸がGateway APIへ移っていくという点です。既存のIngressリソースはすぐに停止しませんが、Ingress NGINXプロジェクトは2026年3月にメンテナンス終了となり、AKSのApplication Routing add-onで提供されるマネージドNGINXも、2026年11月までのサポートを前提に移行計画が求められます。Microsoft Learnの日本語ドキュメントは2026年5月14日に更新され、この方針と移行先の選択肢が整理されています。(Microsoft Learn)
まず確認すべきことは3つです。現在のAKSクラスターでどのIngress Controllerを使っているか、Ingress NGINX固有のアノテーションやTLS/DNS連携に依存していないか、そしてGateway API・Application Gateway for Containers・Istioのどれに移行するのが運用要件に合うかです。特に本番環境では、「期限が近づいたら差し替える」ではなく、ステージング環境でルーティング、証明書、DNS、監視、クライアントIP保持まで検証してから移行する必要があります。
AKS Ingress Networkingの更新で押さえるべき変更点
今回の公式情報は、AKSのIngress機能そのものの単純な廃止告知ではありません。ポイントは、Kubernetes側でIngress NGINXの保守が終了し、AKSも長期的にはGateway APIをIngress/L7トラフィック管理の標準として扱う方向に整理されたことです。Microsoft Learnでは、AKSがアップストリームKubernetesに合わせてGateway APIへ移行していく方針を示し、現在の構成に応じた移行パスを計画するよう案内しています。(Microsoft Learn)
| 確認項目 | 公式情報の要点 | 実務上の影響 |
|---|---|---|
| Ingress NGINX | Kubernetes SIG NetworkとSecurity Response CommitteeがIngress NGINXの廃止を発表し、メンテナンスは2026年3月で終了 | 自己管理のingress-nginxを使っている環境は移行優先度が高い |
| AKS Application Routing add-on with NGINX | AKS上のマネージドNGINX Ingressリソースは、2026年11月まで重要なセキュリティパッチの公式サポート対象 | すぐに停止はしないが、長期利用前提の新規設計は避けるべき |
| 長期方針 | AKSはIngressとL7トラフィック管理の長期標準としてGateway APIへ移行 | Gateway APIの設計理解と移行検証が必要 |
| 移行候補 | Application Routing Gateway API実装、Application Gateway for Containers、Istioベースのサービスメッシュなど | 要件に応じて移行先を選ぶ必要がある |
重要なのは、Ingress APIとIngress NGINXを分けて考えることです。Kubernetes公式ドキュメントでは、Ingress APIはGAであり削除予定はない一方、APIとしては凍結され、今後の新機能開発はGateway API側へ移っていると説明されています。つまり、IngressというAPIオブジェクトが即座になくなるわけではありませんが、将来の拡張性や標準化を考えるとGateway APIへの移行検討が現実的です。(Kubernetes)
影響を受ける環境と、急いで確認すべき環境
影響の大きさは、AKS上でどのIngress Controllerを使っているかによって変わります。単にIngressリソースが存在するかではなく、裏側で動いているController、IngressClass、アノテーション、TLS証明書管理、DNS連携まで確認してください。
| 現在の構成 | 影響度 | まず確認すること |
|---|---|---|
| OSSのingress-nginxをHelmやマニフェストで自己管理している | 高 | ingress-nginx Pod、Helm release、IngressClass、独自アノテーション |
| AKS Application Routing add-on with NGINXを使用 | 中〜高 | webapprouting.kubernetes.azure.com のIngressClass、DNS/Key Vault連携、2026年11月までの移行計画 |
| Application Gateway for Containersを使用 | 低〜中 | Ingress API/Gateway APIのどちらで構成しているか、ALB Controllerの管理方式 |
| Istioサービスメッシュを使用 | 中 | Istio Ingress Gateway、mTLS、Gateway API対応状況、アドオンの制限 |
| LoadBalancer型Serviceのみで公開 | 低 | L4公開で要件を満たしているか、将来的にL7ルーティングが必要か |
自己管理のIngress NGINXは特に注意が必要です。Kubernetes Contributorsの発表では、2026年3月以降はリリース、バグ修正、セキュリティ脆弱性への更新が提供されないと説明されています。既存デプロイやHelm Chart、コンテナーイメージは残りますが、「動き続ける」ことと「安全に保守される」ことは別です。(Kubernetes Contributors)
Ingress Controllerの棚卸し手順
移行計画の前に、まず現状を見える化します。以下のコマンドを、対象クラスターごとに実行して一覧化してください。
kubectl get ingress -A
kubectl get ingressclass
kubectl get svc -A | grep LoadBalancer自己管理のIngress NGINXを使っているか確認する場合は、Kubernetes側の案内でも示されているように、app.kubernetes.io/name=ingress-nginxラベルでPodを確認します。(Kubernetes Contributors)
kubectl get pods --all-namespaces \
--selector app.kubernetes.io/name=ingress-nginxApplication Routing add-on with NGINXを使っている環境では、IngressClassにwebapprouting.kubernetes.azure.comが使われているかを確認します。Microsoft Learnの手順でも、このIngressClassを指定するとApplication Routing add-onが有効になると説明されています。(Microsoft Learn)
kubectl get ingress -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName,HOSTS:.spec.rules[*].host'加えて、次の項目をマニフェストから抽出しておくと、移行時の手戻りを減らせます。
- NGINX固有のアノテーション
- TLS Secretの名前と証明書更新方法
- Azure DNSや外部DNSで管理しているホスト名
- Azure Key Vault連携の有無
- 静的IPアドレスへの依存
X-Forwarded-Forを使ったクライアントIP判定- WAF、mTLS、リトライ、ヘッダー書き換えなどのL7機能
- 監視メトリック、ログ、アラートの取得方法
特にアノテーションは移行時の落とし穴です。Ingress NGINXではアノテーションで高度な挙動を実現していたケースが多く、Gateway APIやApplication Gateway for Containersへ移行する際に、同じ表現で移せるとは限りません。ルーティングルールだけでなく、タイムアウト、リダイレクト、ボディサイズ、ヘッダー制御なども確認してください。
移行先の選び方
AKSでの移行先は、単に「Gateway APIなら何でもよい」ではありません。誰がトラフィック基盤を管理するのか、証明書をどう扱うのか、mTLSやWAFが必要か、既存の静的IPやDNS設計を維持する必要があるかで選択が変わります。
| 移行候補 | 向いているケース | 注意点 |
|---|---|---|
| Application Routing Gateway API実装 | AKSのマネージドな入口管理を使い、Gateway APIへ段階移行したい | プレビュー機能のため、本番投入はサポート条件とGA状況を確認して判断 |
| Application Gateway for Containers | AzureホステッドなL7負荷分散、WAF、mTLS、重み付きルーティングなどを使いたい | 既存のNGINXアノテーションはそのまま移せない可能性がある |
| Istioベースのサービスメッシュアドオン | サービス間mTLS、細かなトラフィック制御、メッシュ全体の可観測性が必要 | サービスメッシュ導入そのものの運用設計が必要 |
| Application Routing add-on with NGINXへの一時移行 | 自己管理のOSS ingress-nginxから短期的にAKS公式サポートの橋渡しを使いたい | 2026年11月以降の長期移行先を別途決める必要がある |
Application Gateway for Containersは、AKSワークロード向けのレイヤー7負荷分散と動的トラフィック管理を提供し、Ingress APIとGateway APIの両方をサポートします。トラフィック分割、バックエンドへのmTLS、WAF、HTTP/2、URLリダイレクト、URL書き換えなども選択肢に入るため、単純なNGINX置き換えではなく、入口基盤をAzureネイティブに寄せたい場合に検討しやすい移行先です。(Microsoft Learn)
一方、Application Routing Gateway API実装は、Gateway APIベースのIngress管理へ移るためのAKS側の推奨経路として位置づけられています。ただしMicrosoft Learnでは、この機能がプレビューとして提供され、SLAや限定保証から除外される旨が明記されています。検証環境で早めに試し、本番適用は機能のサポート状態、制限、運用要件を確認してから判断してください。(Microsoft Learn)
Gateway API移行で変わる設計の考え方
Gateway APIでは、従来のIngressに比べて役割分担が明確になります。AKS Engineering Blogでは、GatewayClass、Gateway、HTTPRouteなどのリソースに分かれることで、インフラ担当がゲートウェイ基盤を管理し、アプリケーション開発者がルーティングルールを管理しやすくなると説明されています。(AKS Engineering Blog)
Ingress中心の運用では、1つのIngressリソースにホスト名、パス、TLS、Controller固有のアノテーションが集まりがちでした。Gateway APIへ移ると、たとえば次のような分担にできます。
| 役割 | 主に扱うリソース | 実務での担当例 |
|---|---|---|
| プラットフォーム管理者 | GatewayClass、Gateway | 入口基盤、リスナー、公開方式、共通ポリシー |
| アプリ開発者 | HTTPRoute、GRPCRoute | アプリ単位のホスト名、パス、バックエンドService |
| セキュリティ担当 | TLS、証明書、認証、ポリシー | 証明書管理、mTLS、公開範囲、監査 |
| 運用担当 | HPA、ログ、メトリック、アラート | 可用性、スケール、障害対応 |
この分担は、大規模なAKS環境ほど効果があります。複数チームが同じIngress Controllerにルールを追加している環境では、Gateway APIのロール指向設計により、権限分離と変更管理を整理しやすくなります。
Application Routing Gateway API実装を使う場合の注意点
Application Routing Gateway API実装は、軽量なIstioコントロールプレーンを使ってGateway基盤を管理しますが、フルのIstioサービスメッシュを有効化するものではありません。AKS Engineering Blogでは、サイドカー注入やワークロード向けIstio CRDは使わず、EnvoyベースのGateway Proxyを管理する構成だと説明されています。(AKS Engineering Blog)
確認すべき制限は次の通りです。
| 注意点 | 内容 |
|---|---|
| 本番利用判断 | プレビュー機能のため、SLAやサポート条件を確認してから本番適用する |
| Istioサービスメッシュとの併用 | Application Routing Gateway API実装とIstioサービスメッシュアドオンは同時に有効化できない |
| DNS/証明書管理 | Application Routing add-onのAzure DNS/TLS証明書管理は、Gateway APIでは現時点で未対応 |
| TLSRoute | SNIパススルー用途のTLSRouteは現時点で未対応 |
| エグレス管理 | Application Routing Gateway API実装によるエグレス管理は未対応 |
| アップグレード | Istioサービスメッシュアドオンのようなカナリアリビジョンではなく、インプレース更新となる点に注意 |
Microsoft Learnでも、Application Routing Gateway API実装とIstioサービスメッシュアドオンを同時に有効化できないこと、Gateway APIでAzure DNSとTLS証明書管理が現在サポートされないこと、TLSRouteやエグレス管理が未対応であることが示されています。(Microsoft Learn)
Application Routing add-on with NGINXを継続する場合の確認ポイント
Application Routing add-on with NGINXは、AKSでIngress Controllerを構成する推奨方法として案内されてきたマネージドな選択肢です。Azure DNS統合、Azure Key Vaultに保存した証明書でのSSL終端、マネージドNGINX Ingress Controllerの簡単な構成が提供されます。(Microsoft Learn)
ただし、継続利用する場合も「何もしなくてよい」わけではありません。以下を確認してください。
| 確認項目 | 理由 |
|---|---|
| 2026年11月までの移行計画 | 公式サポートは橋渡し期間として考えるべき |
| IngressClass | webapprouting.kubernetes.azure.comを使うIngressを特定する |
| Azure DNSゾーン | アドオンで管理しているDNSゾーンを把握する |
| Key Vault証明書 | 証明書の更新経路と有効期限を確認する |
| NGINXアノテーション | Gateway APIや別Controllerへ移せるかを確認する |
| ConfigMap編集 | app-routing-system名前空間のingress-nginx ConfigMap編集はサポートされない |
| ブロックされるスニペット注釈 | load_module、location、proxy_passなど一部の注釈は構成不可 |
Application Routing add-onには、DNSゾーン数、マネージドID必須、ConfigMap編集不可、ブロックされるスニペット注釈などの制限があります。既存の自己管理NGINXから移す場合は、「NGINXだから同じ挙動になる」と考えず、マニフェスト差分と動作確認を必ず行ってください。(Microsoft Learn)
クライアントIP保持とTLS設計で失敗しやすいポイント
Ingress移行で見落としやすいのが、アプリケーション側がクライアントIPに依存しているケースです。AKSのIngress ControllerでクライアントソースIP保持を有効にすると、元のクライアントIPはX-Forwarded-Forヘッダーで利用できます。一方で、クライアントソースIP保持をIngress Controllerで使う場合、TLSパススルーは利用できないと公式ドキュメントに記載されています。(Microsoft Learn)
次のような実装がある場合は、移行前にテストケースへ含めてください。
- アプリケーションが
X-Forwarded-Forでアクセス元制御をしている - WAFやAPIゲートウェイ側でIP制限をしている
- 監査ログにクライアントIPを記録している
- TLS終端位置がアプリ側、Ingress側、Application Gateway側で変わる
- mTLSをフロントエンドまたはバックエンドで使っている
- HTTPSを終端せずにSNIパススルーしたい
このあたりは、単純なHTTP 200の疎通確認だけでは検出できません。移行検証では、正常系だけでなく、証明書更新、リダイレクト、エラーレスポンス、レート制限、ログ出力まで確認することが重要です。
管理者・開発者が今すぐ作るべき移行チェックリスト
Ingress移行は、ネットワーク担当だけで完結しません。アプリ開発、セキュリティ、SRE、DNS管理、証明書管理の作業が絡みます。次の順序で進めると、影響範囲を整理しやすくなります。
| 手順 | 実施内容 | 完了条件 |
|---|---|---|
| 現状棚卸し | Ingress、IngressClass、Service、Controller Pod、Helm releaseを一覧化 | クラスターごとの公開方式が分かる |
| 依存機能の洗い出し | アノテーション、TLS、DNS、WAF、mTLS、IP保持、監視を確認 | 移行時に再現すべき機能が一覧化されている |
| 移行先選定 | Gateway API、Application Gateway for Containers、Istioなどを比較 | 要件に合う候補と採用しない理由が説明できる |
| 検証環境構築 | ステージングでGateway/HTTPRouteなどを作成 | 主要ルートが疎通し、ログと監視が取れる |
| 切り替え手順作成 | DNS TTL、証明書、ロールバック、メンテナンス時間を設計 | 作業手順書とロールバック条件がある |
| 本番移行 | 段階的にトラフィックを移す | エラー率、レイテンシ、ログ、証明書に問題がない |
| 旧構成削除 | 使わなくなったIngress Controller、Secret、DNSを削除 | 旧Controllerへの依存が残っていない |
特に、複数のAKSクラスターを運用している組織では、クラスター単位ではなく「公開アプリケーション単位」で棚卸しするのがおすすめです。1つのクラスターに複数のIngressClassが混在していたり、同じドメイン配下で異なるControllerを使っていたりすることがあるためです。
新規構築ではどの選択肢を選ぶべきか
これからAKSで新しいアプリケーションを公開するなら、自己管理のIngress NGINXを新規採用する理由はかなり限られます。Kubernetes側でも、Ingress NGINXを新規にデプロイすべきではなく、Gateway API実装を検討するよう案内されています。(GitHub)
実務上は、次のように判断すると分かりやすいです。
| 要件 | 推奨候補 |
|---|---|
| AKS内でシンプルなHTTP/HTTPS公開をしたい | Application Routing add-on、将来的にはGateway API実装を検討 |
| WAF、mTLS、重み付きルーティング、AzureホステッドなL7基盤が必要 | Application Gateway for Containers |
| サービス間通信も含めてmTLS、トラフィック制御、監視を統合したい | Istioベースのサービスメッシュアドオン |
| 既存のNGINXアノテーション資産が多い | まず棚卸しし、互換性と移行難度を評価 |
| 一時的に自己管理NGINXから公式サポートの橋渡しへ移りたい | Application Routing add-on with NGINX。ただし2026年11月以降の計画が必要 |
まとめ：AKS Ingressは「延命」ではなく「移行設計」を始める段階
AKS Ingress Networkingの更新で伝えられている本質は、Ingress NGINX終了に伴う一時対応ではなく、AKSの入口設計をGateway API中心に見直すタイミングが来たということです。Application Routing add-on with NGINXを使っている場合、すぐに障害が起きるわけではありません。しかし、2026年11月までのサポートを前提に、今のうちから移行先を決め、検証環境でルーティング、TLS、DNS、監視、クライアントIP保持を確認しておく必要があります。
まずは、kubectl get ingress -Aとkubectl get ingressclassで現状を棚卸ししてください。そのうえで、自己管理のingress-nginxは優先的に移行計画を作り、Application Routing add-on利用中の環境はGateway API実装やApplication Gateway for Containersへの移行可否を検証します。新規構築では、将来の標準化と運用分離を考え、Gateway APIを前提に設計するのが現実的です。
コメント