Freigeben über

Konfigurieren Sie Ingress mit der Kubernetes-Gateway-API über das Anwendungsrouting-Add-on (Vorschau)

Von Bedeutung

AKS-Vorschaufunktionen sind auf Selbstbedienungsbasis und freiwillig verfügbar. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Vorsicht

Der Kubernetes SIG Network und der Sicherheitsreaktionsausschuss kündigte die bevorstehende Einstellung des Projekts Ingress NGINX an, wobei die Wartung im März 2026 endet. Für AKS-Cluster, die das Anwendungsrouting-Add-On mit NGINX verwenden, ist heute keine sofortige Aktion erforderlich. Microsoft wird offizielle Unterstützung für kritische Sicherheitspatches für NGINX Ingress-Ressourcen für das Anwendungsrouting bis November 2026 bereitstellen.

AKS passt sich dem Upstream Kubernetes an, indem es auf Gateway API als langfristigen Standard für die Verwaltung des Ingress- und L7-Datenverkehrs umstellt. Wir empfehlen Ihnen, ihren Migrationspfad basierend auf Ihrem aktuellen Setup zu planen:

  • Benutzer des Add-on Application Routing: Produktions-Workloads werden noch bis November 2026 vollständig unterstützt. Migrieren Sie auf die Application Routing Gateway API-Implementierung für eine Gateway API-basierte Verwaltung des Datenverkehrs im Eingang.
  • OSS NGINX-Benutzer haben mehrere Optionen:
  • Dienstgitterbenutzer: Wenn Sie ein Dienstgitter einführen möchten, berücksichtigen Sie das Istio-basierte Dienstgitter-Add-On. Nutzen Sie heute Istio Ingress und planen Sie die Migration auf die Unterstützung der Istio-Gateway-API, sobald sie allgemein verfügbar wird (GA).

Das Anwendungsrouting-Add-On unterstützt die Kubernetes-Gateway-API für das Management von Ingress-Traffic. Die Kubernetes-Gateway-API ist eine Reihe von Ressourcen, die ein standardisiertes, rollenorientiertes und erweiterbares Framework für die Datenverkehrsverwaltung bereitstellen, das als Nachfolger und Weiterentwicklung der Ingress-API konzipiert ist. Die Implementierung der Anwendungsroutinggateway-API soll daher als Nachfolger des verwalteten NGINX-Add-Ons dienen, das auf der älteren Ingress-API basiert und nach November 2026 keine Azure-Unterstützung mehr von Azure erhält. Wenn Sie verwaltetes NGINX verwenden, müssen Sie bis November 2026 zur Gateway-API für Anwendungsrouting-Implementierung oder einer anderen unterstützten Implementierung migrieren.

Die Api-Implementierung des Anwendungsrouting-Add-Ons Kubernetes Gateway stellt eine Istio-Steuerungsebene bereit, um die Infrastruktur für Kubernetes-Gateway-API-Ressourcen zu verwalten. Es unterscheidet sich jedoch von dem Istio-Service-Mesh-Add-On für AKS in folgender Hinsicht:

Funktion Anwendungs-Routing-Gateway-API Istio Service Mesh Add-on
Name der Gatewayklasse approuting-istio istio
Sidecar-Injektion und Istio CRD-Unterstützung Nicht unterstützt. Verwaltet nur infrastruktur für Kubernetes Gateway-API-Ressourcen Unterstützt
Überarbeitung und Aktualisierungen Nicht überarbeitet. In-Place-Upgrade für Minor- und Patch-Versions-Updates Überarbeitet. Upgrade über Canary-Upgrades für Minor-Versionsupdates und In-Place für Patch-Versionsupdates

Einschränkungen

  • Die Application Routing Gateway API-Implementierung und das Istio Service Mesh Add-on können nicht gleichzeitig aktiviert werden. Sie müssen eins zuerst deaktivieren und den anderen in einem separaten Vorgang aktivieren. Beim Übergang vom Istio Service Mesh Add-On zur Gateway-API-Implementierung für das Anwendungsrouting müssen Sie die Istio GatewayClass und Istio-CRDs löschen, nachdem Sie das Istio-Add-On deaktiviert haben. Das Istio-Add-on installiert CRDs (z. B. virtualservices.networking.istio.io, destinationrules.networking.istio.io und andere in den networking.istio.io, security.istio.io, telemetry.istio.io und extensions.istio.io API-Gruppen), die nicht entfernt werden, wenn das Add-on deaktiviert ist. Wenn diese CRDs im Cluster verbleiben, kann die Istio-Steuerungsebene der Gateway-API für das Anwendungsrouting nicht gestartet werden. Führen Sie den folgenden Befehl aus, um sie zu löschen: azurecli-interactive    kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io')    kubectl delete gatewayclass istio    > [! HINWEIS] > Wenn Sie über benutzerdefinierte Istio-Ressourcen (z. B. VirtualServices oder DestinationRules) verfügen, werden die CRDs auch gelöscht. Stellen Sie sicher, dass Sie sie nicht mehr benötigen, bevor Sie fortfahren.
  • Die Implementierung der Gateway-API für das Anwendungs-Routing verwendet dieselbe Allowlist zur Anpassung von Ressourcen wie das Istio-Add-On, um Anpassungen der ConfigMap für Gateway-Ressourcen zu validieren. Anpassungen, die nicht in der Zulassungsliste enthalten sind, werden über verwaltete Add-On-Webhooks blockiert.
  • Die Azure DNS- und TLS-Zertifikatverwaltung über das Anwendungsrouting-Add-On wird derzeit für die Kubernetes-Gateway-API nicht unterstützt. Sie können die Schritte in der Anleitung Application Routing Gateway API Implementation Secure Ingress befolgen, um ein Gateway für die Durchführung der TLS-Terminierung zu konfigurieren.
  • Das Konfigurieren des HTTPS-Eingangszugriffs auf HTTPS-Dienste – d. h. SNI-Passthrough (Server Name Indication) – über die TLSRoute Ressource wird derzeit nicht unterstützt.
  • Die Verwaltung des Egress-Datenverkehrs über die Implementierung der Application Routing Gateway API wird nicht unterstützt.

Voraussetzungen

  • Installieren Sie die aks-preview Erweiterung oder aktualisieren Sie die neueste Version der Erweiterung mithilfe der Befehle [az extension add][az-extension-add] und [az extension update][az-extension-update]. wenn Sie Azure CLI verwenden. Sie müssen Version aks-preview und höher verwenden19.0.0b24.

    # Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension to the latest version
az extension update --name aks-preview

  • Aktivieren Sie die Installation der verwalteten Gateway-API. Die Verwendung von selbstverwalteten Gateway-API-CRDs mit dem Anwendungsrouting-Add-On wird nicht unterstützt.

  • Registrieren Sie das Vorschau-Feature-Flag der App-Routing-Gateway-API.

  • Registrieren Sie das Featureflag AppRoutingIstioGatewayAPIPreview mithilfe des Befehls az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AppRoutingIstioGatewayAPIPreview"

Aktivierung der API-Implementierung des Anwendungs-Routing-Gateways

Festlegen von Umgebungsvariablen

export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

Aktivieren während der Clustererstellung

Führen Sie den folgenden Befehl aus, um die Implementierung der Anwendungsroutinggateway-API während der Clustererstellung zu aktivieren:

az aks create --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-app-routing-istio

Aktivieren für einen vorhandenen Cluster

Führen Sie den folgenden Befehl aus, um die Anwendungsroutinggateway-API-Implementierung für einen vorhandenen Cluster zu aktivieren:

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

Sie sollten istiod Pods im aks-istio-system Namespace sehen:

kubectl get pods -n aks-istio-system

NAME                      READY   STATUS    RESTARTS   AGE
istiod-54b4ff45cf-htph8   1/1     Running   0          3m15s
istiod-54b4ff45cf-wlvgd   1/1     Running   0          3m

Sie sollten auch sehen, dass die ValidatingWebhookConfiguration bereitgestellt werden:

kubectl get validatingwebhookconfiguration

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

Wenn die Installation der verwalteten Gateway-API aktiviert ist, sollten Sie auch sehen, dass die ConfigMap zur Anpassung des Istio-Gateways erstellt wird.

kubectl get cm -n aks-istio-system

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

Konfigurieren des Eingangs mithilfe eines Kubernetes-Gateways

Bereitstellen der Beispielanwendung

Stellen Sie zunächst die Beispielanwendung httpbin im default Namespace bereit:

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

Erstellen von Kubernetes-Gateway und HTTPRoute

Stellen Sie als Nächstes eine Gateway-API-Konfiguration im default Namespace bereit, wobei gatewayClassName auf approuting-istio gesetzt ist.

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

Hinweis

Im obigen Beispiel wird ein externer Eingangslastenausgleichsdienst erstellt, auf den von außerhalb des Clusters zugegriffen werden kann. Sie können Anmerkungen hinzufügen, um einen internen Lastenausgleich zu erstellen und andere Einstellungen für den Lastenausgleich anzupassen.

Hinweis

Standardmäßig hängt die Steuerungsebene von Istio den GatewayClass Namen approuting-istio an den Namen der Ressourcen an, die sie für den Gateway bereitstellt. Sie können Ihre Gateway Ressource mit gateway.istio.io/name-override kommentieren, um den Namen der bereitgestellten Ressourcen zu überschreiben. Die Ressourcennamen müssen kleiner als 63 Zeichen sein und ein gültiger DNS-Name sein.

Stellen Sie sicher, dass ein Deployment, ein Service, ein HorizontalPodAutoscaler und ein PodDisruptionBudget für httpbin-gateway erstellt werden.

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

Anforderung an Beispielanwendung senden

Versuchen Sie schließlich, eine curl Anforderung an die httpbin Anwendung zu senden. Legen Sie zunächst die Umgebungsvariable INGRESS_HOST fest:

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}')

Versuchen Sie dann, eine HTTP-Anforderung an httpbin:

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

Es sollte eine HTTP 200-Antwort angezeigt werden.

Hinweis

Informationen zum Sichern des eingehenden Datenverkehrs mit der Implementierung der Gateway-API für das Anwendungsrouting finden Sie im folgenden Leitfaden zum Synchronisieren geheimer Schlüssel aus Azure Key Vault (AKV) zum Sichern des Gateway-API-Eingangsdatenverkehrs mit TLS-Beendigung.

Versionsverwaltung und Upgrades

Die Application Gateway API-Implementierung für das Routing von Anwendungen stellt die Istio Steuerungsebene auf der Grundlage der Kubernetes-Version des AKS-Clusters bereit und führt Upgrades durch, und zwar sowohl für kleinere Versionen als auch für Patches.

Die Istio-Version ist die maximal unterstützte Istio-Nebenversion, die mit der AKS-Version Ihres Clusters kompatibel ist. Wenn Sie beispielsweise die AKS-Version 1.34 verwenden, ist die maximal unterstützte Istio-Nebenversion, die installiert ist (Stand: März 2026), 1.28. Beachten Sie, dass die maximal unterstützte Istio-Version für eine bestimmte Kubernetes-Version zwischen Long-Term Supportclustern (LTS) und Nicht-LTS-Clustern unterschiedlich sein kann.

Um die maximal unterstützte Istio-Minor-Version für Ihre AKS Kubernetes-Version zu finden, können Sie den Service Mesh Add-on-Veröffentlichungskalender überprüfen. Während die Implementierung der Application Gateway API für das Routing nicht überarbeitet wird, entspricht die Nebenversion der Istio Steuerungsebene der gegebenen Revision des Service Mesh Add-Ons (z.B.: für das Service Mesh Add-On asm-1-28 wäre die Nebenversion der Istio Steuerungsebene für das Application Routing 1.28). Sie können auch die Istio-Nebenversion sehen, indem Sie die Patchversion im istiod Bereitstellungsimage überprüfen: kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}".

Aktualisierungen

Upgrades der Patch-Version und der Nebenversion der Istio-Steuerungsebene für die Implementierung der Application Routing Gateway API finden In-Place statt. Upgrades der Patch-Version der Istio Steuerungsebene werden automatisch als Teil der AKS-Releases ausgelöst. Nebenversionsupgrades können abhängig von der AKS Kubernetes-Version und dem Zeitpunkt der Istio-Minor-Version-Veröffentlichungen automatisch oder manuell ausgelöst werden. Nebenversionsupgrades treten in den folgenden beiden Szenarien auf:

  • Der AKS-Cluster wird auf eine neue Version aktualisiert, die mit einer höheren maximal unterstützten Istio-Version angeheftet ist. Die Steuerungsebene von Istio wird im Rahmen des Upgrades des AKS-Clusters auf die höhere Minor-Version aktualisiert.
  • Eine neue Istio-Version wird für AKS veröffentlicht und ist jetzt die maximal unterstützte Istio-Version für die AKS-Clusterversion. Die Istio Steuerungsebene auf Ihrem Cluster wird automatisch auf die neue Minor-Version aktualisiert, nachdem das Release in Ihrer Region ausgerollt wurde. Folgen Sie den AKS-Versionshinweisen und der AKS-Versionsverfolgung , um neue Istio-Versionsversionen nachzuverfolgen und zu sehen, wann die neue Version für Ihre Region eingeführt wurde.

Es ist möglich, dass Während des Upgradevorgangs Verkehrsunterbrechungen auftreten können. Um Unterbrechungen bei Upgrades zu minimieren, stellt das Application Routing Add-on einen Horizontal Pod Autoscaler (HPA) mit mindestens 2 Repliken und ein PodDisruptionBudget (PDB) mit einer Mindestverfügbarkeit von 1 für jeden Gateway bereit. Sie können diese Ressourcen anpassen , um diese Einstellungen zu ändern.

Ressourcenanpassungen

Anpassung der Steuerungsebene Horizontal Pod Autoscaling (HPA)

Die Implementierung der Application Routing Gateway API unterstützt die Anpassung der Istio Steuerungsebene Horizontal Pod Autoscaler (HPA). Die istiod HPA-Ressource verfügt über die folgenden Standardkonfigurationen:

  • Minimale Repliken: 2
  • Maximale Anzahl Replikate: 5
  • CPU-Auslastung: 80%

Hinweis

Um Konflikte mit PodDisruptionBudget zu vermeiden, bietet die Application Routing Gateway API-Implementierung keine Möglichkeit, minReplicas unterhalb des anfänglichen Standards von 2 festzulegen.

Die HPA-Konfiguration kann über Patches und direkte Bearbeitungen geändert werden. Beispiel:

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

Gateway-Ressourcenanpassung

Die API-Implementierung des Anwendungsrouting-Gateways unterstützt die Anpassung der Gateway Ressourcen über Annotations und ConfigMaps. Das Application Routing bietet dieselbe Möglichkeit der Ressourcenanpassung wie das Istio Add-on für das Gateway Mesh zur Anpassung der Gateway API-Ressourcen. Folgen Sie den Schritten in den Istio Add-on Gateway API docs, um die für die Gateways generierten Ressourcen zu konfigurieren und um zu sehen, welche Felder unter die zulässige Liste fallen.

Hinweis

Die istio-gateway-class-defaults ConfigMap wird von AKS bereitgestellt und abgestimmt, wenn die Managed Gateway API CRDs und die Application Routing Gateway API Implementierung gemeinsam aktiviert sind. Wenn Sie zuvor die istio-gateway-class-defaults ConfigMap im aks-istio-system Namespace selbst erstellt haben, müssen Sie die selbstverwaltete ConfigMap-Instanz löschen, bevor Sie die CRDs der verwalteten Gateway-API aktivieren, um Konflikte beim Abgleich der von AKS verwalteten ConfigMap zu vermeiden.

Deaktivieren der API-Implementierung des Anwendungs-Routing-Gateways

Führen Sie den folgenden Befehl aus, um die Implementierung der API für Anwendungs-Routing-Gateway zu deaktivieren.

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

Bereinigen von Ressourcen

Führen Sie die folgenden Befehle aus, um Gateway und HttpRoute zu löschen.

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

Wenn Sie eine ConfigMap erstellt haben, um Ihren GatewayAnzupassen, führen Sie den folgenden Befehl aus, um die ConfigMap zu löschen:

kubectl delete configmap gw-options

Wenn Sie eine SecretProviderClass und einen geheimen Schlüssel für die TLS-Beendigung erstellt haben, löschen Sie auch die folgenden Ressourcen:

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

Nächste Schritte

Sichern Sie den eingehenden Datenverkehr mit der API-Implementierung des Anwendungs-Routing-Gateways

  • Last updated on