Panoramica della rete CNI del servizio Azure Kubernetes
Kubernetes usa plug-in CNI (Container Networking Interface) per gestire la rete nei cluster Kubernetes. Le CNI sono responsabili dell'assegnazione di indirizzi IP ai pod, del routing di rete tra i pod, del routing del servizio Kubernetes e altro ancora.
AKS fornisce numerosi plug-in CNI che è possibile usare nei cluster a seconda dei requisiti di rete.
Modelli di rete nel servizio Azure Kubernetes
La scelta di un plug-in CNI 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 per la pianificazione del cluster del servizio Azure Kubernetes.
Il servizio Azure Kubernetes usa due modelli di rete principali: rete di sovrimpressione e rete flat.
Entrambi i modelli di rete dispongono di più opzioni di plug-in CNI supportate. Le differenze principali tra i modelli riguardano le modalità di assegnazione degli indirizzi IP dei pod e il modo in cui il traffico esce dal cluster.
Reti di sovrimpressione
La rete di sovrimpressione è il modello di rete più comune usato in Kubernetes. Nelle reti di sovrimpressione viene assegnato ai pod un indirizzo IP da un CIDR privato, logicamente separato dalla subnet della rete virtuale di Azure in cui vengono distribuiti i nodi del servizio Azure Kubernetes. Ciò 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 in uscita dal cluster viene convertito dall'indirizzo di rete di origine (SNAT) nell'indirizzo IP del nodo, mentre e traffico IP del pod in ingresso viene instradato tramite un servizio, ad esempio un servizio di bilanciamento del carico. Ciò significa che l'indirizzo IP del pod è "nascosto" dietro l'indirizzo IP del nodo. Questo approccio riduce il numero di indirizzi IP della rete virtuale necessari per i cluster.
Il servizio Azure Kubernetes fornisce i plug-in CNI seguenti per la rete di sovrimpressione:
- Sovrimpressione di Azure CNI, il plug-in CNI consigliato per la maggior parte degli scenari.
- kubenet, il modello di sovrimpressione CNI legacy.
Reti flat
A differenza di una rete di sovrimpressione, un modello di rete flat nel servizio Azure Kubernetes assegna gli indirizzi IP ai pod da una subnet della stessa rete virtuale di Azure dei nodi del servizio Azure Kubernetes. Ciò significa che il traffico in uscita dai cluster non viene sottoposto a SNAT e l'indirizzo IP del pod è direttamente esposto alla destinazione. Questo può essere utile per alcuni scenari, ad esempio quando è necessario esporre gli indirizzi IP del pod a servizi esterni.
Il servizio Azure Kubernetes offre due plug-in CNI per la rete flat. Questo articolo non illustra in dettaglio ogni opzione di plug-in. Per altre informazioni, vedere la documentazione collegata:
- Subnet del pod di Azure CNI, il plug-in CNI consigliato per scenari di rete flat.
- Subnet del nodo di Azure CNI, un modello di rete flat legacy che la CNI consiglia di usare solo se è necessaria una rete virtuale gestita per il cluster.
Scelta di una CNI
Quando si sceglie una CNI, è necessario prendere in considerazione diversi fattori. Ogni modello di rete presenta vantaggi e svantaggi specifici e la scelta migliore per il cluster dipenderà dai requisiti specifici.
Scelta di un modello di rete
I due modelli di rete principali nel servizio Azure Kubernetes sono le reti di sovrimpressione e flat.
Reti di sovrimpressione:
- Preservare lo spazio indirizzi IP della rete virtuale usando intervalli CIDR logicamente separati per i pod.
- Supporto massimo per la scalabilità dei cluster.
- Gestione indirizzi IP semplice.
Reti flat:
- I pod ottengono la connettività di rete virtuale completa e possono essere raggiunti direttamente tramite l'indirizzo IP privato dalle reti connesse.
- Richiedere uno spazio indirizzi IP della rete virtuale di grandi dimensioni e non frammentato.
Confronto tra casi d'uso
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 | Caso d'uso in evidenza |
|---|---|---|
| Sovrimpressione di Azure CNI | Overlay | - Ideale per la conservazione del protocollo IP della rete virtuale - Numero massimo di nodi supportato dal server API + 250 pod per nodo - Configurazione più semplice - Nessun accesso diretto al protocollo IP del pod esterno |
| Subnet del pod di Azure CNI | Flat | - Accesso diretto al pod esterno - Modalità per un utilizzo efficiente degli indirizzi IP della rete virtuale o per il supporto su larga scala del cluster (anteprima) |
| Kubenet (legacy) | Overlay | - Assegna priorità alla conservazione del protocollo IP - Scalabilità limitata - Gestione manuale della route |
| Subnet del nodo di Azure CNI (legacy) | Flat | - Accesso diretto al pod esterno - Configurazione più semplice - Scalabilità limitata - Uso inefficiente dei protocolli P della rete virtuale |
Confronto delle funzionalità
È inoltre possibile confrontare le funzionalità di ogni plug-in CNI. La tabella seguente fornisce un confronto delle funzionalità supportate da ogni plug-in CNI di alto livello:
| Funzionalità | Sovrimpressione di Azure CNI | Subnet del pod di Azure CNI | Subnet del nodo di Azure CNI (legacy) | Kubenet |
|---|---|---|---|---|
| Distribuire un cluster in una rete virtuale esistente o nuova | Supportata | Supportato | Supportata | Supportato: route definite dall'utente manuali |
| Connettività pod-macchina virtuale con macchina virtuale nella stessa rete virtuale o in una rete con peering | Pod avviato | Entrambe le modalità | Entrambe le modalità | Pod avviato |
| Accesso locale tramite rete privata virtuale/ExpressRoute | Pod avviato | Entrambe le modalità | Entrambe le modalità | Pod avviato |
| Accesso agli endpoint del servizio | Supportata | Supportato | Supportato | Supportata |
| Esporre i servizi tramite il bilanciamento del carico | Supportata | Supportato | Supportato | Supportata |
| Esporre i servizi tramite il gateway applicazione | Attualmente non supportati | Supportata | Supportato | Supportata |
| Esporre i servizi tramite il controller in ingresso | Supportata | Supportato | Supportato | Supportata |
| Pool di nodi Windows | Supportata | Supportato | Supportato | Non supportato |
| DNS di Azure e zone private predefinite | Supportata | Supportato | Supportato | Supportata |
| Condivisione di subnet della rete virtuale tra più cluster | Supportata | Supportato | Supportato | Non supportato |
Supporto dell'ambito tra i modelli di rete
A seconda della CNI usata, le risorse della rete virtuale del cluster possono essere distribuite secondo una delle modalità seguenti:
- La piattaforma Azure può creare e configurare automaticamente le risorse di rete virtuale quando si crea un cluster del servizio Azure Kubernetes. ad esempio nella sovrimpressione di Azure CNI, nella subnet del nodo di Azure CNI e in Kubenet.
- È 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. Ad 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
Durante la pianificazione della configurazione di rete per il servizio Azure Kubernetes, è consigliabile prendere in considerazione diversi requisiti e considerazioni:
- La rete virtuale per il cluster servizio Azure Kubernetes deve consentire la connettività Internet in uscita.
- I cluster del servizio Azure Kubernetes non possono usare
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16o192.0.2.0/24per l'intervallo di indirizzi del servizio Kubernetes, per l'intervallo di indirizzi del pod o per l'intervallo di indirizzi della rete virtuale del cluster. - Negli scenari di rete virtuale BYO, l'identità del cluster usata dal cluster del servizio Azure Kubernetes deve avere almeno le autorizzazioni Collaboratore rete nella subnet all'interno della rete virtuale. Se si vuole definire un ruolo personalizzato invece di usare il ruolo predefinito Collaboratore di rete, sono necessarie le autorizzazioni seguenti:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(necessario solo se si definiscono subnet e CIDR)
- 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 relativa subnet e non modifica alcun gruppo di sicurezza di rete associato a tale subnet. Se si specifica la propria subnet e si aggiungono i 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. Per altre informazioni, vedere Gruppi di sicurezza di rete.
Passaggi successivi
Azure Kubernetes Service