Panoramica della rete CNI del servizio Azure Kubernetes

Kubernetes usa plug-in CNI (Container Networking Interface) per gestire la rete nei cluster Kubernetes. I plug-in CNI gestiscono l'assegnazione di indirizzi IP ai pod, il routing del traffico di rete tra pod, il routing del traffico del servizio Kubernetes e altro ancora.

Servizio Azure Kubernetes (AKS) offre più configurazioni di rete CNI che è possibile usare nei cluster, a seconda dei requisiti di rete. Quando si pianifica la rete dei pod, si sceglie un'opzione di gestione degli indirizzi IP e una tecnologia di routing e trasporto per il piano dati di rete.

Modelli di rete nel servizio Azure Kubernetes

La scelta di un'opzione di Gestione indirizzi IP per il cluster del servizio Azure Kubernetes dipende in gran parte dal modello di rete più adatto alle proprie esigenze. Ogni modello presenta vantaggi e svantaggi specifici da considerare quando si pianifica un cluster AKS.

"AKS (Azure Kubernetes Service) utilizza due modelli di rete principali:"

• Rete sovrapposta:

  • Consente di risparmiare spazio degli indirizzi IP per le reti virtuali (VNet) utilizzando intervalli CIDR (Classless Inter-Domain Routing) logicamente separati per i pod.
  • Fornisce il supporto massimo per la scalabilità dei cluster.
  • Fornisce una gestione semplice degli indirizzi IP.

• Rete piatta:

  • Fornisce la connettività completa della rete virtuale per i pod. I pod possono essere raggiunti direttamente tramite l'indirizzo IP privato dalle reti connesse.
  • Richiede uno spazio indirizzi IP di grandi dimensioni e non frammentato per le reti virtuali.

Entrambi i modelli di rete supportano più opzioni di Gestione indirizzi IP. Le differenze principali tra i modelli sono il modo in cui si assegnano gli indirizzi IP del pod e il modo in cui il traffico esce dal cluster.

Per Azure CNI, l'opzione Gestione indirizzi IP è separata dal piano dati di rete. È possibile usare il piano dati CNI Azure basato su Cilium con Azure overlay CNI, Azure subnet pod CNI o Azure subnet del nodo CNI. Per altre informazioni sulle opzioni di Gestione indirizzi IP e piano dati, vedere Pianificare la rete dei pod per il servizio Azure Kubernetes.

Reti overlay

La rete di sovrapposizione nel servizio Azure Kubernetes assegna gli indirizzi IP dei pod da un CIDR di pod distinto dalla subnet del nodo nella rete virtuale. Questa configurazione consente una scalabilità più semplice e spesso migliore rispetto al modello di rete flat.

Nelle reti di sovrimpressione, i pod possono comunicare tra loro direttamente. Il traffico che lascia il cluster viene tradotto in indirizzi di rete di origine traslati (SNAT) all'indirizzo IP del nodo. Il traffico IP del pod in ingresso viene instradato attraverso un servizio, ad esempio un servizio di bilanciamento del carico. L'indirizzo IP del pod viene quindi "nascosto" dietro l'indirizzo IP del nodo. Questo approccio riduce il numero di indirizzi IP necessari per le reti virtuali nei cluster.

Per la rete di sovrapposizione, il servizio Azure Kubernetes fornisce Azure overlay CNI. Usare questa opzione di Gestione indirizzi IP per la maggior parte degli scenari.

Reti flat

A differenza di una rete sovrapposta, un modello di rete flat nel servizio Azure Kubernetes assegna indirizzi IP ai pod da una subnet nella stessa rete virtuale Azure dei nodi del servizio Azure Kubernetes. Per il traffico di rete privato, l'indirizzo IP di origine visualizzato da una destinazione dipende dall'opzione Gestione indirizzi IP. Azure subnet pod CNI mantiene l'indirizzo IP del pod tra reti virtuali connesse. Con Azure subnet del nodo CNI, le destinazioni nella rete virtuale del cluster vedono l'indirizzo IP del pod, ma le destinazioni esterne alla rete virtuale del cluster vedono l'indirizzo IP del nodo. Quando internet in uscita è abilitato, il metodo in uscita configurato del cluster determina l'indirizzo IP di origine pubblica visualizzato dalle destinazioni Internet.

Il servizio Azure Kubernetes offre due opzioni di Gestione indirizzi IP CNI Azure per la rete flat:

• Azure subnet pod CNI, opzione di Gestione indirizzi IP consigliata per scenari di rete flat.
• Subnet del nodo CNI di Azure, un modello legacy CNI per reti piatte. In generale, è consigliabile usarlo solo se è necessaria una rete virtuale gestita per il cluster.

Scegliere un'opzione di Gestione indirizzi IP per il servizio Azure Kubernetes

Quando si sceglie un'opzione di Gestione indirizzi IP, prendere in considerazione diversi fattori. Ogni modello di rete presenta vantaggi e svantaggi specifici. La scelta migliore per il cluster dipende dai requisiti specifici.

Confronto tra casi d'uso

Confronto delle funzionalità

Supporto dell'ambito tra i modelli di rete

A seconda dell'opzione di Gestione indirizzi IP usata, è possibile distribuire le risorse di rete virtuale per il cluster in uno dei modi seguenti:

• La piattaforma Azure può creare e configurare automaticamente le risorse della rete virtuale al momento della creazione di un cluster AKS.
• È possibile creare e configurare manualmente le risorse della rete virtuale e collegarsi a tali risorse quando si crea il cluster del servizio Azure Kubernetes.

Sebbene funzionalità come gli endpoint di servizio o le route definite dall'utente siano supportate, i criteri di supporto per il servizio Azure Kubernetes definiscono le modifiche che è possibile apportare. Per esempio:

• Se si creano manualmente le risorse di rete virtuale per un cluster del servizio Azure Kubernetes, è possibile configurare le route definite dall'utente o gli endpoint di servizio personalizzati.
• Se la piattaforma Azure crea automaticamente le risorse di rete virtuale per il cluster del servizio Azure Kubernetes, non è possibile modificare manualmente tali risorse gestite dal servizio Azure Kubernetes per configurare le route definite dall'utente o gli endpoint di servizio.

Prerequisiti di rete CNI del servizio Azure Kubernetes

Quando si pianifica la configurazione di rete per AKS, tenere a mente questi requisiti e considerazioni:

• A meno che non si usi un cluster isolato di rete, la rete virtuale per il cluster del servizio Azure Kubernetes deve consentire la connettività Internet in uscita agli endpoint necessari. I cluster isolati di rete possono eseguire il bootstrap senza connettività Internet in uscita.

• Gli intervalli di indirizzi del servizio Azure Kubernetes hanno le restrizioni seguenti:

  Intervallo CIDR riservato	Si applica a:	Condition
  169.254.0.0/16	Intervalli di indirizzi di rete virtuale del cluster, del servizio Kubernetes, del pod e del cluster	Tutti i cluster del servizio Azure Kubernetes
  192.0.2.0/24	Intervalli di indirizzi di rete virtuale del cluster, del servizio Kubernetes, del pod e del cluster	Tutti i cluster del servizio Azure Kubernetes
  172.30.0.0/16	Intervalli di indirizzi di rete virtuale del cluster, del servizio Kubernetes, del pod e del cluster	Tutti i cluster del servizio Azure Kubernetes
  172.31.0.0/16	Intervalli di indirizzi di rete virtuale del cluster, del servizio Kubernetes, del pod e del cluster	Tutti i cluster del servizio Azure Kubernetes

  Il servizio Azure Kubernetes rifiuta i CIDR dei pod che si sovrappongono a un intervallo riservato durante la creazione o l'aggiornamento del cluster. Ad esempio, 172.16.0.0/12 non è valido perché l'intervallo include 172.30.0.0/16 e 172.31.0.0/16.

• Negli scenari in cui viene usata la propria rete virtuale, l'identità del cluster usata del servizio Azure Kubernetes deve disporre almeno delle autorizzazioni di Collaboratore Rete sulla subnet all'interno della rete virtuale.

• Se si definisce un ruolo personalizzato anziché usare il ruolo Collaboratore rete predefinito, includere le autorizzazioni seguenti:

  Autorizzazione	Se necessario
  Microsoft.Network/virtualNetworks/subnets/join/action	Sempre quando si usa un ruolo personalizzato
  Microsoft.Authorization/roleAssignments/write	Sempre quando si usa un ruolo personalizzato
  Microsoft.Network/virtualNetworks/subnets/read	Solo quando si definiscono subnet e CIDR personalizzati

• La subnet assegnata al pool di nodi del servizio Azure Kubernetes non può essere una subnet delegata.

• Il servizio Azure Kubernetes non applica i gruppi di sicurezza di rete (NSG) alla subnet e non modifica alcun gruppo di sicurezza di rete associato a tale subnet. Se si specifica la propria subnet e si aggiungono gruppi di sicurezza di rete associati a tale subnet, è necessario assicurarsi che le regole di sicurezza nei gruppi di sicurezza di rete consentano il traffico all'interno dell'intervallo CIDR del nodo. Con Azure CNI Overlay, se una regola di negazione del gruppo di sicurezza di rete influisce sul traffico CIDR dei pod, è necessario consentire anche il traffico dal CIDR del nodo al CIDR del pod e dal CIDR del pod al CIDR del pod su tutte le porte e protocolli. Per altre informazioni, vedere Gruppi di sicurezza di rete con Azure overlay CNI.

• Il Container Network Service (CNS) è un servizio locale del nodo all'interno della rete CNI di servizio Azure Kubernetes che alloca, tiene traccia e programma la rete per i pod. Questo componente invia i dati di telemetria (metriche e log) per impostazione predefinita all'esterno del cluster a un endpoint di Application Insights gestito Microsoft per consentire una risoluzione più rapida dei problemi di assegnazione degli indirizzi IP di rete dei pod.

Contenuti correlati

• Sovrimpressione di Azure CNI
• Subnet del pod di Azure CNI
• Opzioni CNI legacy
• Pianificazione degli indirizzi IP per i cluster