Valutazione delle prestazioni CNI per Kubernetes su rete 10G (agosto 2020)
TL; DR: Tutti i CNI funzionano come dovrebbero, ad eccezione di Kube-Router e Kube-OVN, Calico, ad eccezione del rilevamento automatico MTU, è il migliore.
Articolo di aggiornamento dei miei assegni passati (2018 и 2019), al momento del test sto utilizzando Kubernetes 1.19 su Ubuntu 18.04 con CNI aggiornati ad agosto 2020.
Prima di immergerci nei parametri...
Cosa c'è di nuovo da aprile 2019?
Puoi eseguire test sul tuo cluster: puoi eseguire test sul tuo cluster utilizzando il nostro strumento Benchmark della rete Kubernetes: knb
Nuovi scenari: i controlli attuali eseguono test delle prestazioni di rete "Pod-to-Pod" ed è stato aggiunto un nuovo script "Pod-to-Service" che esegue test più vicini alle condizioni del mondo reale. In pratica, il tuo Pod con API funziona con Base as a Service e non tramite l'indirizzo IP del Pod (ovviamente controlliamo sia TCP che UDP per entrambi gli scenari).
Consumo di risorse: ogni test ora ha il proprio confronto di risorse
Rimozione dei test delle applicazioni: non eseguiamo più test HTTP, FTP e SCP poiché la nostra fruttuosa collaborazione con la comunità e i manutentori di CNI ha scoperto un divario tra i risultati di iperf su TCP e i risultati di curl a causa di un ritardo nell'avvio di CNI (i primi secondi di Pod avvio, cosa non tipica nelle condizioni reali).
Open source: tutte le fonti di test (script, impostazioni yml e dati "grezzi") originali sono disponibili qui
Protocollo di test di riferimento
Il protocollo è descritto in dettaglio quiTieni presente che questo articolo riguarda Ubuntu 18.04 con il kernel predefinito.
Selezione di un CNI per la valutazione
Questo test ha lo scopo di confrontare i CNI configurati con un file yaml (sono quindi esclusi tutti quelli installati tramite script, come VPP e altri).
Prima di tutto, controlliamo l'impatto del rilevamento automatico della MTU sulle prestazioni del TCP:
Impatto di MTU sulle prestazioni TCP
Un divario ancora maggiore si riscontra quando si utilizza UDP:
Impatto di MTU sulle prestazioni UDP
Dato l'ENORME impatto sulle prestazioni rivelato nei test, vorremmo inviare una lettera di speranza a tutti i manutentori di CNI: aggiungete il rilevamento automatico della MTU a CNI. Salverai gattini, unicorni e anche quello più carino: il piccolo Devop.
Tuttavia, se è necessario utilizzare CNI senza supporto per il rilevamento automatico della MTU, è possibile configurarlo manualmente per ottenere prestazioni. Tieni presente che questo vale per Calico, Canal e WeaveNet.
La mia piccola richiesta al CNI accompagnatore...
Test CNI: dati grezzi
In questa sezione confronteremo il CNI con la MTU corretta (determinata automaticamente o impostata manualmente). L'obiettivo principale qui è mostrare i dati grezzi nei grafici.
Legenda colori:
grigio - campione (cioè ferro nudo)
verde: larghezza di banda superiore a 9500 Mbps
giallo: larghezza di banda superiore a 9000 Mbps
arancione: larghezza di banda superiore a 8000 Mbps
rosso: larghezza di banda inferiore a 8000 Mbps
blu - neutro (non correlato alla larghezza di banda)
Consumo di risorse senza carico
Innanzitutto verificare il consumo delle risorse quando il cluster è “dormiente”.
Consumo di risorse senza carico
Da pod a pod
Questo scenario presuppone che il pod client si connetta direttamente al pod server utilizzando il suo indirizzo IP.
Scenario da pod a pod
TCP
Risultati TCP da pod a pod e consumo di risorse corrispondente:
UDP
Risultati UDP pod-to-pod e consumo di risorse corrispondente:
Pod-a-servizio
Questa sezione è rilevante per casi d'uso reali, il pod client si connette al pod server tramite il servizio ClusterIP.
Script da pod a servizio
TCP
Risultati TCP pod-to-service e corrispondente consumo di risorse:
UDP
Risultati UDP da pod a servizio e corrispondente consumo di risorse:
Supporto alle politiche di rete
Tra tutti questi, l'unico che non sostiene la politica è Flannel. Tutti gli altri implementano correttamente le politiche di rete, incluse quelle in entrata e in uscita. Ottimo lavoro!
Crittografia CNI
Tra i CNI controllati ci sono quelli in grado di crittografare lo scambio di rete tra Pod:
Antrea utilizzando IPsec
Calico utilizzando Wireguard
Cilium utilizzando IPsec
WeaveNet utilizzando IPsec
capacità
Poiché sono rimasti meno CNI, inseriamo tutti gli scenari in un unico grafico:
Consumo di risorse
In questa sezione valuteremo le risorse utilizzate durante l'elaborazione della comunicazione Pod-to-Pod in TCP e UDP. Non ha senso tracciare un grafico Pod-to-Service poiché non fornisce informazioni aggiuntive.
Mettere tutto insieme
Proviamo a ripetere tutti i grafici, qui abbiamo introdotto un po' di soggettività, sostituendo i valori effettivi con le parole “vwry fast”, “low”, ecc.
Conclusione e le mie conclusioni
Questo è un po' soggettivo, poiché sto trasmettendo la mia interpretazione dei risultati.
Sono contento che siano apparsi nuovi CNI, Antrea ha funzionato bene, molte funzioni sono state implementate anche nelle prime versioni: rilevamento automatico MTU, crittografia e facile installazione.
Se confrontiamo le prestazioni, tutti i CNI funzionano bene, tranne Kube-OVN e Kube-Router. Anche Kube-Router non è stato in grado di rilevare la MTU, non ho trovato un modo per configurarlo da nessuna parte nella documentazione (qui è aperta una richiesta su questo argomento).
In termini di consumo di risorse, Cilium utilizza ancora più RAM rispetto ad altri, ma il produttore punta chiaramente a cluster di grandi dimensioni, il che chiaramente non è la stessa cosa di un test su un cluster a tre nodi. Anche Kube-OVN consuma molte risorse CPU e RAM, ma è un CNI giovane basato su Open vSwitch (come Antrea, performa meglio e consuma meno).
Tutti tranne Flannel hanno politiche di rete. È molto probabile che non li sosterrà mai, visto che l'obiettivo è più semplice di una rapa al vapore: più è leggera, meglio è.
Inoltre, tra le altre cose, le prestazioni di crittografia sono sorprendenti. Calico è uno dei CNI più vecchi, ma la crittografia è stata aggiunta solo un paio di settimane fa. Hanno scelto wireguard invece di IPsec e, in poche parole, funziona alla grande e in modo sorprendente, eclissando completamente gli altri CNI in questa parte del test. Naturalmente, il consumo di risorse aumenta a causa della crittografia, ma il throughput raggiunto ne vale la pena (Calico ha mostrato un miglioramento di sei volte nel test di crittografia rispetto a Cilium, che è al secondo posto). Inoltre, puoi abilitare wireguard in qualsiasi momento dopo aver distribuito Calico nel cluster e, se lo desideri, puoi anche disabilitarlo per un breve periodo o in modo permanente. È incredibilmente conveniente, però! Ti ricordiamo che Calico attualmente non rileva automaticamente l'MTU (questa funzionalità è prevista per le versioni future), quindi assicurati di configurare l'MTU se la tua rete supporta Jumbo Frames (MTU 9000).
Tra le altre cose, tieni presente che Cilium può crittografare il traffico tra i nodi del cluster (e non solo tra i pod), il che può essere molto importante per i nodi del cluster pubblico.
In conclusione, suggerisco i seguenti casi d’uso:
Ho bisogno di CNI per un cluster molto piccolo OPPURE non ho bisogno di sicurezza: lavorare con Flanella, il CNI più leggero e stabile (è anche uno dei più antichi, secondo la leggenda fu inventato dall'Homo Kubernautus o Homo Contaitorus). Potrebbe interessarti anche il progetto più ingegnoso k3s, controllo!
Hai bisogno di CNI per un cluster regolare: Calico - la tua scelta, ma non dimenticare di configurare la MTU se necessario. Puoi giocare in modo semplice e naturale con le politiche di rete, attivare e disattivare la crittografia, ecc.
Hai bisogno di CNI per cluster su (molto) larga scala: Beh, il test non mostra il comportamento di cluster di grandi dimensioni, sarei felice di fare dei test, ma non abbiamo centinaia di server con una connessione a 10Gbps. Quindi l'opzione migliore è eseguire un test modificato sui tuoi nodi, almeno con Calico e Cilium.