Criteri decisionali
La scelta del plug-in di rete migliore per il caso d'uso dipende dai criteri. Ogni opzione ha i propri vantaggi, svantaggi e compromessi da tenere in considerazione al momento della scelta.
Criteri decisionali di alto livello
Saturazione di IPv4
Kubenet è stato progettato tenendo conto della conservazione dello spazio indirizzi IP. Azure CNI offre pod con connettività di rete completa, ma richiede più spazio indirizzi IP e una maggiore pianificazione. L'esaurimento IPv4 è quando il numero di indirizzi raggiunge il limite e arresta i nodi da un'operazione di ridimensionamento o aggiornamento. Durante l'esaurimento, l'applicazione richiede troppi risorse e si sfalsa per mantenere il passo.
Kubenet consente ai nodi di ricevere indirizzi IP definiti, senza bisogno di riservare anticipatamente un numero elevato di indirizzi IP per tutti i potenziali pod che potrebbero essere eseguiti nel cluster. Con Kubenet non è necessario preoccuparsi dell'esaurimento degli indirizzi IPv4 e si gestisce un piccolo intervallo di indirizzi IP per il supporto dei cluster di grandi dimensioni e le esigenze dell'applicazione.
I calcoli di base seguenti confrontano lo spazio indirizzi nei modelli di rete:
- Kubenet: un semplice intervallo di indirizzi IP /24 può supportare fino a 251 nodi nel cluster (ogni subnet di rete virtuale di Azure riserva i primi tre indirizzi IP per le operazioni di gestione). Questo numero di nodi potrebbe supportare fino a 27.610 pod (con un valore massimo predefinito di 110 pod per nodo con kubenet).
- Azure CNI: lo stesso intervallo di indirizzi IP di base /24 della subnet potrebbe supportare solo 8 nodi al massimo nel cluster. Questo numero di nodi potrebbe supportare solo fino a 240 pod (con un valore massimo predefinito di 30 pod per nodo con Azure CNI).
Dimensioni del cluster
Kubenet ha un massimo di 400 nodi per ogni cluster, mentre Azure CNI dipende dalla configurazione del plug-in.
Connettività
In Kubenet è necessario gestire e mantenere manualmente le route definite dall'utente (UDR). Per raggiungere i pod dall'esterno del cluster, è necessario usare un bilanciamento del carico. Con Azure CNI, i pod ottengono una connettività di rete virtuale completa e possono essere raggiunti direttamente tramite l'indirizzo IP privato a partire dalle reti connesse.
Supporto di più cluster
In kubenet, la stessa subnet del nodo non può essere usata da più cluster. Questa configurazione è invece possibile con Azure CNI.
Latenza
Rispetto ad Azure CNI, Kubenet richiede un hop aggiuntivo, che può introdurre una latenza secondaria. I carichi di lavoro sensibili alla latenza devono essere distribuiti nei cluster usando Azure CNI.
Funzionalità aggiuntive
Azure CNI supporta topologie di rete complesse con la rete CNI di Azure, ad esempio nodi virtuali o criteri di rete di Azure.
Queste funzionalità aggiuntive sono:
- Subnet per pool di nodi
- Allocazione dinamica degli indirizzi IP
- Allocazioni di subnet dei nodi e dei pod
Differenze comportamentali tra Kubenet e Azure CNI
Oltre ai criteri di alto livello, esistono molte differenze comportamentali e discrepanze nel supporto delle funzioni:
| Funzionalità | Kubenet | Azure CNI | Sovrimpressione di Azure CNI | Azure CNI con tecnologia Cilium |
|---|---|---|---|---|
| Distribuzione del cluster in una rete virtuale esistente o nuova | Supportata; le route definite dall'utente sono applicate manualmente | Supportata | Supportato | Supportata |
| Connettività tra pod | Supportata | Supportato | Supportato | Supportata |
| Connettività tra pod e macchina virtuale, con la VM nella stessa rete virtuale | Funziona quando avviata dal pod | Si applica in entrambi i sensi | Funziona quando avviata dal pod | Funziona quando avviata dal pod |
| Connettività tra pod e macchina virtuale, con la VM in una rete virtuale con peering | Funziona quando avviata dal pod | Si applica in entrambi i sensi | Funziona quando avviata dal pod | Funziona quando avviata dal pod |
| Accesso locale tramite VPN o ExpressRoute | Funziona quando avviata dal pod | Si applica in entrambi i sensi | Funziona quando avviata dal pod | Funziona quando avviata dal pod |
| Accesso alle risorse protette mediante gli endpoint di servizio | Supportata | Supportato | Supportata | |
| Accesso alle risorse esposte mediante endpoint privati | Supportata | Supportata | ||
| Esposizione dei servizi Kubernetes tramite un servizio di bilanciamento del carico, un gateway applicazione o un controller in ingresso | Supportata | Supportato | Supportata | Stesse limitazioni quando si usa la modalità overlay |
| DNS di Azure e zone private predefinite | Supportata | Supportato | Supportata | |
| Supporto per i pool di nodi Windows | Non supportato | Supportata | Supportata | Disponibile solo per Linux |
| Nodi virtuali | Non supportato | Supportato | Non supportato | |
| Più cluster che condividono una subnet | Non supportato | Supportata | Supportata | |
| Criteri di rete supportati | Calico | Criteri di rete Calico e Azure | Calico, Criteri di rete di Azure, Cilium | Cilium |