Ingresso nel servizio Azure Kubernetes

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:

L'ingresso nel servizio Azure Kubernetes è una risorsa Kubernetes che gestisce l'accesso del traffico di tipo HTTP esterno ai servizi all'interno di un cluster. Un ingresso del servizio Azure Kubernetes potrebbe fornire servizi come bilanciamento del carico, terminazione SSL e hosting virtuale basato sul nome. Per altre informazioni sull'ingresso Kubernetes, vedere la documentazione sull'ingresso Kubernetes.

Per la maggior parte dei carichi di lavoro di produzione, inizia con AKS Automatic. AKS Automatic è l'impostazione predefinita consigliata e pronta per la produzione in AKS e fornisce configurazioni predefinite gestite per la rete, il ridimensionamento, la sicurezza, il monitoraggio e gli aggiornamenti. Per l'ingresso, ciò significa che è possibile iniziare con il percorso di ingresso gestito e passare solo a opzioni più specializzate quando è necessario un controllo più approfondito sulla topologia, il comportamento di routing o l'integrazione della mesh del servizio.

Usa AKS Standard quando hai bisogno di un controllo più granulare sulla selezione dell'ingress controller, sulla topologia di distribuzione o sull'integrazione di rete avanzata.

Modalità e ingresso del cluster del servizio Azure Kubernetes

AKS supporta due modalità del cluster:

  • AKS Automatic: Punto di partenza consigliato per la maggior parte dei carichi di lavoro di produzione. Riduce il sovraccarico operativo e offre impostazioni predefinite gestite per l'ingresso e i componenti di rete correlati.
  • AKS Standard: ideale quando è necessario un controllo esplicito sull'hosting dell'ingress controller, sull'esposizione dei servizi e sui modelli avanzati di gestione del traffico.

Le linee guida per l'ingresso in questo articolo si applicano a entrambe le modalità. La differenza principale è chi possiede più impostazioni predefinite della piattaforma e quanto personalizzazione è necessario gestire direttamente.

Controller in ingresso

Quando si gestisce il traffico dell'applicazione, i controller in ingresso offrono funzionalità avanzate operando al livello 7. Possono instradare il traffico HTTP ad applicazioni diverse in base all'URL in ingresso, consentendo regole di distribuzione del traffico più intelligenti e flessibili. Ad esempio, un controller in ingresso può indirizzare il traffico a microservizi diversi a seconda del percorso URL, migliorando l'efficienza e l'organizzazione dei servizi.

D'altra parte, un servizio di tipo LoadBalancer, quando creato, configura una risorsa di bilanciamento del carico di Azure sottostante. Questo servizio di bilanciamento del carico opera al livello 4, distribuendo il traffico ai pod nel servizio su una porta specificata. Tuttavia, i servizi di livello 4 sono inconsapevoli delle applicazioni effettive e non possono implementare questi tipi di regole di routing complesse.

Comprendere la distinzione tra questi due approcci consente di selezionare lo strumento appropriato per le esigenze di gestione del traffico.

Se usi AKS Automatic, inizia con l'opzione di ingresso gestita e usa opzioni più specializzate solo quando il tuo carico di lavoro le richiede. In AKS Standard, si ha maggiore flessibilità nella scelta del controller di ingresso e della topologia più adatti alla propria architettura.

Diagramma che mostra il flusso del traffico in ingresso in un cluster del servizio Azure Kubernetes

Confrontare le opzioni in ingresso

Confronto delle funzionalità

Nella tabella seguente sono elencate le differenze di funzionalità tra le diverse opzioni del controller di ingresso. Per la maggior parte dei workload AKS in produzione, la scelta predefinita consigliata è l'approccio con ingresso gestito in AKS Automatic, a meno che non siano necessari routing personalizzato, integrazione con un service mesh o un ingresso ospitato in Azure.

Funzionalità Componente aggiuntivo per l'instradamento delle applicazioni Gateway applicativo per contenitori Azure Service Mesh/Istio Service Mesh
Controller in ingresso/gateway Controller di ingresso NGINX Gateway applicativo per contenitori di Azure Gateway in ingresso Istio
api API ingresso API in ingresso e API gateway Istio Ingress API
Servizio di hosting Nel cluster Ospitato in Azure Nel cluster
Ridimensionamento Scalabilità automatica Scalabilità automatica Scalabilità automatica
Bilanciamento del carico Interno/esterno Esterno Interno/esterno
Terminazione SSL Nel cluster Sì: offload e SSL E2E Nel cluster
mTLS N/D Sì: front-end e back-end
Indirizzo IP statico FQDN (nessun indirizzo IP statico) N/D
Certificati SSL archiviati in Azure Key Vault N/D
Integrazione DNS di Azure per la gestione della zona DNS N/D

Quando usare ogni controller di ingresso

La tabella seguente elenca i diversi scenari in cui è possibile usare ogni controller in ingresso:

Opzione in ingresso Utilizzo
NGINX gestito - componente aggiuntivo per il routing delle applicazioni • Controller in ingresso NGINX ospitati, personalizzabili e scalabili nel cluster.
• Funzionalità di bilanciamento del carico e routing di base.
• Configurazione del servizio di bilanciamento del carico interno ed esterno.
• Configurazione dell'indirizzo IP statico.
• Integrazione con Azure Key Vault per la gestione dei certificati.
• Integrazione con DNS di Azure zone per la gestione DNS pubblica e privata.
• Supporta l'API Ingress.
Gateway applicativo per contenitori • Gateway in ingresso ospitato in Azure.
• Strategie di distribuzione flessibili gestite dal controller oppure usando il proprio Application Gateway for Containers.
• Funzionalità avanzate di gestione del traffico, ad esempio tentativi automatici, resilienza delle zone di disponibilità, autenticazione reciproca (mTLS) alla destinazione back-end, suddivisione del traffico/round robin ponderato e scalabilità automatica.
• Integrazione con Azure Key Vault per la gestione dei certificati.
• Integrazione con DNS di Azure zone per la gestione DNS pubblica e privata.
• Supporta le API Ingress e Gateway.
Gateway in ingresso Istio • Basato su Envoy, quando si usa con Istio per una mesh di servizi.
• Funzionalità avanzate di gestione del traffico, ad esempio la limitazione della frequenza e l'interruzione del circuito.
• Supporto di mTLS.

Note

Il componente aggiuntivo Istio attualmente non supporta l'API gateway per il traffico in ingresso Istio.

Creare una risorsa in ingresso

Il componente aggiuntivo Application Routing è il modo consigliato per configurare un controller Ingress in AKS ed è il percorso Ingress gestito da cui iniziare in AKS Automatic per la maggior parte dei carichi di lavoro. Il componente aggiuntivo per il routing applicativo è un controller Ingress completamente gestito per AKS che offre le funzionalità seguenti:

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

Per la maggior parte dei carichi di lavoro di produzione, si tratta dell'impostazione predefinita corretta per iniziare. Se è necessaria una topologia di ingress personalizzata, un ingress ospitato in Azure o il comportamento di una service mesh, è possibile passare a una delle altre opzioni di ingress.

Per altre informazioni sul componente aggiuntivo Routing delle applicazioni, vedere Ingresso NGINX gestito con il componente aggiuntivo Routing delle applicazioni.

Conservazione dell'IP di origine client

Configurare il controller in ingresso per conservare l'indirizzo IP di origine client nelle richieste ai contenitori nel cluster del servizio Azure Kubernetes. Quando il controller in ingresso instrada la richiesta di un client a un contenitore nel cluster del servizio Azure Kubernetes, l'IP di origine della richiesta non è disponibile per il contenitore di destinazione. Quando si abilita la conservazione dell'IP di origine client, l'IP di origine per il client è disponibile nell'intestazione della richiesta in X-Forwarded-For.

Se si usa la conservazione dell'IP di origine client nel controller in ingresso, non è possibile usare il pass-through TLS. La conservazione dell'IP di origine client e il pass-through TLS possono essere usati con altri servizi, ad esempio il tipo LoadBalancer.

Questa è una scelta di progettazione importante sia nel servizio Azure Kubernetes automatico che nello standard del servizio Azure Kubernetes, perché la gestione degli indirizzi IP di origine influisce sull'osservabilità, la controllabilità e il comportamento dell'applicazione indipendentemente dalla modalità cluster.

Per altre informazioni sulla conservazione dell'IP di origine client, vedere Conservazione dell'IP di origine client per i servizi LoadBalancer nel servizio Azure Kubernetes.