Ingresso NGINX gestito con il componente aggiuntivo Instradamento dell'applicazione

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. Non è richiesta alcuna azione immediata oggi per i cluster AKS che usano 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:

Un modo per instradare il traffico HTTP (Hypertext Transfer Protocol) e HTTPS (Hypertext Transfer Protocol Secure) alle applicazioni in esecuzione in un cluster del servizio Azure Kubernetes prevede l'uso dell'oggetto Ingress Kubernetes. Quando si abilita il componente aggiuntivo di routing dell'applicazione con NGINX, crea, configura e gestisce un controller di ingresso nel cluster del servizio Azure Kubernetes.

Questo articolo illustra come abilitare il controller di ingresso NGINX gestito e configurare un oggetto Ingress per instradare il traffico a un'applicazione nel cluster del servizio Azure Kubernetes.

Componente aggiuntivo Instradamento dell'applicazione con funzionalità NGINX

Il componente aggiuntivo Instradamento dell'applicazione con NGINX offre quanto segue:

  • Configurazione semplice dei controller Ingress NGINX gestiti basati sul controller Ingress NGINX Kubernetes.
  • Integrazione con DNS di Azure per la gestione delle zone pubbliche e private.
  • Terminazione SSL con certificati archiviati in Azure Key Vault.

Per altre configurazioni, vedere:

Importante

A partire dal 30 settembre 2027, il servizio Azure Kubernetes non supporta più il componente aggiuntivo Open Service Mesh (OSM). Il progetto Open Service Mesh upstream è stato ritirato.

Se il cluster usa il componente aggiuntivo OSM, eseguire la migrazione al componente aggiuntivo Istio prima della data di fine del supporto. Questo avviso di dismissione si applica solo al componente aggiuntivo OSM gestito e non riguarda le installazioni di service mesh open source o autogestite. Per la procedura di migrazione, vedere Indicazioni sulla migrazione dal componente aggiuntivo OSM al componente aggiuntivo Istio. Per rimanere aggiornati sugli annunci e gli aggiornamenti di AKS, consulta le note sulla versione di AKS.

Prerequisiti

  • Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, è possibile creare un account gratuito.
  • Interfaccia della riga di comando di Azure versione 2.54.0 o successiva installata e configurata. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Limitazioni

  • Il componente aggiuntivo Instradamento dell'applicazione supporta fino a cinque zone DNS di Azure.

  • Il componente aggiuntivo Instradamento dell'applicazione può essere abilitato solo nei cluster del servizio Azure Kubernetes con l'identità gestita.

  • Tutte le zone DNS di Azure globali integrate con il componente aggiuntivo devono risiedere nello stesso gruppo di risorse.

  • Tutte le zone DNS di Azure private integrate con il componente aggiuntivo devono risiedere nello stesso gruppo di risorse.

  • La modifica di ingress-nginx ConfigMap nello spazio dei nomi app-routing-system non è supportata.

  • Se un valore di annotazione del frammento di codice corrisponde a uno dei valori bloccati seguenti, l'ingresso non viene configurato:

    Valore bloccato Effetto
    load_module L'ingresso non è configurato.
    lua_package L'ingresso non è configurato.
    _by_lua L'ingresso non è configurato.
    location L'ingresso non è configurato.
    root L'ingresso non è configurato.
    proxy_pass L'ingresso non è configurato.
    serviceaccount L'ingresso non è configurato.
    { L'ingresso non è configurato.
    } L'ingresso non è configurato.
    ' L'ingresso non è configurato.

  • Il componente aggiuntivo non supporta ufficialmente l'inserimento di sidecar non gestiti da Microsoft (ad esempio, dati di telemetria personalizzati, registrazione o agenti di sicurezza) nei pod proxy in ingresso-nginx gestiti. Se si sceglie di inserire il proprio sidecar in un pod proxy gestito, Microsoft fornisce solo il supporto ottimale per eventuali problemi riscontrati.

Abilitare il componente aggiuntivo di routing dell'applicazione usando interfaccia della riga di comando di Azure

Abilitare l'instradamento dell'applicazione in un nuovo cluster

Per abilitare l'instradamento dell'applicazione in un nuovo cluster, usare il comando az aks create, specificando il flag --enable-app-routing.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --location <location> \
    --enable-app-routing \
    --generate-ssh-keys

Abilitare l'instradamento dell'applicazione in un cluster esistente

Per abilitare l'instradamento dell'applicazione in un cluster esistente, usare il comando az aks approuting enable.

az aks approuting enable --resource-group <resource-group-name> --name <cluster-name>

Connettersi al cluster del servizio Azure Kubernetes

Per connettersi al cluster Kubernetes dal computer locale, si usa kubectl, ovvero il client da riga di comando di Kubernetes. È possibile installarlo in locale usando il comando az aks install-cli. Se si usa Azure Cloud Shell, kubectl è già installato.

Configurare kubectl per connettersi al cluster Kubernetes usando il comando az aks get-credentials.

az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

Distribuire un'applicazione

Gli oggetti in ingresso Kubernetes definiscono le regole di routing per un controller in ingresso. Usare la classe in ingresso gestita del componente aggiuntivo di routing dell'applicazione e le annotazioni supportate per configurare il modo in cui il controller gestisce il traffico.

  1. Creare lo spazio dei nomi dell'applicazione denominato aks-store per eseguire i pod di esempio usando il comando kubectl create namespace.

    kubectl create namespace aks-store

  2. Distribuire l'applicazione dell'archivio del servizio Azure Kubernetes usando il file manifesto YAML seguente:

    kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/sample-manifests/docs/app-routing/aks-store-deployments-and-services.yaml -n aks-store

Questo manifesto crea rabbitmq, order-service, product-servicee store-front distribuzioni e i servizi corrispondenti. Il store-front servizio espone la porta 80, a cui in ingresso viene instradato nella sezione successiva.

Creare l'oggetto Ingress

Quando si abilita il componente aggiuntivo di routing dell'applicazione, viene creata una classe in ingresso denominata webapprouting.kubernetes.azure.com. Specificare questa classe in un oggetto Ingress per usare il controller di ingresso NGINX gestito del componente aggiuntivo.

  1. Copiare il manifesto YAML seguente in un nuovo file denominato ingress.yaml e salvare il file nel computer locale.

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: store-front
  namespace: aks-store
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  rules:
  - http:
      paths:
      - backend:
          service:
            name: store-front
            port:
              number: 80
        path: /
        pathType: Prefix

  2. Creare la risorsa di ingresso con il comando kubectl apply.

    kubectl apply -f ingress.yaml -n aks-store

    L'output di esempio seguente mostra la risorsa creata:

    ingress.networking.k8s.io/store-front created

Verificare la risorsa in ingresso gestita

È possibile verificare che l'oggetto Ingress sia stato creato usando il comando kubectl get ingress.

kubectl get ingress -n aks-store

L'output di esempio seguente mostra l'oggetto Ingress gestito creato:

NAME          CLASS                                HOSTS   ADDRESS       PORTS   AGE
store-front   webapprouting.kubernetes.azure.com   *       51.8.10.109   80      110s

È possibile verificare che l'archivio del servizio Azure Kubernetes funzioni puntando il browser all'indirizzo IP pubblico del controller in ingresso. Il comando seguente recupera l'indirizzo IP esterno assegnato dal servizio di bilanciamento del carico al servizio di ingresso NGINX nginx gestito nello spazio dei app-routing-system nomi:

kubectl get service -n app-routing-system nginx -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

Rimuovere il componente aggiuntivo Instradamento dell'applicazione

Per rimuovere lo spazio dei nomi associato, usare il comando kubectl delete namespace.

kubectl delete namespace aks-store

Per rimuovere il componente aggiuntivo Instradamento dell'applicazione dal cluster, usare il comando az aks approuting disable.

az aks approuting disable --name <cluster-name> --resource-group <resource-group-name>

Note

Per evitare potenziali interruzioni del traffico nel cluster quando si disabilita il componente aggiuntivo di routing dell'applicazione, alcune risorse kubernetes, tra cui configMap, segreti e la distribuzione che esegue il controller, rimangono nel cluster. Queste risorse si trovano nello spazio dei nomi app-routing-system. È possibile rimuovere queste risorse se non sono più necessarie eliminando lo spazio dei nomi con kubectl delete ns app-routing-system.

Contenuti correlati

  • Last updated on