AKSでapplication routing add-onのManaged NGINX ingressを使っている場合、結論は「すぐに止まるわけではないが、2026年11月までに移行先を決めて検証を始めるべき」です。Ingress NGINXプロジェクトは2026年3月でメンテナンス終了が予定されており、MicrosoftはAKSのapplication routing add-onで使われるNGINX Ingressリソースについて、2026年11月まで重要なセキュリティパッチの公式サポートを提供すると案内しています。(Microsoft Learn)
この記事では、Azure Kubernetes Service（AKS）の「managed NGINX ingress with the application routing add-on」について、何が変わるのか、どのクラスターが影響を受けるのか、管理者・開発者が確認すべき設定、Gateway APIやApplication Gateway for Containersへの移行時に失敗しやすいポイントを整理します。
AKS managed NGINX ingressで何が変わるのか
今回のポイントは、AKSのapplication routing add-onが今すぐ利用不能になることではありません。重要なのは、Ingress NGINXを前提にしたL7ルーティング設計を、Gateway APIを中心とした構成へ段階的に移行する流れが明確になったことです。Microsoftは、AKSがIngressとL7トラフィック管理の長期的な標準としてGateway APIへ移行していく方針を示しています。(Microsoft Learn)
| 観点 | これまで | 今後の実務上の判断 |
|---|---|---|
| AKS application routing add-on with NGINX | AKS上で管理されたNGINX Ingress controllerとして利用 | 本番ワークロードは2026年11月までサポート対象。ただし移行計画が必要 |
| OSS版Ingress NGINX | Helmなどで自己管理するケースが多い | Gateway API、AKSのapplication routing add-on、Application Gateway for Containersなどへの移行を検討 |
| ルーティングAPI | Ingress リソース中心 | Gateway / HTTPRoute を使うGateway APIが長期候補 |
| 新規構築 | NGINX Ingressを選びがち | 将来運用を考えるとGateway APIまたはApplication Gateway for Containersを優先検討 |
「2026年11月まで使えるなら対応は後でよい」と考えるのは危険です。Ingressの移行は、単にYAMLのkindを変える作業ではなく、DNS、TLS証明書、ロードバランサー、IngressClass、NGINX固有annotation、監視、障害時の切り戻しまで含む変更です。特に本番サービスでパス書き換え、gRPC、CORS、アップロードサイズ制限、長時間接続を使っている場合は、早めに棚卸しを始める必要があります。
影響を受ける対象者
影響を受けるのは、AKSで外部または内部HTTP/HTTPSトラフィックをIngress NGINX経由で受けているチームです。application routing add-onを有効化すると、AKSはNGINX Ingress controllerを作成・構成・管理し、webapprouting.kubernetes.azure.com などのIngressClassを使うIngressオブジェクトでルーティングします。(Microsoft Learn)
まず、次のコマンドで対象範囲を確認します。
kubectl get ingressclass
kubectl get ingress -A \
-o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName,HOSTS:.spec.rules[*].host'
kubectl get nginxingresscontroller
kubectl get pods --all-namespaces \
--selector app.kubernetes.io/name=ingress-nginxKubernetes側の案内でも、Ingress NGINXを使っているか確認する方法として app.kubernetes.io/name=ingress-nginx ラベルでPodを確認する方法が示されています。AKSのManaged NGINXだけでなく、Helmなどで別途入れた自己管理版Ingress NGINXが混在している場合もあるため、クラスター単位ではなく名前空間・IngressClass単位で確認するのが安全です。(Kubernetes Contributors)
影響が大きいケース
次のような構成は、移行時の確認項目が多くなります。
| 構成 | なぜ注意が必要か |
|---|---|
nginx.ingress.kubernetes.io/* annotationを多用している | Gateway APIや別コントローラーで同じ挙動になるとは限らない |
| Key Vault証明書やAzure DNS連携を使っている | 移行先で証明書同期・DNS更新の方式が変わる可能性がある |
| 内部ロードバランサーや静的IPを使っている | GatewayやApplication Gateway for Containers側で再設計が必要 |
| パス書き換えや正規表現ルーティングを使っている | アプリ側のURL設計とルーティング仕様の再確認が必要 |
| 本番と検証でIngressClassが違う | 移行テストの結果が本番にそのまま適用できない可能性がある |
一方、Application Gateway for Containersだけを使っている環境や、AKS上でHTTP/HTTPS Ingressを利用していない環境は、この変更の直接影響は限定的です。ただし、今後AKSで新しい公開経路を作る予定がある場合は、最初からGateway APIベースで設計する価値があります。
管理者が確認すべき設定
AKS管理者が最初に見るべきポイントは、アドオンの有効化状態、IngressClass、ロードバランサー、DNS、証明書、監視です。application routing add-onには、Azure DNS連携、Azure Key Vaultに保存した証明書によるSSL終端、マネージドNGINX Ingress controllerの構成といった機能があります。(Microsoft Learn)
| 確認項目 | 確認内容 | 見落としやすいポイント |
|---|---|---|
| アドオン利用状況 | az aks approuting enable で有効化されたクラスターか | 複数クラスターで有効・無効が混在している |
| IngressClass | webapprouting.kubernetes.azure.com や独自IngressClassの利用状況 | YAMLに古いClass名が残っている |
| DNSゾーン | Azure DNSのパブリック/プライベートゾーン連携 | ゾーン数やリソースグループ制約に引っかかる |
| TLS証明書 | Key Vault URI、証明書更新、Secret同期方式 | 移行先で同じ自動化が使えるとは限らない |
| ロードバランサー | Public/Internal、静的IP、SKU、権限 | Basic/Standard SKU不一致や権限不足 |
| NGINX設定 | ConfigMap編集、snippet annotation利用有無 | AKS managedでは一部設定がサポート外 |
| 監視 | Prometheus、Grafana、P95/P99、5xx、リロード回数 | 移行前の基準値がないと比較できない |
application routing add-onには、Azure DNSゾーンは最大5つ、アドオン有効化はマネージドIDを持つAKSクラスターのみ、グローバルDNSゾーンとプライベートDNSゾーンはそれぞれ同じリソースグループに置く必要がある、といった制限があります。また、app-routing-system 名前空間の ingress-nginx ConfigMapを編集することはサポートされていません。(Microsoft Learn)
特に注意したいのがsnippet系annotationです。公式ドキュメントでは、load_module、lua_package、_by_lua、location、root、proxy_pass、serviceaccount、{、}、' などを含むsnippet annotationはブロックされ、Ingressが構成されない可能性があるとされています。過去に自己管理版NGINXで柔軟に設定していたチームほど、Managed NGINXや移行先で同じ前提が通らないことがあります。(Microsoft Learn)
開発者が確認すべきIngressマニフェスト
開発者側で重要なのは、「今のIngressがどんなNGINX固有機能に依存しているか」を洗い出すことです。host、path、service の単純なルーティングだけなら移行は比較的進めやすいですが、annotationで細かく挙動を変えている場合は、Gateway APIやApplication Gateway for Containersでの代替表現を個別に確認する必要があります。
grep -R "nginx.ingress.kubernetes.io" ./manifests ./charts ./kustomize 2>/dev/nullよく使われるannotationと確認観点は次のとおりです。NGINX Ingressのannotationでは、booleanや数値のように見える値も文字列としてクォートする必要があります。(Microsoft Learn)
| annotation例 | よくある用途 | 移行時の確認ポイント |
|---|---|---|
nginx.ingress.kubernetes.io/proxy-body-size | ファイルアップロード上限の変更 | 大容量アップロードで413が出ないか |
nginx.ingress.kubernetes.io/proxy-read-timeout | 長時間API、レポート生成、SSEなど | タイムアウト値が移行先で同等か |
nginx.ingress.kubernetes.io/backend-protocol | BackendをHTTPSまたはgRPCにする | HTTP/HTTPS/gRPCの終端位置を再確認 |
nginx.ingress.kubernetes.io/enable-cors | CORS有効化 | API側でCORS制御した方が安全な場合もある |
nginx.ingress.kubernetes.io/ssl-redirect | HTTPSリダイレクト制御 | TLS終端とリダイレクトの責務を整理 |
nginx.ingress.kubernetes.io/rewrite-target | パス書き換え | Gateway API移行時にURL設計を再検証 |
例えば、/app-one と /app-two を同一ドメイン配下で公開し、rewrite-target と正規表現でバックエンドに渡している場合、移行時に「見た目のURL」と「バックエンドが期待するURL」の差分が障害原因になります。単純にHTTPRouteへ置き換えるのではなく、アプリ側がどのパスを受け取るのか、リダイレクトURLやCookie Pathに影響がないかまで確認してください。(Microsoft Learn)
移行先の選び方
移行先は「Microsoftが推しているからGateway API」と機械的に決めるのではなく、現在の要件で選ぶべきです。AKSの公式情報では、application routing add-on利用者はGateway APIベースのapplication routing Gateway API implementationへの移行、OSS NGINX利用者はAKSのapplication routing add-on、Gateway API implementation、Application Gateway for Containersなどが選択肢として示されています。(Microsoft Learn)
| 移行先 | 向いているケース | 注意点 |
|---|---|---|
| Application routing Gateway API implementation | AKS上でGateway APIを使い、マネージドなIngress運用に寄せたい | 公式ページではプレビューとして案内。制限事項の確認が必須 |
| Application Gateway for Containers | WAF、mTLS、HTTP/2、URL rewriteなどAzureネイティブなL7機能を重視する | Azure側リソース、リージョン、価格、運用責任の確認が必要 |
| Istio-based service mesh add-on | サービスメッシュ、mTLS、細かなトラフィック制御を使う | 単なるIngress置き換えより設計範囲が広い |
| AKS Managed NGINXを当面継続 | 移行検証の時間を確保したい | 2026年11月以降を見据えた移行計画が必要 |
| 自己管理版Ingress NGINXを継続 | 既存設定を短期維持したい | 上流メンテナンス終了後のセキュリティ・運用リスクが高い |
Application routing Gateway API implementationは、Gateway APIリソースのインフラ管理のためにIstio control planeをデプロイしますが、Istio service mesh add-onとは異なり、sidecar injectionやIstio CRDサポートはありません。また、GatewayClass名は approuting-istio で、Istio service mesh add-onと同時に有効化できない点にも注意が必要です。(Microsoft Learn)
さらに、Gateway API implementationでは、application routing add-onによるAzure DNSとTLS証明書管理が現時点でサポートされていないと案内されています。TLS終端は別途ガイドに従って構成する必要があるため、既存の「Azure DNS + Key Vault連携がそのまま移る」と考えないでください。SNI Passthroughやegress traffic managementにも制限があります。(Microsoft Learn)
Application Gateway for Containersは、Kubernetesクラスター上のワークロード向けのL7ロードバランシングおよび動的トラフィック管理サービスです。Ingress APIとGateway APIをサポートし、WAF、mTLS、HTTP/2、gRPC、URL rewrite、WebSocketなどの機能が案内されています。Azureネイティブな境界防御や高度なL7制御を重視する場合は、有力な移行先になります。(Microsoft Learn)
Gateway APIへ移行する基本手順
Gateway APIへの移行では、既存Ingressを一括変換して本番投入するのではなく、ルール単位で段階的に検証するのが現実的です。公式サンプルでは、gatewayClassName: approuting-istio を指定した Gateway と HTTPRoute を作成し、外部ロードバランサー経由でアプリケーションへルーティングする流れが示されています。(Microsoft Learn)
簡略化すると、基本形は次のようになります。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: web-gateway
spec:
gatewayClassName: approuting-istio
listeners:
- name: http
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: app-route
spec:
parentRefs:
- name: web-gateway
hostnames:
- app.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: web
port: 80この例は、既存のIngressをそのまま置き換える完成形ではありません。実際には、TLS、DNS、内部/外部ロードバランサー、複数host、複数namespace、リダイレクト、パス書き換え、ヘッダー条件、監視設定を個別に移行設計へ落とし込む必要があります。
実務での移行ステップ
| 手順 | 作業内容 | 成功条件 |
|---|---|---|
| 棚卸し | Ingress、IngressClass、annotation、TLS、DNS、LBを一覧化 | 影響範囲がサービス単位で分かる |
| 分類 | 単純ルーティング、NGINX依存、TLS複雑、内部公開などに分ける | 移行難易度を見積もれる |
| 検証環境作成 | Gateway APIまたはApplication Gateway for Containersを検証環境に展開 | 本番と近い条件でテストできる |
| ルール変換 | IngressをGateway/HTTPRouteなどに置き換える | 同じhost/pathで期待通り応答する |
| DNS・証明書確認 | TTL、証明書更新、Secret同期、HTTPSリダイレクトを確認 | ブラウザ・APIクライアントで警告や失敗がない |
| 性能比較 | 2xx/3xx/4xx/5xx、P95/P99、接続数、CPU/メモリを比較 | 移行前後の差分を説明できる |
| 段階切り替え | 低リスクなサービスから移行 | 切り戻し手順がある |
| 旧構成整理 | 古いIngress、Service、DNS、証明書、アドオン残存リソースを削除 | 不要な公開口が残らない |
移行作業では、DNS切り替えだけに注目しがちですが、実際の障害は「バックエンドに渡るパスが違う」「アップロードサイズ上限が戻る」「HTTPSリダイレクトが二重になる」「gRPCがHTTP扱いになる」「証明書更新が止まる」といった細部で起きます。移行前に代表的なAPI、ログイン、ファイルアップロード、WebSocket/gRPC、管理画面、ヘルスチェックをテストケース化しておくと、切り替え後の確認が速くなります。
デプロイ時に確認すべき具体的な設定
application routing add-onは、新規AKSクラスターでは az aks create --enable-app-routing、既存クラスターでは az aks approuting enable で有効化できます。前提としてAzure CLI 2.54.0以降が必要です。(Microsoft Learn)
az aks create \
--resource-group <ResourceGroupName> \
--name <ClusterName> \
--location <Location> \
--enable-app-routing \
--generate-ssh-keys
az aks approuting enable \
--resource-group <ResourceGroupName> \
--name <ClusterName>複数のNGINX Ingress controllerを作る場合や、内部ロードバランサー、静的IPを使う場合は、NginxIngressController カスタムリソースを確認します。内部ロードバランサーでは service.beta.kubernetes.io/azure-load-balancer-internal: "true"、静的IPでは service.beta.kubernetes.io/azure-pip-name や service.beta.kubernetes.io/azure-load-balancer-resource-group などのannotationが使われます。(Microsoft Learn)
静的IPを使う場合は、AKSクラスターのIDに対象リソースグループへの Network Contributor 権限が必要です。また、Basic SKUのロードバランサーにはBasic SKUのPublic IP、Standard SKUのロードバランサーにはStandard SKUのPublic IPが必要です。SKU不一致は、移行や再作成時に見落としやすいポイントです。(Microsoft Learn)
監視では、application routing add-onのIngress NGINX controllerが /metrics をポート10254で公開し、nginx-metrics というプライベートServiceを使える点を確認します。PrometheusやAzure Monitor managed service for Prometheusで、リクエスト数、成功率、設定リロード、P50/P95/P99、CPU、メモリを移行前から記録しておくと、移行後の劣化を判断しやすくなります。(Microsoft Learn)
kubectl port-forward -n app-routing-system service/nginx-metrics :10254削除・無効化時の注意点
移行後にapplication routing add-onを無効化する場合も、いきなり削除しないでください。公式ドキュメントでは、トラフィック断を避けるため、アドオンを無効化してもConfigMap、Secret、コントローラーのDeploymentなど一部のKubernetesリソースが app-routing-system 名前空間に残ると説明されています。不要になった場合は、名前空間を削除して整理します。(Microsoft Learn)
az aks approuting disable \
--name <ClusterName> \
--resource-group <ResourceGroupName>
kubectl delete ns app-routing-systemこの削除は、対象クラスターでNGINX Ingress controller経由の通信が完全に不要になったことを確認してから実行します。残っているIngress、DNSレコード、ロードバランサーIP、証明書、監視アラートの参照先を確認せずに削除すると、意図しないサービス停止や原因調査の長期化につながります。
よくある失敗と回避策
| 失敗パターン | 原因 | 回避策 |
|---|---|---|
| Gateway APIへ移したのに通信が来ない | DNSが旧LoadBalancer IPを向いている、またはGatewayがProgrammedになっていない | kubectl wait、Gateway status、DNS解決結果を確認 |
| 一部APIだけ404になる | rewrite-target や正規表現パスの移行漏れ | URLごとの期待バックエンドを一覧化 |
| アップロードだけ失敗する | proxy-body-size 相当の設定を移していない | 大容量ファイルのテストを移行前後で実施 |
| HTTPSで警告が出る | Key Vault証明書連携やSecret同期の方式が変わった | TLS終端位置と証明書更新手順を明文化 |
| gRPCが失敗する | backend-protocol: "GRPC" 依存を見落とした | gRPCクライアントで疎通テストを行う |
| 移行後に性能差が説明できない | 移行前のメトリックがない | NGINX metrics、Grafana、アプリログを事前保存 |
| アドオン削除後もリソースが残る | app-routing-system の残存リソース仕様を知らない | 削除計画に名前空間整理を含める |
移行で最も避けたいのは、期限直前に全Ingressを一括で移すことです。まずは低リスクな社内向けアプリやステージング環境でGateway APIまたはApplication Gateway for Containersを試し、次に外部公開サービスのうちルーティングが単純なものから移行します。NGINX固有annotationが多いサービスは、最後に回すのではなく、早期に検証して代替策を見つけておくべきです。
今すぐ取るべきアクション
まず、AKSクラスターごとにIngressClass、Ingress、NGINX annotation、TLS証明書、DNS、ロードバランサーIPを棚卸ししてください。次に、サービスを「単純なhost/pathルーティング」「NGINX annotation依存」「TLS/DNS連携が複雑」「内部公開」「gRPC/WebSocketあり」に分類します。
そのうえで、2026年11月までのスケジュールを逆算します。小規模な環境なら数週間で検証できますが、複数チームがIngressを管理している場合、YAMLの修正よりもオーナー確認、テスト調整、DNS切り替え、運用手順の更新に時間がかかります。新規サービスではManaged NGINXを前提にしすぎず、Gateway APIまたはApplication Gateway for Containersを候補に入れて設計するのが現実的です。
AKS managed NGINX ingressは、今すぐ慌てて停止する対象ではありません。しかし、2026年11月までサポートされる期間は「移行を先延ばしにする猶予」ではなく、「安全に移行するための検証期間」です。今日やるべきことは、既存Ingressの棚卸し、NGINX依存の特定、移行先候補の選定です。ここまで終われば、Gateway APIへの移行もApplication Gateway for Containersへの切り替えも、場当たり的な作業ではなく計画的に進められます。
コメント