Condividi tramite

Configurare l'ingresso con l'API del gateway Kubernetes tramite il componente aggiuntivo di instradamento dell'applicazione (anteprima)

Importante

Le funzionalità di anteprima di AKS sono disponibili su base self-service, su scelta. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Attenzione

Kubernetes SIG Network e il Security Response Committee hanno annunciato il ritiro imminente del progetto NGINX in ingresso, con la manutenzione che termina a marzo 2026. Attualmente non è necessaria alcuna azione immediata per i cluster AKS che utilizzano il componente aggiuntivo di routing delle applicazioni con NGINX. Microsoft fornirà il supporto ufficiale per le patch di sicurezza critiche per le risorse di ingresso NGINX per il routing delle applicazioni fino a novembre 2026.

AKS è in linea con Kubernetes upstream passando a Gateway API come standard a lungo termine per la gestione del traffico L7 e degli ingressi. È consigliabile iniziare a pianificare il percorso di migrazione in base alla configurazione corrente:

Il componente aggiuntivo di routing dell'applicazione supporta l'API gateway Kubernetes per la gestione del traffico in ingresso. L'API del gateway Kubernetes è un set di risorse che forniscono un framework standardizzato, orientato ai ruoli ed estendibile per la gestione del traffico, progettato per essere un successore e un'evoluzione dell'API in ingresso. L'implementazione dell'API di Gateway per il routing dell'applicazione mira quindi a fungere da successore del componente aggiuntivo NGINX gestito, basato sull'API Ingress legacy e smetterà di ricevere il supporto di Azure dopo novembre 2026. Se si usa NGINX gestito, è necessario eseguire la migrazione all'implementazione dell'API del gateway di routing dell'applicazione o a un'altra implementazione supportata entro novembre 2026.

L'implementazione del componente aggiuntivo di instradamento dell'applicazione con l'API del gateway Kubernetes distribuisce un piano di controllo Istio per gestire l'infrastruttura delle risorse dell'API stessa. Tuttavia, differisce dal componente aggiuntivo Mesh del servizio Istio per il servizio Azure Kubernetes nei seguenti modi:

Feature API di Gateway di instradamento delle applicazioni Componente aggiuntivo di Istio Service Mesh
Nome classe gateway approuting-istio istio
Inserimento sidecar e supporto per le definizioni di risorse personalizzate Istio Non supportato. Gestisce solo l'infrastruttura per le risorse dell'API del gateway Kubernetes Supportato
Revisione e aggiornamenti Non aggiornato. Aggiornamento in loco per gli aggiornamenti secondari e patch delle versioni Revisionato. Aggiornamento di tipo canary per gli aggiornamenti secondari delle versioni e in loco per gli aggiornamenti patch.

Limitazioni

  • L'implementazione dell'API gateway di routing dell'applicazione e il componente aggiuntivo Mesh del servizio Istio non possono essere abilitati contemporaneamente. È necessario disabilitare un primo e abilitare l'altro in un'operazione separata. Quando si esegue la transizione dal componente aggiuntivo della rete di servizi Istio all'implementazione dell'API del gateway di routing dell'applicazione, è necessario eliminare Istio GatewayClass e i CRD Istio dopo aver disabilitato il componente aggiuntivo Istio. Il componente aggiuntivo Istio installa i CRD (ad esempio virtualservices.networking.istio.io, destinationrules.networking.istio.io, e altri nei gruppi API networking.istio.io, security.istio.io, telemetry.istio.io, e extensions.istio.io) che non vengono rimossi quando il componente aggiuntivo è disabilitato. Se questi CRD rimangono nel cluster, il piano di controllo Istio dell'API Gateway di routing dell'applicazione non riesce ad avviarsi. Eseguire il comando seguente per eliminarli: azurecli-interactive    kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io')    kubectl delete gatewayclass istio    > [! NOTA] > Se sono presenti risorse personalizzate Istio (ad esempio VirtualServices o DestinationRules), l'eliminazione dei CRL eliminerà anche tali risorse. Assicurarsi che non siano più necessari prima di procedere.
  • L'implementazione dell'API gateway di routing dell'applicazione usa lo stesso elenco di opzioni consentite di personalizzazione delle risorse del componente aggiuntivo Istio per convalidare le personalizzazioni configMap per Gateway le risorse. Le personalizzazioni non presenti nell'elenco elementi consentiti vengono bloccate tramite webhook gestiti da componenti aggiuntivi.
  • La gestione dei certificati TLS e DNS di Azure tramite il componente aggiuntivo di routing delle applicazioni non è attualmente supportata per l'API del gateway Kubernetes. È possibile seguire la procedura descritta nella guida all'implementazione sicura dell'API Gateway di routing dell'applicazione per configurare un'istanza Gateway per l'esecuzione della terminazione TLS.
  • La configurazione dell'accesso in ingresso HTTPS ai servizi HTTPS, ad esempio pass-through di indicazione nome server tramite la risorsa TLSRoute, non è attualmente supportata.
  • La gestione del traffico in uscita tramite l'implementazione dell'API del gateway di routing dell'applicazione non è supportata.

Prerequisiti

  • Installare l'estensione o eseguire l'aggiornamento aks-preview alla versione più recente dell'estensione usando i comandi [az extension add][az-extension-add] e [az extension update][az-extension-update]. Se stai utilizzando l'interfaccia della riga di comando di Azure. È necessario usare la aks-preview versione 19.0.0b24 e versioni successive.

    # 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

  • Abilitare l'installazione dell'API del gateway gestito. L'uso dei CRD dell'API Gateway autogestiti con il componente aggiuntivo per il routing delle applicazioni non è supportato.

  • Registrare il flag di funzionalità di anteprima dell'API del gateway di instradamento dell'applicazione

  • Registrare il flag della funzionalità AppRoutingIstioGatewayAPIPreview usando il comando az feature register.

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

Abilitare l'implementazione dell'API del gateway di routing dell'applicazione

Impostare le variabili di ambiente

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

Abilitare durante la creazione del cluster

Eseguire il comando seguente per abilitare l'implementazione dell'API del gateway di routing dell'applicazione durante la creazione del cluster:

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

Abilitare per un cluster esistente

Eseguire il comando seguente per abilitare l'implementazione dell'API gateway di routing dell'applicazione per un cluster esistente:

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

I pod istiod devono essere visualizzati nello spazio dei nomi aks-istio-system:

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

Dovresti anche vedere il ValidatingWebhookConfiguration venire distribuito:

kubectl get validatingwebhookconfiguration

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

Se l'installazione dell'API del gateway gestito è abilitata, deve essere visualizzata anche la creazione dell'oggetto ConfigMap per la personalizzazione del gateway Istio:

kubectl get cm -n aks-istio-system

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

Configurare l'ingresso con un gateway Kubernetes

Distribuire l'applicazione di esempio

Per prima cosa, distribuisci l'applicazione di esempio httpbin nello spazio dei nomi default

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

Creare un Gateway di Kubernetes e un HTTPRoute

Distribuire quindi una configurazione dell'API del gateway nello spazio dei nomi default con gatewayClassName impostato su approuting-istio.

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

Annotazioni

L'esempio precedente crea un servizio di bilanciamento del carico in ingresso esterno accessibile dall'esterno del cluster. È possibile aggiungere annotazioni per creare un servizio di bilanciamento del carico interno e personalizzare altre impostazioni del servizio di bilanciamento del carico.

Annotazioni

Per impostazione predefinita, il piano di controllo Istio aggiungerà il nome GatewayClass al nome delle risorse approuting-istio di cui effettua il provisioning per il Gateway. È possibile aggiungere alla risorsa Gateway in uso l'annotazione gateway.istio.io/name-override per sostituire il nome delle risorse con provisioning. I nomi delle risorse devono essere minori di 63 caratteri e devono essere un nome DNS valido.

Verificare che siano stati creati un Deployment, Service, HorizontalPodAutoscaler e PodDisruptionBudget per 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

Inviare una richiesta all'applicazione di esempio

Infine, provare a inviare una curl richiesta all'applicazione httpbin . Prima di tutto, impostare la INGRESS_HOST variabile di ambiente:

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

Provare quindi a inviare una richiesta HTTP a httpbin:

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

Verrà visualizzata una HTTP 200 risposta.

Annotazioni

Per proteggere il traffico in ingresso con l'implementazione dell'API gateway di routing dell'applicazione, vedere la guida seguente per sincronizzare i segreti da Azure Key Vault (AKV) per proteggere il traffico in ingresso dell'API gateway con terminazione TLS.

Controllo delle versioni e aggiornamenti

L'implementazione dell'API del gateway di instradamento dell'applicazione distribuisce e aggiorna il piano di controllo Istio in base alla versione Kubernetes del cluster del servizio Azure Kubernetes per gli aggiornamenti secondari e batch della versione.

La versione di Istio è la versione secondaria di Istio massima supportata e compatibile con la versione del servizio Azure Kubernetes del cluster. Ad esempio, se si usa la versione 1.34 di Azure Kubernetes Service (AKS), la massima versione secondaria di Istio supportata e installata (a partire da marzo 2026) è 1.28. Tenere presente che la versione massima di Istio supportata per una determinata versione di Kubernetes può differire tra cluster a supporto a lungo termine (LTS) e cluster non a lungo termine (non LTS).

Per trovare la versione secondaria massima supportata di Istio per la versione di AKS Kubernetes, è possibile controllare il calendario di rilascio dell'add-on del service mesh. Anche se l'implementazione dell'API del gateway di routing dell'applicazione non viene modificata, la versione secondaria del piano di controllo Istio corrisponde alla revisione del componente aggiuntivo service mesh specificata (ad esempio, per il componente aggiuntivo service mesh asm-1-28, la versione secondaria del piano di controllo Istio di routing dell'applicazione sarà 1.28). È possibile visualizzare anche la versione secondaria di Istio controllando la versione della patch nell'immagine di distribuzione istiod: kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}".

Aggiornamenti

Gli aggiornamenti patch e secondari della versione del piano di controllo Istio per l'implementazione dell'API del gateway di instradamento dell'applicazione avvengono in loco. Gli aggiornamenti patch delle versioni del piano di controllo Istio vengono attivati automaticamente nell'ambito dei rilasci del servizio Azure Kubernetes. Gli aggiornamenti delle versioni minori possono essere attivati automaticamente o manualmente a seconda della versione di AKS Kubernetes e della tempistica delle versioni minori di Istio. Gli aggiornamenti di versione secondaria si verificano nei due scenari seguenti:

  • Il cluster del servizio Azure Kubernetes viene aggiornato a una nuova versione, che ha una versione superiore di Istio massima supportata associata. Il piano di controllo Istio verrà aggiornato alla versione secondaria successiva durante l'aggiornamento del cluster del servizio Azure Kubernetes.
  • Viene rilasciata una nuova versione di Istio per il servizio Azure Kubernetes ed è ora la versione istio massima supportata per la versione del cluster del servizio Azure Kubernetes. Il piano di controllo Istio nel cluster verrà aggiornato automaticamente alla nuova versione minore dopo il rilascio nella tua area. Consulta le note di rilascio di AKS e lo strumento di monitoraggio dei rilasci di AKS per tenere traccia dei nuovi rilasci della versione di Istio e sapere quando la nuova versione viene distribuita nella tua regione.

È possibile che si verifichino interruzioni del traffico durante il processo di aggiornamento. Per ridurre al minimo le interruzioni durante gli aggiornamenti, il componente aggiuntivo di routing dell'applicazione distribuisce un Horizontal Pod Autoscaler (HPA) con un minimo di 2 repliche e un PodDisruptionBudget (PDB) con una disponibilità minima di 1 per ogni Gateway. È possibile personalizzare queste risorse per modificare queste impostazioni.

Personalizzazioni delle risorse

Personalizzazione della scalabilità automatica orizzontale dei pod (HPA) del piano di controllo

L'implementazione dell'API del gateway di instradamento dell'applicazione supporta la personalizzazione della scalabilità automatica orizzontale dei pod (HPA) del piano di controllo Istio. La istiod risorsa HPA ha le configurazioni predefinite seguenti:

  • Replica Minime: 2
  • Numero massimo di repliche: 5
  • Utilizzo CPU: 80%

Annotazioni

Per evitare conflitti con PodDisruptionBudget, l'implementazione dell'API del gateway di routing dell'applicazione non consente di impostare il minReplicas al di sotto del valore predefinito iniziale di 2.

La configurazione HPA può essere modificata tramite patch e modifiche dirette. Esempio:

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

Personalizzazione delle risorse del gateway

L'implementazione dell'API di gateway per il routing delle applicazioni supporta la personalizzazione delle risorse tramite annotazioni e ConfigMaps. Il routing delle applicazioni usa lo stesso elenco di elementi consentiti di personalizzazione delle risorse del componente aggiuntivo Istio service mesh per la personalizzazione delle risorse dell'API gateway. Seguire la procedura descritta nella documentazione dell'API del gateway del componente aggiuntivo Istio per configurare le risorse generate per Gateways e per vedere quali campi rientrano nell'elenco di elementi consentiti.

Annotazioni

L'oggetto istio-gateway-class-defaults ConfigMap viene sottoposto a provisioning e riconciliato dal servizio Azure Kubernetes quando le definizioni di risorse personalizzate dell'API del gateway gestito e l'implementazione dell'API del gateway di instradamento dell'applicazione vengono abilitati contemporaneamente. Se in precedenza hai creato ConfigMap istio-gateway-class-defaults nello spazio dei nomi aks-istio-system manualmente, è necessario eliminare l'istanza di ConfigMap autogestita prima di abilitare i CRD dell'API del gateway gestito per evitare conflitti con la riconciliazione del ConfigMap gestito da AKS.

Disabilitare l'implementazione dell'API del gateway di routing dell'applicazione

Eseguire il comando seguente per disabilitare l'implementazione dell'API del gateway di routing dell'applicazione:

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

Pulizia delle risorse

Eseguire i seguenti comandi per eliminare il Gateway e il HttpRoute.

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

Se è stato creato un oggetto ConfigMap per personalizzare Gateway, eseguire il comando seguente per eliminare ConfigMap:

kubectl delete configmap gw-options

Se è stato creato un secretProviderClass e un segreto da usare per la terminazione TLS, eliminare anche le risorse seguenti:

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

Passaggi successivi

Proteggere il traffico in ingresso con l'implementazione dell'API gateway di routing dell'applicazione

  • Last updated on