Questo è il mio aggiornamento , che ora funziona su Kubernetes 1.14 con l'ultima versione CNI a partire da aprile 2019.
Innanzitutto voglio ringraziare il team di Cilium: i ragazzi mi hanno aiutato a controllare e correggere gli script di monitoraggio delle metriche.
Cosa è cambiato da novembre 2018
Ecco cosa è cambiato da allora (se sei interessato):
Flannel rimane l'interfaccia CNI più veloce e semplice, ma non supporta ancora le politiche di rete e la crittografia.
Romana non è più supportato, quindi lo abbiamo rimosso dal benchmark.
WeaveNet ora supporta le policy di rete per Ingress e Egress! Ma la produttività è diminuita.
In Calico, devi comunque configurare manualmente la dimensione massima del pacchetto (MTU) per ottenere le migliori prestazioni. Calico offre due opzioni per l'installazione di CNI, quindi puoi fare a meno di un repository ETCD separato:
- archiviazione dello stato nell'API Kubernetes come archivio dati (dimensione del cluster < 50 nodi);
- archiviazione dello stato nell'API Kubernetes come archivio dati con un proxy Typha per alleviare il carico sull'API K8S (dimensione del cluster > 50 nodi).
Calico ha annunciato il supporto oltre a Istio per la sicurezza a livello di applicazione.
Cilium ora supporta la crittografia! Cilium fornisce la crittografia con tunnel IPSec e offre un'alternativa alla rete WeaveNet crittografata. Ma WeaveNet è più veloce di Cilium con la crittografia abilitata.
Cilium è ora più facile da implementare grazie all'operatore ETCD integrato.
Il team Cilium ha provato a ridurre un po' il peso del suo CNI riducendo il consumo di memoria e i costi della CPU, ma i suoi concorrenti sono ancora più leggeri.
Contesto di riferimento
Il benchmark viene eseguito su tre server Supermicro non virtualizzati con uno switch Supermicro da 10 Gb. I server sono collegati direttamente allo switch tramite cavi passivi DAC SFP+ e sono configurati sulla stessa VLAN con jumbo frame (MTU 9000).
Kubernetes 1.14.0 installato su Ubuntu 18.04 LTS con Docker 18.09.2 (la versione Docker predefinita in questa versione).
Per migliorare la riproducibilità abbiamo deciso di configurare sempre il master sul primo nodo, posizionare la parte server del benchmark sul secondo server e la parte client sul terzo. Per fare ciò, utilizziamo NodeSelector nelle distribuzioni Kubernetes.
Descriveremo i risultati del benchmark sulla seguente scala:
Selezione di un CNI per un punto di riferimento
Questo è un punto di riferimento solo per CNI dall'elenco nella sezione Consulta la documentazione ufficiale di Kubernetes. Dei 9 CNI ne prenderemo solo 6: escluderemo quelli difficili da installare e/o che non funzionano senza configurazione secondo la documentazione (Romana, Contiv-VPP e JuniperContrail/TungstenFabric).
Confronteremo i seguenti CNI:
- Calicò v3.6
- Canal v3.6 (essenzialmente Flannel per il networking + Calico come firewall)
- Cilio 1.4.2
- Flanella 0.11.0
- Router Kube 0.2.5
- WeaveNet 2.5.1
Installazione
Più facile sarà l'installazione del CNI, migliore sarà la nostra prima impressione. Tutti i CNI del benchmark sono molto facili da installare (con uno o due comandi).
Come abbiamo detto, i server e lo switch sono configurati con i jumbo frame abilitati (abbiamo impostato la MTU a 9000). Saremmo felici se il CNI determinasse automaticamente la MTU in base alla configurazione degli adattatori. Tuttavia, solo Cilium e Flannel ci sono riusciti. Il resto dei CNI hanno richieste su GitHub per aggiungere il rilevamento automatico della MTU, ma lo configureremo manualmente modificando ConfigMap per Calico, Canal e Kube-router o passando una variabile di ambiente per WeaveNet.
Qual è il problema con un MTU errato? Questo diagramma mostra la differenza tra WeaveNet con MTU predefinito e frame jumbo abilitati:
In che modo MTU influisce sul throughput?
Abbiamo visto quanto sia importante l'MTU per le prestazioni, ora vediamo come i nostri CNI lo determinano automaticamente:
CNI rileva automaticamente MTU
Il grafico mostra che è necessario configurare MTU per Calico, Canal, Kube-router e WeaveNet per prestazioni ottimali. Cilium e Flannel sono stati in grado di determinare correttamente la MTU da soli senza alcuna impostazione.
sicurezza
Confronteremo la sicurezza CNI sotto due aspetti: la capacità di crittografare i dati trasmessi e l'implementazione delle policy di rete Kubernetes (basate su test reali, non documentazione).
Solo due CNI crittografano i dati: Cilium e WeaveNet. Crittografia WeaveNet abilitato impostando la password di crittografia come variabile di ambiente CNI. IN WeaveNet lo descrive in modo complicato, ma tutto è fatto semplicemente. Crittografia Ciglio configurato dai comandi, creando segreti Kubernetes e attraverso la modifica del daemonSet (un po' più complicato che in WeaveNet, ma Cilium ha passo dopo passo ).
Per quanto riguarda l'attuazione della politica di rete, hanno avuto successo Calico, Canal, Cilium e WeaveNet, in cui è possibile configurare le regole di ingresso e di uscita. Per Router Kube ci sono regole solo per Ingress e Flanella Non ci sono affatto politiche di rete.
Ecco i risultati complessivi:
Risultati dei benchmark delle prestazioni di sicurezza
Производительность
Questo benchmark mostra il throughput medio su almeno tre esecuzioni di ciascun test. Testiamo le prestazioni di TCP e UDP (utilizzando iperf3), applicazioni reali come HTTP (con Nginx e curl) o FTP (con vsftpd e curl) e infine le prestazioni delle applicazioni utilizzando la crittografia basata su SCP (utilizzando client e server OpenSSH).
Per tutti i test, abbiamo eseguito un benchmark bare metal (linea verde) per confrontare le prestazioni CNI con le prestazioni della rete nativa. Qui usiamo la stessa scala, ma a colori:
- Giallo = molto buono
- Arancione = buono
- Blu = così così
- Rosso = cattivo
Non prenderemo CNI configurati in modo errato e mostreremo solo i risultati per CNI con la MTU corretta. (Nota: Cilium non calcola correttamente la MTU se abiliti la crittografia, quindi dovrai ridurre manualmente la MTU a 8900 nella versione 1.4. La versione successiva, 1.5, lo fa automaticamente.)
Ecco i risultati:
Prestazioni TCP
Tutti i CNI hanno ottenuto buoni risultati nel benchmark TCP. La CNI con la crittografia è molto indietro perché la crittografia è costosa.
Prestazioni dell'UDP
Anche qui tutti i CNI se la passano bene. Il CNI con la crittografia ha mostrato quasi lo stesso risultato. Cilium è un po' indietro rispetto alla concorrenza, ma è solo il 2,3% del bare metal, quindi non è un brutto risultato. Non dimenticare che solo Cilium e Flannel hanno determinato correttamente la MTU e questi sono i loro risultati senza alcuna configurazione aggiuntiva.
Che ne dici di una vera e propria applicazione? Come puoi vedere, le prestazioni complessive per HTTP sono leggermente inferiori a quelle per TCP. Anche se utilizzi HTTP con TCP, abbiamo configurato iperf3 nel benchmark TCP per evitare un avvio lento che potrebbe influire sul benchmark HTTP. Tutti hanno fatto un buon lavoro qui. Il router Kube ha un chiaro vantaggio, ma WeaveNet non ha funzionato bene: circa il 20% peggio del bare metal. Cilium e WeaveNet con la crittografia sembrano davvero tristi.
Con FTP, un altro protocollo basato su TCP, i risultati variano. Flannel e Kube-router fanno il lavoro, ma Calico, Canal e Cilium sono un po' indietro e sono circa il 10% più lenti del bare metal. WeaveNet è indietro fino al 17%, ma WeaveNet crittografato è avanti del 40% rispetto a Cilium crittografato.
Con SCP possiamo vedere immediatamente quanto ci costa la crittografia SSH. Quasi tutti i CNI stanno andando bene, ma WeaveNet è ancora una volta in ritardo. Cilium e WeaveNet con crittografia sono presumibilmente i peggiori a causa della doppia crittografia (SSH + CNI).
Ecco una tabella riassuntiva con i risultati:
Consumo di risorse
Ora confrontiamo il modo in cui CNI consuma le risorse in condizioni di carico pesante (durante il trasferimento TCP, 10 Gbps). Nei test prestazionali confrontiamo il CNI con il bare metal (linea verde). Per il consumo di risorse, mostriamo Kubernetes puro (linea viola) senza CNI e vediamo quante risorse extra consuma CNI.
Cominciamo con la memoria. Di seguito è riportato il valore medio della RAM dei nodi (esclusi buffer e cache) in MB durante il trasferimento.
Consumo di memoria
Flannel e Kube-router hanno mostrato risultati eccellenti: solo 50 MB. Calico e Canal ne hanno 70 ciascuno. WeaveNet consuma chiaramente più degli altri: 130 MB e Cilium ne utilizza fino a 400.
Ora controlliamo il consumo di tempo della CPU. Degno di nota: il diagramma non mostra percentuali, ma ppm, ovvero 38 ppm per “ferro nudo” è 3,8%. Ecco i risultati:
Consumo della CPU
Calico, Canal, Flannel e Kube-router sono molto efficienti in termini di CPU - solo il 2% in più rispetto a Kubernetes senza CNI. WeaveNet è molto indietro con un ulteriore 5%, seguito da Cilium al 7%.
Ecco un riepilogo del consumo di risorse:
Risultati di
Tabella con tutti i risultati:
Risultati benchmark generali
conclusione
Nell'ultima parte esprimerò la mia opinione soggettiva sui risultati. Ricorda che questo benchmark testa solo il throughput di una singola connessione su un cluster molto piccolo (3 nodi). Non si applica ai cluster di grandi dimensioni (<50 nodi) o alle connessioni parallele.
Consiglio di utilizzare i seguenti CNI a seconda dello scenario:
- Hai nel tuo cluster nodi con poche risorse (diversi GB di RAM, diversi core) e non hai bisogno di funzionalità di sicurezza: scegli Flanella. Questo è uno dei CNI più convenienti. Ed è compatibile con un'ampia varietà di architetture (amd64, arm, arm64, ecc.). Inoltre, questo è uno dei due CNI (l'altro è Cilium) in grado di determinare automaticamente la MTU, quindi non è necessario configurare nulla. Anche il router Kube è adatto, ma non è di serie e dovrai configurare manualmente la MTU.
- Se necessario crittografare la rete per sicurezza, prendi WeaveNet. Non dimenticare di specificare la dimensione MTU se stai utilizzando frame jumbo e abilitare la crittografia specificando una password tramite una variabile di ambiente. Ma è meglio dimenticare le prestazioni: questo è il costo della crittografia.
- per uso normale советую Calico. Questo CNI è ampiamente utilizzato in vari strumenti di distribuzione Kubernetes (Kops, Kubespray, Rancher, ecc.). Come con WeaveNet, assicurati di configurare la MTU in ConfigMap se usi i frame jumbo. È uno strumento multifunzionale efficiente in termini di consumo di risorse, prestazioni e sicurezza.
E infine, ti consiglio di seguire lo sviluppo Ciglio. Questo CNI ha un team molto attivo che lavora molto sul proprio prodotto (funzionalità, risparmio di risorse, prestazioni, sicurezza, clustering...) e ha piani molto interessanti.
Diagramma visivo per la selezione CNI
Fonte: habr.com