Condividi tramite

Personalizzare l'uscita del cluster con i tipi in uscita in Servizio Azure Kubernetes (AKS)

Importante

A partire da March 31, 2026, Servizio Azure Kubernetes (AKS) non supporta più l'accesso in uscita predefinito per le macchine virtuali. I nuovi cluster AKS che usano l'opzione rete virtuale gestita da AKS inseriscono le subnet del cluster in subnet private per impostazione predefinita (defaultOutboundAccess = false). Questa impostazione non influisce sul traffico del cluster gestito dal servizio Azure Kubernetes, che usa percorsi in uscita configurati in modo esplicito. Potrebbe influire su scenari non supportati, ad esempio la distribuzione di altre risorse nella stessa subnet. I cluster che usano reti virtuali BYO non sono interessati da questa modifica. Nelle configurazioni supportate non è necessaria alcuna azione. Per ulteriori informazioni sulla disattivazione, vedere l'annuncio di disattivazione degli aggiornamenti di Azure. Per rimanere informati sugli annunci e sugli aggiornamenti, segui le note di rilascio di AKS.

Puoi personalizzare l'uscita per un cluster AKS in base a scenari specifici. Per impostazione predefinita, il servizio Azure Kubernetes crea un Load Balancer Standard da configurare e usare per l'uscita. La configurazione predefinita potrebbe, però, non soddisfare i requisiti di tutti gli scenari se gli indirizzi IP pubblici non sono consentiti o se per l'uscita sono necessari hop aggiuntivi.

Questo articolo mostra i vari tipi di connettività in uscita disponibili nei cluster AKS.

Note

Ora puoi aggiornare il outboundType dopo la creazione del cluster.

Importante

Nei cluster non privati, il traffico del cluster del server API viene instradato ed elaborato tramite il tipo in uscita del cluster. Per evitare che il traffico del server API venga elaborato come traffico pubblico, prendere in considerazione l'uso di un cluster privato o consultare la funzionalità Integrazione rete virtuale del server API .

Limitazioni

  • Per impostare outboundType, sono necessari cluster del servizio Azure Kubernetes con vm-set-type impostato su VirtualMachineScaleSets e load-balancer-sku impostato su Standard.

Tipi in uscita nel servizio Azure Kubernetes

È possibile configurare un cluster AKS utilizzando i seguenti tipi di uscita: bilanciamento del carico, gateway NAT o route definite dall'utente. Il tipo in uscita influisce solo sul traffico in uscita del cluster. Per altre informazioni, vedere Configurazione dei controller di ingresso.

Tipo in uscita: Bilanciamento del carico

Il bilanciamento del carico viene usato per l'uscita tramite un indirizzo IP pubblico assegnato dal servizio Azure Kubernetes. Il tipo in uscita loadBalancer supporta i servizi Kubernetes di tipo loadBalancer, che prevedono l'uscita dal bilanciamento del carico creato dal provider di risorse del servizio Azure Kubernetes.

Se loadBalancer è impostato, il servizio Azure Kubernetes completa automaticamente la configurazione seguente:

  • Viene creato un indirizzo IP pubblico per l'uscita del cluster.
  • L'indirizzo IP pubblico viene assegnato alla risorsa del bilanciamento del carico.
  • Per i nodi agente nel cluster vengono impostati pool back-end per il bilanciamento del carico.

Il diagramma mostra l'ingresso I P e l'uscita I P, dove l'I P in ingresso indirizza il traffico a un servizio di bilanciamento del carico, che indirizza il traffico da e verso un cluster interno e altro traffico verso l'I P in uscita, che indirizza il traffico a Internet, M C R, i servizi richiesti da Azure e il piano di controllo A K S.

Per ulteriori informazioni, vedi Usare un bilanciamento del carico standard nel servizio Azure Kubernetes.

Tipo di uscita: Gateway NAT

Se managedNATGatewayV2 (anteprima), managedNATGateway o userAssignedNATGateway sono selezionati per outboundType, AKS si basa su Azure Networking NAT gateway per l'uscita del cluster.

  • Selezionare managedNatGatewayV2 o managedNatGateway quando si usano reti virtuali gestite. AKS effettua il provisioning di un gateway NAT StandardV2 con managedNATGatewayV2 e un gateway NAT Standard con managedNATGateway e lo collega alla subnet del cluster. Il gateway NAT StandardV2 è consigliato perché è ridondante a livello di zona per impostazione predefinita e offre una maggiore larghezza di banda e throughput. Per informazioni, vedere Gateway NAT StandardV2.
  • Seleziona userAssignedNATGateway quando usi la rete virtuale bring-your-own. Questa opzione richiede la presenza di un gateway NAT creato prima della creazione del cluster. Sono supportati sia i gateway NAT Standard che StandardV2.

Importante

Il managedNATGatewayV2 tipo in uscita è attualmente in VERSIONE DI ANTEPRIMA. Vedi le Condizioni supplementari d'uso per le anteprime di Microsoft Azure per conoscere le condizioni legali applicabili alle funzionalità di Azure che sono in beta, in anteprima o non ancora rilasciate nella disponibilità generale.

Per altre informazioni, vedere Uso del gateway NAT con AKS.

Tipo in uscita: routes definite dall'utente

Note

Il tipo in uscita userDefinedRouting rappresenta uno scenario di rete avanzato e richiede una configurazione di rete appropriata.

Se userDefinedRouting è impostato, il servizio Azure Kubernetes non configura automaticamente i percorsi in uscita. La configurazione in uscita viene completata dall'utente.

È necessario distribuire il cluster del servizio Azure Kubernetes in una rete virtuale esistente con una subnet configurata in precedenza. Poiché non stai usando un'architettura Load Balancer standard, devi indicare l'uscita in modo esplicito. Questa architettura richiede l'invio esplicito del traffico in uscita a un'appliance, ad esempio un firewall, un gateway, un proxy, oppure la gestione di NAT da un indirizzo IP pubblico assegnato al servizio di bilanciamento del carico standard o all'appliance.

Per altre informazioni, vedere Configurazione dell'uscita del cluster tramite il routing definito dall'utente.

Tipo in uscita: nessuno

Importante

Il none tipo in uscita è disponibile solo con cluster isolato di rete e richiede un'attenta pianificazione per garantire che il cluster funzioni come previsto senza dipendenze impreviste da servizi esterni. Per i cluster completamente isolati, vedere Considerazioni sul cluster isolato.

Se none è impostato, il servizio Azure Kubernetes non configurerà automaticamente i percorsi in uscita. Questa opzione è simile a userDefinedRouting ma non richiede una route predefinita come parte della convalida.

Il tipo in uscita none è supportato in scenari di rete virtuale BYO (Bring Your Own) e in scenari di rete virtuale gestita. Tuttavia, è necessario assicurarsi che il cluster del servizio Azure Kubernetes venga distribuito in un ambiente di rete in cui vengono definiti percorsi in uscita espliciti, se necessario. Per gli scenari di rete virtuale BYO, il cluster deve essere distribuito in una rete virtuale esistente con una subnet già configurata. Poiché il servizio Azure Kubernetes non crea un Load Balancer Standard o un'infrastruttura in uscita, è necessario stabilire percorsi in uscita espliciti, se necessario. Le opzioni di uscita possono includere il routing del traffico verso un firewall, un proxy, un gateway o altre configurazioni di rete personalizzate.

Tipo in uscita: blocco (Anteprima)

Importante

Il block tipo in uscita è disponibile solo con cluster isolato di rete e richiede un'attenta pianificazione per garantire che non esistano dipendenze di rete indesiderate. Per i cluster completamente isolati, vedere Considerazioni sul cluster isolato.

Se block è impostato, AKS configura le regole di rete per bloccare attivamente tutto il traffico in uscita dal cluster. Questa opzione è utile per ambienti altamente sicuri in cui la connettività in uscita deve essere limitata.

Quando si usa block:

  • Il servizio Azure Kubernetes garantisce che nessun traffico Internet pubblico possa lasciare il cluster tramite regole del gruppo di sicurezza di rete. Il traffico della rete virtuale non è interessato.
  • È necessario consentire in modo esplicito qualsiasi traffico in uscita necessario tramite configurazioni di rete aggiuntive.

L'opzione block offre un altro livello di isolamento della rete, ma richiede un'attenta pianificazione per evitare l'interruzione di carichi di lavoro o dipendenze.

Aggiornare outboundType dopo la creazione del cluster

La modifica del tipo in uscita dopo la creazione del cluster distribuisce o rimuove le risorse come richiesto per inserire il cluster nella nuova configurazione in uscita.

Le tabelle seguenti mostrano i percorsi di migrazione supportati tra i tipi in uscita per le reti virtuali gestite e BYO.

Percorsi di migrazione supportati per la rete virtuale gestita

Ogni riga indica se è possibile eseguire la migrazione del tipo in uscita ai tipi elencati nella parte superiore. "Supportato" indica che la migrazione è possibile, mentre "Non supportato" o "N/A" significa che non lo è. Quando si utilizza una rete virtuale gestita, la migrazione è supportata solo tra i tipi di uscita gestiti, loadBalancer, managedNATGatewayV2 e managedNATGateway. Quando si usa una rete virtuale personalizzata/BYO, la migrazione è supportata solo tra i tipi in uscita definiti dall'utente - loadBalancere userAssignedNATGatewayuserDefinedRouting.

Da|A loadBalancer managedNATGatewayV2 managedNATGateway none block
loadBalancer N/D Supportato Supportato Supportato Supportato
managedNATGatewayV2 Non supportato N/D Non supportato Non supportato Non supportato
managedNATGateway Non supportato Supportato N/D Supportato Supportato
none Supportato Supportato Supportato N/D Supportato
block Supportato Supportato Supportato Supportato N/D

Percorsi di migrazione supportati per la rete virtuale BYO

Da|A loadBalancer userAssignedNATGateway userDefinedRouting none block
loadBalancer N/D Supportato Supportato Supportato Non supportato
userAssignedNATGateway Supportato N/D Supportato Supportato Non supportato
userDefinedRouting Supportato Supportato N/D Supportato Non supportato
none Supportato Supportato Supportato N/D Non supportato

Avviso

La migrazione del tipo in uscita a managedNATGatewayV2userAssignedNATGateway o userDefinedRouting modificherà gli indirizzi IP pubblici in uscita del cluster. Se gli intervalli IP autorizzati sono abilitati, assicurarsi che venga aggiunto un nuovo intervallo IP in uscita all'intervallo IP autorizzato.

Avviso

Modificare il tipo in uscita in un cluster causa un'interruzione della connettività di rete e comporta una modifica dell'indirizzo IP in uscita del cluster. Comporta tempi di inattività e impatto sulle connessioni esistenti. Se sono state configurate regole del firewall per limitare il traffico dal cluster, devi aggiornarle in modo che corrispondano al nuovo indirizzo IP in uscita.

Aggiorna il cluster per usare un nuovo tipo in uscita

Note

Per eseguire la migrazione del tipo in uscita, è necessario usare una versione >= 2.56 di interfaccia della riga di comando di Azure. Usare az upgrade per eseguire l'aggiornamento alla versione più recente di interfaccia della riga di comando di Azure.

  • Aggiorna la configurazione in uscita del tuo cluster usando il comando az aks update.

Aggiornare il cluster da loadbalancer a managedNATGatewayV2

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type managedNATGatewayV2 --nat-gateway-managed-outbound-ipv6-count <number of managed outbound ipv6>

Importante

Il managedNATGatewayV2 tipo in uscita è attualmente in VERSIONE DI ANTEPRIMA. Vedi le Condizioni supplementari d'uso per le anteprime di Microsoft Azure per conoscere le condizioni legali applicabili alle funzionalità di Azure che sono in beta, in anteprima o non ancora rilasciate nella disponibilità generale. Per altre informazioni sulla registrazione, vedere Uso del gateway NAT con il servizio Azure Kubernetes.

Aggiornare il cluster da managedNATGateway a loadbalancer

az aks update --resource-group <resourceGroup> --name <clusterName> \
--outbound-type loadBalancer \
<--load-balancer-managed-outbound-ip-count <number of managed outbound ip>| --load-balancer-outbound-ips <outbound ip ids> | --load-balancer-outbound-ip-prefixes <outbound ip prefix ids> >

Avviso

Non riutilizzare un indirizzo IP già in uso nelle configurazioni in uscita precedenti.

Aggiorna il cluster da managedNATGateway a userDefinedRouting

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userDefinedRouting

Aggiorna il cluster da loadbalancer a userAssignedNATGateway nello scenario di rete virtuale BYO

az aks update --resource-group <resourceGroup> --name <clusterName> --outbound-type userAssignedNATGateway

Passaggi successivi

  • Last updated on