Condividi tramite


Rete di Azure Container Networking Interface (CNI) Overlay

Con la sovrimpressione di Azure CNI, i nodi del cluster vengono distribuiti in una subnet di rete virtuale di Azure. Ai pod vengono assegnati indirizzi IP da un CIDR privato in un modo logico diverso dalla rete virtuale che ospita i nodi. Il traffico di pod e nodi all'interno del cluster usa una rete Overlay. Network Address Translation (NAT) usa l'indirizzo IP del nodo per raggiungere le risorse all'esterno del cluster. Questa soluzione consente di risparmiare una quantità significativa di indirizzi IP della rete virtuale e di ridimensionare il cluster in dimensioni elevate. Un vantaggio aggiuntivo è che è possibile riutilizzare il CIDR privato in diversi cluster del servizio Azure Kubernetes, che estende lo spazio IP disponibile per le applicazioni in contenitori nel servizio Azure Kubernetes.

Panoramica della rete di Overlay

In Rete di overlay, solo ai nodi del cluster Kubernetes vengono assegnati indirizzi IP dalle subnet. I pod ricevono indirizzi IP da un CIDR privato fornito al momento della creazione del cluster. A ogni nodo viene assegnato uno spazio indirizzi /24 ritagliato dallo stesso CIDR. Nodi aggiuntivi creati quando si aumenta il numero di istanze di un cluster ricevono automaticamente gli spazi indirizzi /24 dallo stesso CIDR. Azure CNI assegna indirizzi IP ai pod da questo spazio /24.

Nello stack di rete di Azure viene creato un dominio di routing separato per lo spazio CIDR privato del pod, che crea una rete Overlay per la comunicazione diretta tra i pod. Non è necessario effettuare il provisioning di route personalizzate nella subnet del cluster o usare un metodo di incapsulamento per eseguire il tunneling del traffico tra i pod, che offre prestazioni di connettività tra i pod alla pari con le macchine virtuali in una rete virtuale. I carichi di lavoro in esecuzione all'interno dei pod non sono nemmeno consapevoli che la manipolazione degli indirizzi di rete stia accadendo.

Un diagramma che mostra due nodi con tre pod in esecuzione in una rete Overlay. Il traffico dei pod verso endpoint esterni al cluster viene instradato tramite NAT.

La comunicazione con endpoint esterni al cluster, ad esempio reti virtuali locali e con peering, avviene usando l'IP del nodo tramite NAT. Azure CNI converte l'indirizzo IP di origine (IP Overlay del pod) del traffico all'indirizzo IP primario della macchina virtuale, che consente allo stack di rete di Azure di instradare il traffico alla destinazione. Gli endpoint esterni al cluster non possono connettersi direttamente a un pod. È necessario pubblicare l'applicazione del pod come servizio di bilanciamento del carico Kubernetes per renderla raggiungibile nella rete virtuale.

È possibile fornire connettività in uscita (egress) a Internet per i pod Overlay usando un servizio load balancer SKU Standard o un gateway NAT gestito. È anche possibile controllare il traffico in uscita indirizzandolo a un firewall usando route definite dall'utente nella subnet del cluster.

È possibile configurare la connettività in ingresso al cluster usando un controller di ingresso, ad esempio Nginx o il routing dell'applicazione HTTP. Non è possibile configurare la connettività in ingresso usando il gateway applicazione di Azure. Per informazioni dettagliate, vedere Limitazioni con Azure CNI Overlay.

Differenze tra kubenet e Azure CNI Overlay

La tabella seguente fornisce un confronto dettagliato tra kubenet e Azure CNI Overlay:

Area Sovrimpressione di Azure CNI kubenet
Scalabilità del cluster 5.000 nodi e 250 pod/nodo 400 nodi e 250 pod/nodo
Configurazione di rete Semplice: non sono necessarie configurazioni aggiuntive per la rete dei pod Complesso: richiede tabelle di route e route definite dall'utente nella subnet del cluster per la rete dei pod
Prestazioni della connettività dei pod Prestazioni in parità con le macchine virtuali in una rete virtuale L'hop aggiuntivo aggiunge una latenza secondaria
Criteri di rete di Kubernetes Criteri di rete di Azure, Calico, Cilium Calico
Piattaforme del sistema operativo supportate Linux e Windows Server 2022, 2019 Solo Linux

Pianificazione degli indirizzi IP

Nodi del cluster

Quando si configura il cluster del servizio Azure Kubernetes, assicurarsi che le subnet della rete virtuale abbiano spazio sufficiente per aumentare per il ridimensionamento futuro. È possibile assegnare ogni pool di nodi a una subnet dedicata.

Una /24subnet può contenere fino a 251 nodi poiché i primi tre indirizzi IP sono riservati per le attività di gestione.

Pod

La soluzione Overlay assegna uno spazio indirizzi /24 per i pod in ogni nodo dal CIDR privato specificato durante la creazione del cluster. La dimensione /24 è fissa e non può essere aumentata o ridotta. È possibile eseguire fino a 250 pod in un nodo.

Quando si pianifica lo spazio degli indirizzi IP per i pod, considerare i fattori seguenti:

  • Assicurarsi che il CIDR privato sia sufficientemente grande da fornire spazi di indirizzi /24 per i nuovi nodi per supportare l'espansione futura del cluster.
  • Lo stesso spazio CIDR dei pod può essere usato in più cluster del servizio Azure Kubernetes indipendenti nella stessa rete virtuale.
  • Lo spazio CIDR dei pod non deve sovrapporsi all'intervallo di subnet del cluster.
  • Lo spazio CIDR dei pod non deve sovrapporsi alle reti connesse direttamente (ad esempio peering reti virtuali, ExpressRoute o VPN). Se il traffico esterno ha indirizzi IP di origine nell'intervallo podCIDR, deve eseguire la conversione in un indirizzo IP non sovrapposto tramite SNAT per comunicare con il cluster.

Intervallo di indirizzi del servizio Kubernetes

Le dimensioni del CIDR dell'indirizzo del servizio dipendono dal numero di servizi cluster che si intende creare. Deve essere minore di /12. Questo intervallo non deve sovrapporsi all'intervallo CIDR del pod, all'intervallo di subnet del cluster e all'intervallo IP usato nelle reti virtuali con peering e nelle reti locali.

Indirizzo IP del servizio DNS di Kubernetes

Questo indirizzo IP è all'interno dell'intervallo di indirizzi del servizio Kubernetes usato dall'individuazione del servizio cluster. Non usare il primo indirizzo IP nell'intervallo di indirizzi, perché questo viene usato per l'indirizzo kubernetes.default.svc.cluster.local.

Gruppi di sicurezza di rete

Il traffico da pod a pod con Azure CNI Overlay non è incapsulato e vengono applicate le regole del gruppo di sicurezza di rete della subnet. Se il gruppo di sicurezza di rete della subnet contiene regole di negazione che influiscono sul traffico CIDR del pod, assicurarsi che siano presenti le regole seguenti per garantire la funzionalità del cluster appropriata (oltre a tutti i requisiti in uscita del servizio Azure Kubernetes):

  • Traffico dal CIDR del nodo al CIDR del nodo su tutte le porte e protocolli
  • Traffico dal CIDR del nodo al CIDR del pod su tutte le porte e i protocolli (necessario per il routing del traffico del servizio)
  • Traffico dal CIDR del pod al CIDR del pod su tutte le porte e i protocolli (necessario per il traffico da pod a pod e da pod a server, tra cui DNS)

Il traffico da un pod a qualsiasi destinazione all'esterno del blocco CIDR del pod usa SNAT per impostare l'IP di origine sull'IP del nodo in cui viene eseguito il pod.

Se si vuole limitare il traffico tra carichi di lavoro nel cluster, è consigliabile usare i criteri di rete.

Numero massimo di pod per nodo

È possibile configurare il numero massimo di pod per nodo al momento della creazione del cluster o quando si aggiunge un nuovo pool di nodi. Il valore predefinito e massimo per Azure CNI Overlay è 250 e il valore minimo è 10. Il valore massimo di pod per nodo configurati durante la creazione di un pool di nodi si applica solo ai nodi nel pool di nodi.

Scelta di un modello di rete da usare

Azure CNI offre due opzioni di indirizzi IP per i pod: la configurazione tradizionale che assegna IP di rete virtuale ai pod e alla rete Overlay. La scelta dell’opzione da usare per il cluster del servizio Azure Kubernetes è un compromesso tra le esigenze di flessibilità e di configurazione avanzata. Le considerazioni seguenti sono utili per stabilire quando ogni modello di rete può essere il più appropriato.

Usare la rete Overlay quando:

  • Si vuole ridimensionare fino a un numero elevato di pod, ma è disponibile uno spazio di indirizzi IP limitato nella rete virtuale.
  • La maggior parte delle comunicazioni dei pod avviene all'interno del cluster.
  • Non sono necessarie funzionalità avanzate del servizio Azure Kubernetes, ad esempio nodi virtuali.

Usare l'opzione di rete virtuale tradizionale quando:

  • È disponibile uno spazio indirizzi IP adeguato.
  • La maggior parte delle comunicazioni dei pod avviene con risorse esterne al cluster.
  • Le risorse esterne al cluster devono raggiungere direttamente i pod.
  • Sono necessarie funzionalità avanzate del servizio Azure Kubernetes, come i nodi virtuali.

Limitazioni con Azure CNI Overlay

Azure CNI Overlay presenta le limitazioni seguenti:

  • Non è possibile usare il gateway applicazione come controller in ingresso (AGIC).
  • I set di disponibilità delle macchine virtuali (VMAS) non sono supportati.
  • Non è possibile usare macchine virtuali serie DCsv2 nei pool di nodi. Per soddisfare i requisiti di Confidential Computing, prendere in considerazione l'uso di macchine virtuali riservate serie DCasv5 o DCadsv5.
  • Se si usa una subnet personale per distribuire il cluster, i nomi della subnet, della rete virtuale e del gruppo di risorse che contengono la rete virtuale devono contenere al massimo 63 caratteri. Questi nomi verranno usati come etichette nei nodi di lavoro del servizio Azure Kubernetes e sono soggetti alle regole di sintassi delle etichette Kubernetes.