Azure Kubernetes Service (AKS)のアプリケーションルーティングアドオンを使用して Kubernetes Gateway API を使用してイングレスを構成する

注意事項

Kubernetes SIG Network とセキュリティ対応委員会は、イングレス NGINX プロジェクトの今後の廃止を発表し、メンテナンスは 2026 年 3 月に終了します。現在、 NGINX でアプリケーションルーティングアドオンを使用する AKS クラスターには、すぐに必要なアクションはありません。 Microsoft は、 2026 年 11 月まで、アプリケーションルーティングアドオン NGINX イングレスリソースの重要なセキュリティパッチの公式サポートを提供します。

AKS は、イングレスと L7 トラフィック管理の長期的な標準としてゲートウェイ API に移行することで、アップストリームの Kubernetes と連携しています。現在のセットアップに基づいて、移行パスの計画を開始することをお勧めします。

アプリケーションルーティングアドオンユーザー: 運用ワークロードは、2026 年 11 月まで完全にサポートされます。ゲートウェイ API ベースのイングレストラフィック管理エクスペリエンスのために、アプリケーションルーティングゲートウェイ API の実装に移行します。
OSS NGINX ユーザー には、いくつかのオプションがあります。
- NGINX を使用してアプリケーションルーティングアドオンに移行し、長期的なゲートウェイ API の移行を計画しながら、2026 年 11 月までの公式サポートの恩恵を受けることができます。
- ゲートウェイ API ベースのイングレストラフィック管理エクスペリエンスのために、アプリケーションルーティングゲートウェイ API の実装に移行します。
- イングレス API とゲートウェイ API の両方をサポートする Application Gateway for Containers に移行します。
サービスメッシュユーザー: サービス メッシュを採用する予定の場合は、 Istio ベースのサービスメッシュアドオンを検討してください。 Istio イングレスを今すぐ使用し、Istio Gateway API (現在は GA) への移行を計画します。

アプリケーションルーティングアドオンでは、イングレストラフィック管理用の Kubernetes Gateway API がサポートされています。 Kubernetes Gateway API は、イングレス API の後継および進化として設計された、トラフィック管理用の標準化されたロール指向の拡張可能なフレームワークを提供する一連のリソースです。したがって、アプリケーションルーティングゲートウェイ API の実装は、レガシイングレス API に基づくマネージド NGINX アドオンの後継として機能することを目的としており、2026 年 11 月以降に Azure からの Azure サポートの受信を停止します。マネージド NGINX を使用している場合は、2026 年 11 月までに、アプリケーションルーティングゲートウェイ API の実装または別のサポートされている実装に移行する必要があります。

運用環境のワークロードの場合、このモデルは AKS Automatic の推奨される既定のイングレスモデルです。 AKS バージョン 1.36 以降、新しい AKS 自動クラスターでは、既定でアプリケーションルーティングアドオンを介して Kubernetes Gateway API が使用されます。 AKS 自動運用の既定値の背景については、「Azure Kubernetes Service (AKS)自動とは」を参照してください。

Istio サービスメッシュアドオンとの比較

アプリケーションルーティングアドオン Kubernetes Gateway API 実装は、Kubernetes Gateway API リソースのインフラストラクチャを管理するために Istio コントロールプレーンをデプロイします。ただし、次の点で AKS の Istio サービスメッシュアドオンとは異なります。

特徴	アプリケーションルーティングゲートウェイ API	Istio サービスメッシュアドオン
ゲートウェイクラス名	`approuting-istio`	`istio`
サイドカーインジェクションと Istio CRD のサポート	サポートされていません。 Kubernetes Gateway API リソースのインフラストラクチャのみを管理する	サポートされている
リビジョンとアップグレード	変更されていません。マイナーバージョンの更新およびパッチバージョンの更新のどちらの場合も、インプレースでアップグレードされます	リビジョン化されました。マイナーバージョンの更新ではカナリアアップグレードによりアップグレードされ、パッチバージョンの更新ではインプレースでアップグレードされます

運用環境でアプリケーションルーティングゲートウェイ API を使用する場合

必要な場合は、この実装を既定のイングレスパスとして使用します。

AKS Automatic における、運用環境対応のマネージドイングレスの既定の設定。
Kubernetes Gateway API にネイティブ対応した HTTP/HTTPS イングレス。
ゲートウェイプロキシの自動スケーリングや中断予算などの運用上の保護が組み込まれたマネージドゲートウェイインフラストラクチャ。

次のような、この記事の現在のサポート外の機能が必要な場合は、代替手段を検討してください。

サイドカーベースのトラフィック管理と Istio CRD のより広範な利用による、Istio サービスメッシュの完全な動作。
TLSRoute ベースの SNI パススルーなど、現在サポートされていない機能として一覧表示されています。

制限事項

アプリケーションルーティングゲートウェイ API の実装と Istio サービスメッシュアドオンを同時に有効にすることはできません。最初に 1 つを無効にし、別の操作でもう一方を有効にする必要があります。 Istio サービスメッシュアドオンからアプリケーションルーティングゲートウェイ API 実装に移行する場合は、Istio アドオンを無効にした後、Istio GatewayClass と Istio CRD を削除する必要があります。 Istio アドオンは、アドオンが無効になっているときに削除されない CRD ( virtualservices.networking.istio.io、 destinationrules.networking.istio.ioなど) を networking.istio.io、 security.istio.io、 telemetry.istio.io、 extensions.istio.io API グループにインストールします。これらの CRD がクラスター上に残っている場合、アプリケーションルーティングゲートウェイ API Istio コントロールプレーンの起動に失敗します。次のコマンドを実行して削除します。
```
kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io')
kubectl delete gatewayclass istio
```
注

既存の Istio カスタムリソース (VirtualServices や DestinationRules など) がある場合、CRD を削除すると、それらのリソースも削除されます。続行する前に、必要がなくなったことを確認します。
アプリケーションルーティングゲートウェイ API の実装では、リソースの ConfigMap カスタマイズを検証するための Istio アドオンと同じリソースカスタマイズGatewayが使用されます。アドオンマネージド Webhook は、許可リストにないカスタマイズをブロックします。
TLSRoute リソースを介した HTTPS サービス (サーバー名表示 (SNI) パススルーなど) への HTTPS イングレスアクセスの構成は、現在サポートされていません。 AKS が Istio 1.30 のサポートを追加すると、 TLSRoute リソースのサポートが利用可能になります。この時点で、アプリケーションルーティング Istio コントロールプレーンがそのバージョンに自動的にアップグレードされます。
アプリケーションルーティングゲートウェイ API の実装によるエグレストラフィック管理はサポートされていません。
アプリケーションルーティングアドオンによって管理される Istio ゲートウェイプロキシポッドへの、Microsoft管理されていないサイドカー (カスタムテレメトリ、ログ記録、セキュリティエージェントなど) の挿入は公式にはサポートされていません。マネージドプロキシポッドに独自のサイドカーを挿入する場合、Microsoft は、発生した問題に対してベストエフォートベースのサポートのみを提供します。
ゲートウェイプロキシポッドでは Envoy アクセスログが既定で有効になっていますが、ログの形式、スコープ、プロバイダーは Istio Telemetry API を使用してカスタマイズすることはできません。カスタマイズするには、代わりに Istio サービスメッシュアドオンでゲートウェイ API イングレスを使用します。

前提条件

Azure CLI のバージョンを更新する

azure-cliバージョン2.86.0以降を使用する必要があります。 az --versionを実行してazure-cliのバージョンを見つけ、az upgradeを実行してアップグレードします。

マネージドゲートウェイ API の CRD を有効にする

Managed Gateway API のインストールを有効にします。アプリケーションルーティングアドオンでのセルフマネージドゲートウェイ API CRD の使用はサポートされていません。

AKS 自動既定の動作 (AKS 1.36 以降)

AKS 1.36 以降を実行する新しい AKS 自動クラスターでは、アプリケーションルーティングアドオンを介した Kubernetes Gateway API が既定で有効になります。

通常、次の場合を除き、機能有効化コマンドを実行する必要はありません。

既存のクラスターの使用。
以前の AKS バージョンを実行しています。
機能を無効にした後に再び有効にします。

アプリケーションルーティングゲートウェイ API の実装を有効にする

注

AKS 1.36 以降で新しい AKS 自動クラスターを作成する場合、この機能は既定で有効になっています。このセクションのコマンドは、AKS Standard クラスター、以前のバージョン、または機能がまだ有効になっていない既存のクラスターに対して使用します。

クラスターの作成時に有効にする

AKS Standard クラスターの作成時にアプリケーションルーティングゲートウェイ API の実装を有効にするには、次のコマンドを実行します。

# Set environment variables
export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

# Enable the application routing Gateway API implementation during AKS Standard cluster creation
az aks create --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-app-routing-istio

既存のクラスターに対して有効にする

次のコマンドを実行して、既存のクラスターのアプリケーションルーティングゲートウェイ API の実装を有効にします。

# Set environment variables
export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

# Enable the application routing Gateway API implementation for an existing cluster
az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-app-routing-istio

istiod名前空間にaks-istio-systemポッドが表示されます。

kubectl get pods -n aks-istio-system

NAME                      READY   STATUS    RESTARTS   AGE
istiod-12a3bc45de-fghi6   1/1     Running   0          3m15s
istiod-78j9kl01mn-opqrs   1/1     Running   0          3m

次にValidatingWebhookConfigurationがデプロイされることが確認できます。

kubectl get validatingwebhookconfiguration

NAME                                        WEBHOOKS   AGE
aks-node-validating-webhook                 1          117m
azure-service-mesh-ccp-validating-webhook   1          4m2s

Managed Gateway API のインストールが有効になっている場合は、Istio ゲートウェイのカスタマイズ ConfigMap も作成されます。

kubectl get cm -n aks-istio-system

NAME                                  DATA   AGE
...
istio-gateway-class-defaults          2      43s
...

Kubernetes ゲートウェイを使用してイングレスを構成する

サンプルアプリケーションをデプロイする

まず、httpbin名前空間にサンプル default アプリケーションをデプロイします。

export ISTIO_RELEASE="release-1.27"
kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_RELEASE/samples/httpbin/httpbin.yaml

Kubernetes ゲートウェイと HTTPRoute を作成する

次に、defaultを gatewayClassName に設定して、approuting-istio名前空間にゲートウェイ API 構成をデプロイします。

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: httpbin-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: httpbin
spec:
  parentRefs:
  - name: httpbin-gateway
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
EOF

注

上記の例では、クラスターの外部からアクセスできる外部イングレスロードバランサーサービスを作成します。注釈を追加して内部ロードバランサーを作成し、他のロードバランサー設定をカスタマイズできます。

注

既定では、Istio コントロールプレーンは、GatewayClass用にプロビジョニングするリソースの名前にapprouting-istioGateway名を追加します。 Gatewayを使用してgateway.istio.io/name-override リソースに注釈を付けて、プロビジョニングされたリソースの名前をオーバーライドできます。リソース名は 63 文字未満で、有効な DNS 名である必要があります。

Deployment用にService、HorizontalPodAutoscaler、PodDisruptionBudget、httpbin-gatewayが作成されることを確認します。

kubectl get deployment httpbin-gateway-approuting-istio

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
httpbin-gateway-approuting-istio   2/2     2            2           6m41s

kubectl get service httpbin-gateway-approuting-istio

NAME                               TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)                        AGE
httpbin-gateway-approuting-istio   LoadBalancer   10.0.54.96   <external-ip>    15021:30580/TCP,80:32693/TCP   7m13s

kubectl get hpa httpbin-gateway-approuting-istio

NAME                               REFERENCE                                     TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
httpbin-gateway-approuting-istio   Deployment/httpbin-gateway-approuting-istio   cpu: 3%/80%   2         5         2          8m13s

kubectl get pdb httpbin-gateway-approuting-istio

NAME                               MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
httpbin-gateway-approuting-istio   1               N/A               1                     9m1s

サンプルアプリケーションに要求を送信する

最後に、curl アプリケーションにhttpbin要求を送信してみてください。まず、 INGRESS_HOST 環境変数を設定します。

kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway
export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -ojsonpath='{.status.addresses[0].value}')

次に、 httpbinに HTTP 要求を送信してみてください。

curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

HTTP 200応答が表示されます。

注

アプリケーションルーティングゲートウェイ API 実装を使用してイングレストラフィックをセキュリティで保護し、ホスト名管理用のAzure DNSと統合するには、アプリケーションルーティングオペレーターを利用した自動化されたワークフロー用のアプリケーションルーティングゲートウェイ API 実装を使用してAzure DNSと TLS を構成する方法に関する記事を参照してください。オペレーターの統合に依存しない手動 TLS 終了ワークフローについては、アプリケーションルーティングゲートウェイ API の実装によるイングレストラフィックのセキュリティ保護に関する記事を参照してください。

アクセスログ

アプリケーションルーティングゲートウェイ API の実装により、すべてのマネージド Gateway プロキシポッドで Envoy アクセスログが既定で有効になります。アクセスログは、既定の Envoy テキスト形式でプロキシコンテナーの標準出力に書き込まれます。次の kubectl logsを使用してログを表示できます。

kubectl logs deployment/<your-gateway-name>-approuting-istio

ゲートウェイが処理する各要求は、HTTP メソッド、パス、応答コード、アップストリームサービス、要求と応答のサイズなどの詳細を含むログ行を生成します。この詳細により、追加の構成なしで、イングレストラフィックの監視とルーティングの問題のトラブルシューティングが簡単になります。

バージョン管理とアップグレード

アプリケーションルーティングゲートウェイ API の実装では、マイナーバージョンとパッチバージョンのアップグレードの両方について、AKS クラスターの Kubernetes バージョンに基づいて Istio コントロールプレーンがデプロイおよびアップグレードされます。このインプレースモデルは、AKS 自動運用の既定値に合わせ、プラットフォームライフサイクル管理は手動操作を減らすように設計されています。

Istio バージョンは、お使いのクラスターの AKS バージョンと互換性のある、サポート対象の Istio マイナーバージョンのうち最も高いバージョンです。たとえば、AKS バージョン 1.34を使用している場合、(2026 年 3 月の時点で) サポートされている Istio マイナーバージョンの最大数は 1.28。特定の Kubernetes バージョンでサポートされる Istio の最大バージョンは、 Long-Term サポート (LTS) クラスターと LTS 以外のクラスターで異なる場合があることに注意してください。

AKS Kubernetes バージョンでサポートされている Istio マイナーバージョンの最大数を確認するには、サービスメッシュアドオンリリースカレンダーを確認してください。アプリケーションルーティングゲートウェイ API の実装はリビジョン化されていませんが、Istio コントロールプレーンのマイナーバージョンは、指定されたサービスメッシュアドオンリビジョンに対応します (サービスメッシュアドオン asm-1-28の場合、アプリケーションルーティング Istio コントロールプレーンのマイナーバージョンは 1.28)。 istiod デプロイイメージでパッチバージョンを確認することで、Istio マイナーバージョンを確認することもできます。

kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}"

アップグレード

アプリケーションルーティングゲートウェイ API 実装用の Istio コントロールプレーンの修正プログラムとマイナーバージョンのアップグレードが行われます。パッチバージョンのアップグレードは、AKS リリースの一部として自動的にトリガーされます。マイナーバージョンのアップグレードは、AKS Kubernetes のバージョンと Istio マイナーバージョンリリースのタイミングに応じて、自動的または手動でトリガーできます。マイナーバージョンのアップグレードは、次のシナリオで発生します。

AKS クラスターは、サポートされている Istio の最大バージョンがピン留めされた新しいバージョンにアップグレードされます。 Istio コントロールプレーンは、AKS クラスターのアップグレードの一環として、より高いマイナーバージョンにアップグレードされます。
AKS 用に新しい Istio バージョンがリリースされ、AKS クラスターバージョンでサポートされている最大 Istio バージョンになります。リージョンへのロールアウト後、クラスター上の Istio コントロールプレーンが新しいマイナーバージョンに自動的にアップグレードされます。新しい Istio バージョンのリリースを追跡し、新しいバージョンがリージョンにロールアウトされるタイミングを確認するには、 AKS リリースノートと AKS リリーストラッカーに従ってください。

トラフィックの中断は、アップグレードプロセス中に発生する可能性があります。アップグレード中の停止を最小限に抑えるため、アプリケーションルーティングアドオンでは、各 Gateway に対して、最小レプリカ数 2 の Horizontal Pod Autoscaler (HPA) と、最小可用数 1 の PodDisruptionBudget (PDB) をデプロイします。これらのリソースをカスタマイズして、これらの設定を変更できます。

リソースのカスタマイズ

コントロールプレーンの水平ポッドオートスケーリング (HPA) のカスタマイズ

アプリケーションルーティングゲートウェイ API の実装では、Istio コントロールプレーンの水平ポッドオートスケーラー (HPA) のカスタマイズがサポートされています。 istiod HPA リソースには、次の既定の構成があります。

最小レプリカ数: 2
最大レプリカ数: 5 個
CPU 使用率: 80%

注

PodDisruptionBudgetとの競合を防ぐために、アプリケーションルーティングゲートウェイ API の実装では、minReplicasを既定の 2 未満に設定することはできません。

HPA の構成は、修正プログラムと直接編集を使用して変更できます。例：

kubectl patch hpa istiod -n aks-istio-system --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

ゲートウェイリソースのカスタマイズ

アプリケーションルーティングゲートウェイ API の実装では、注釈と ConfigMap を使用した Gateway リソースのカスタマイズがサポートされています。アプリケーションルーティングでは、ゲートウェイ API リソースカスタマイズ用の Istio サービスメッシュアドオンと同じリソースカスタマイズ許可リストが使用されます。 Istio アドオンゲートウェイ API ドキュメントの手順に従って、Gateways用に生成されたリソースを構成し、許可リストに含まれるフィールドを確認します。

注

istio-gateway-class-defaults ConfigMap は、マネージドゲートウェイ API の CRD とアプリケーションルーティングゲートウェイ API の実装が一緒に有効になっている場合に、AKS によってプロビジョニングおよび調整されます。 istio-gateway-class-defaults名前空間に aks-istio-system ConfigMap を自分で作成した場合は、マネージドゲートウェイ API の CRD を有効にする前に、自己管理の ConfigMap インスタンスを削除して、AKS で管理される ConfigMap の調整との競合を回避する必要があります。

注

アプリケーションルーティング Gateway API の実装では、既定の設定である "Cluster" の正常性プローブを設定するために、Gateway Service に externalTrafficPolicy を追加します。spec.externalTrafficPolicy を "Local" に設定する場合は、GatewayClass レベルの ConfigMap または Gateway ごとの ConfigMap で、次のアノテーションを解除する必要があります。

 service: |
    spec:
       externalTrafficPolicy: Local
    metadata:
      annotations:
        service.beta.kubernetes.io/port_80_health-probe_port:
        service.beta.kubernetes.io/port_80_health-probe_protocol:
        service.beta.kubernetes.io/port_80_health-probe_request-path:

アプリケーションルーティングゲートウェイ API の実装を無効にする

次のコマンドを実行して、アプリケーションルーティングゲートウェイ API の実装を無効にします。

az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --disable-app-routing-istio

リソースをクリーンアップする

次のコマンドを実行して、 Gateway と HTTPRoute リソースを削除します。

kubectl delete gateways.gateway.networking.k8s.io httpbin-gateway
kubectl delete httproute httpbin

Gatewayをカスタマイズするために ConfigMap を作成した場合は、次のコマンドを実行して ConfigMap を削除します。

kubectl delete configmap gw-options

TLS 終了に使用する SecretProviderClass とシークレットを作成した場合は、次のリソースを削除します。

kubectl delete secret httpbin-credential
kubectl delete pod secrets-store-sync-httpbin
kubectl delete secretproviderclass httpbin-credential-spc

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-02

Azure Kubernetes Service (AKS)のアプリケーション ルーティング アドオンを使用して Kubernetes Gateway API を使用してイングレスを構成する

Istio サービス メッシュ アドオンとの比較

運用環境でアプリケーション ルーティング ゲートウェイ API を使用する場合