Condividi tramite

Che cos'è il Controller in ingresso del gateway applicazione?

Il controller di ingresso del Gateway Applicazione (AGIC) è un'applicazione Kubernetes che consente ai cluster Azure Kubernetes Service (AKS) di usare il bilanciatore di carico L7 nativo di Application Gateway di Azure per esporre i carichi di lavoro al pubblico tramite Internet. AGIC monitora il cluster Kubernetes su cui è ospitato e aggiorna continuamente un'Application Gateway in modo che i servizi selezionati siano esposti su Internet.

Il controller in ingresso viene eseguito nel proprio pod nel cluster del servizio Azure Kubernetes. AGIC monitora un subset di risorse Kubernetes per individuare le modifiche. Lo stato del cluster di Azure Kubernetes Service (AKS) viene tradotto in una configurazione specifica per l'Application Gateway e applicata tramite Azure Resource Manager (ARM).

In questo articolo vengono illustrati i vantaggi di AGIC, opzioni di distribuzione (componente aggiuntivo Helm e servizio Azure Kubernetes) e configurazioni di rete dei contenitori supportate.

Suggerimento

Prendere in considerazione il Gateway applicativo per contenitori per la soluzione di ingresso Kubernetes. Per altre informazioni, vedere Avvio rapido: Distribuire il controller ALB del gateway applicativo per contenitori.

Vantaggi del controller in ingresso del gateway applicazione

AGIC aiuta a eliminare la necessità di un altro bilanciatore di carico o di un indirizzo IP pubblico davanti al cluster AKS. Evita più passaggi nel percorso dati prima che le richieste raggiungano il cluster AKS. Il gateway applicazione comunica direttamente con i pod tramite l'indirizzo IP privato e non richiede i servizi NodePort o KubeProxy. Questa funzionalità offre anche prestazioni migliori per le proprie distribuzioni.

Il controller Ingress è supportato esclusivamente dagli SKU Standard_v2 e WAF_v2, che abilitano anche i vantaggi del ridimensionamento automatico. Il gateway applicazione può reagire in risposta a un aumento o a una riduzione del carico del traffico e di conseguenza della scalabilità, senza usare risorse dal cluster del servizio Azure Kubernetes.

L'uso del gateway applicativo oltre ad AGIC aiuta anche a proteggere il cluster AKS fornendo criteri di TLS e funzionalità di Web Application Firewall (WAF).

Diagramma che mostra il flusso del traffico da Internet attraverso l'Application Gateway in un cluster AKS con AGIC.

AGIC viene configurato tramite la risorsa di ingresso Kubernetes, insieme a Service and Deployments/Pods.AGIC is configured through the Kubernetes Ingress resource, insieme a Service and Deployments/Pods. Usando il servizio di bilanciamento del carico nativo Azure Application Gateway L7, AGIC offre le funzionalità seguenti:

  • Routing basato su URL
  • Affinità basata sui cookie
  • Terminazione TLS
  • TLS end-to-end
  • Supporto per siti Web pubblici, privati e ibridi
  • Web application firewall integrato

Avvertimento

Per impostazione predefinita, AGIC presuppone la proprietà completa del gateway applicazione a cui è collegato. AGIC sovrascrive tutte le configurazioni esistenti del gateway dell'applicazione non definite nelle risorse Ingress di Kubernetes. Tutti i listener, i pool back-end, le regole o altre impostazioni configurate in precedenza nell'Application Gateway vengono rimosse o sostituite quando l'Application Gateway è abilitato. Prima di abilitare AGIC in un gateway applicazione esistente, eseguire il backup della configurazione del gateway applicazione esportando il modello dal portale di Azure. Per ulteriori informazioni, consultare Eseguire il backup della distribuzione del gateway applicativo.

Se è necessario che AGIC coesista con le configurazioni esistenti di Application Gateway, vedere Configurare una distribuzione condivisa di Application Gateway (solo Helm).

Differenza tra la distribuzione Helm e il componente aggiuntivo AKS di Azure Kubernetes Service.

Puoi distribuire AGIC per il cluster AKS utilizzando Helm o AKS come add-on. Il vantaggio principale della distribuzione dell'AGIC come componente aggiuntivo del servizio Azure Kubernetes è che è più semplice rispetto alla distribuzione tramite Helm. Per una nuova configurazione, è possibile distribuire un nuovo gateway dell'applicazione e un nuovo cluster di Azure Kubernetes Service con AGIC abilitato come componente aggiuntivo, con un solo comando nella CLI di Azure. Il componente aggiuntivo è anche un servizio completamente gestito, che offre vantaggi aggiuntivi, ad esempio aggiornamenti automatici e maggiore supporto. Entrambi i metodi di distribuzione dell'AGIC (Helm e il componente aggiuntivo per il servizio Azure Kubernetes) sono completamente supportati da Microsoft. Inoltre, il componente aggiuntivo consente una migliore integrazione con AKS in qualità di add-on di prima classe.

Sebbene si distribuisca il componente aggiuntivo AGIC come pod nel cluster del servizio Azure Kubernetes (AKS), esistono alcune differenze tra la versione distribuita con Helm e la versione del componente aggiuntivo di AGIC. L'elenco seguente evidenzia le differenze:

  • Non è possibile modificare i valori di distribuzione di Helm nell'add-on di Azure Kubernetes Service (AKS).
    • Per impostazione predefinita, verbosityLevel è impostato su 5
    • usePrivateIp è impostato su false per impostazione predefinita; sovrascrivi questa impostazione usando l'annotazione use-private-ip
    • shared non è supportato in nel componente aggiuntivo
    • reconcilePeriodSeconds non è supportato in nel componente aggiuntivo
    • armAuth.type non è supportato in nel componente aggiuntivo
  • Il controller AGIC distribuito tramite Helm supporta ProhibitedTargets, il che significa che tale controller può configurare il gateway applicazione in modo specifico per i cluster del servizio Azure Kubernetes, senza influire su altri back-end esistenti. Il componente aggiuntivo AGIC al momento non supporta questa funzionalità.
  • Poiché il componente aggiuntivo AGIC è un servizio gestito, si ricevono automaticamente gli aggiornamenti alla versione più recente del componente aggiuntivo AGIC. Al contrario, quando si distribuisce AGIC tramite Helm, è necessario aggiornare manualmente AGIC.

Note

È possibile distribuire un solo componente aggiuntivo AGIC per ogni cluster AKS e ogni componente aggiuntivo AGIC attualmente può avere come destinazione solo un Gateway Applicazione. Per le distribuzioni che richiedono più controller AGIC per cluster o più controller AGIC per uno stesso gateway applicazione, usare la distribuzione tramite Helm.

Sia il componente aggiuntivo Helm che il componente aggiuntivo AGIC non supportano il servizio ExternalName.

Container networking e AGIC

Il controller Ingress di Application Gateway supporta le seguenti offerte di rete di AKS:

  • Kubenet
  • CNI
  • Sovrimpressione di CNI

Azure CNI e Azure CNI Overlay sono le due opzioni consigliate per l'Ingress Controller di Application Gateway. Quando si sceglie un modello di rete, considerare i casi d'uso per ogni plug-in CNI e il tipo di modello di rete usato:

Plug-in CNI Modello di rete Evidenziazioni dei casi d'uso
Azure CNI Overlay Sovrapposizione - Ideale per la conservazione ip della rete virtuale
- Numero massimo di nodi supportato dal server API + 250 pod per nodo
- Configurazione più semplice
-Nessun accesso IP diretto al pod esterno
Subnet Pod di Azure CNI Appartamento - Accesso diretto al pod esterno
- Modalità per un utilizzo efficiente degli indirizzi IP della rete virtuale o supporto su larga scala del cluster
Azure subnet del nodo CNI Appartamento - Accesso diretto al pod esterno
- Configurazione più semplice
- Scalabilità limitata
- Uso inefficiente degli indirizzi IP di rete virtuale

Quando si effettua il provisioning dell'Application Gateway per i Contenitori in un cluster con CNI Overlay o CNI abilitato, l'Application Gateway per i Contenitori rileva automaticamente la configurazione di rete desiderata. Non è necessario modificare la configurazione dell'API Gateway o Ingress per specificare CNI Overlay o CNI.

Quando si usa Azure overlay CNI, considerare le limitazioni seguenti:

  • Controller AGIC: è necessario eseguire la versione 1.9.1 o successiva per sfruttare l'overlay CNI.
  • Dimensioni subnet: la subnet del gateway applicazione deve essere un prefisso massimo di /24; è supportata una sola distribuzione per subnet.
  • Delega subnet: la subnet del Gateway di applicazione deve avere la delega della subnet per Microsoft.Network/applicationGateways.
  • Peering della rete virtuale regionale: non è possibile distribuire Application Gateway in una rete virtuale in una regione e i nodi del cluster AKS in una rete virtuale nella stessa regione.
  • Peering di rete virtuale globale: non è possibile distribuire l'Application Gateway in una rete virtuale in una regione e i nodi del cluster dell'Azure Kubernetes Service (AKS) in una rete virtuale in una regione diversa.
  • Azure CNI Overlay con Application Gateway Ingress Controller non è supportato nella cloud Azure Government o in Microsoft Azure, gestita da 21Vianet (Azure in Cina).

Note

Il controller in ingresso del gateway applicazione rileva automaticamente l'aggiornamento del cluster del servizio Azure Kubernetes da Kubenet o CNI a Sovrimpressione CNI. Pianificare l'aggiornamento durante una finestra di manutenzione perché può verificarsi un'interruzione del traffico. Il controller potrebbe richiedere alcuni minuti a seguito dell'aggiornamento del cluster per rilevare e configurare il supporto CNI Overlay.

Avvertimento

Assicurarsi che la sottorete del gateway applicativo sia una sottorete /24 o più piccola prima dell'aggiornamento. L'aggiornamento da CNI a CNI Overlay con una subnet più grande ,ad esempio /23, comporta un'interruzione e richiede di ricreare la subnet del gateway applicazione con una dimensione di subnet supportata.

Passaggi successivi

  • Last updated on