Aquesta és la meva actualització , que ara s'executa a Kubernetes 1.14 amb la darrera versió de CNI a partir d'abril de 2019.
En primer lloc, vull donar les gràcies a l'equip de Cilium: els nois m'han ajudat a comprovar i corregir els scripts de seguiment de mètriques.
Què ha canviat des del novembre de 2018
Aquí teniu el que ha canviat des de llavors (si us interessa):
Flannel segueix sent la interfície CNI més ràpida i senzilla, però encara no admet polítiques de xarxa i xifratge.
Romana ja no s'admet, així que l'hem eliminat del benchmark.
WeaveNet ara admet polítiques de xarxa per a l'entrada i la sortida! Però la productivitat ha disminuït.
A Calico, encara heu de configurar manualment la mida màxima de paquet (MTU) per obtenir el millor rendiment. Calico ofereix dues opcions per instal·lar CNI, de manera que podeu prescindir d'un repositori ETCD separat:
- l'estat d'emmagatzematge a l'API de Kubernetes com a magatzem de dades (mida del clúster < 50 nodes);
- estat d'emmagatzematge a l'API de Kubernetes com a magatzem de dades amb un servidor intermediari Typha per alleujar la càrrega de l'API K8S (mida del clúster > 50 nodes).
Calico va anunciar suport a la part superior d'Istio per a la seguretat a nivell d'aplicació.
Cilium ara admet el xifratge! Cilium proporciona xifratge amb túnels IPSec i ofereix una alternativa a la xarxa WeaveNet xifrada. Però WeaveNet és més ràpid que Cilium amb el xifratge habilitat.
Ara Cilium és més fàcil de desplegar gràcies a l'operador ETCD integrat.
L'equip de Cilium ha intentat reduir el pes del seu CNI reduint el consum de memòria i els costos de la CPU, però els seus competidors encara són més lleugers.
Context de referència
El punt de referència s'executa en tres servidors Supermicro no virtualitzats amb un commutador Supermicro de 10 Gb. Els servidors es connecten directament al commutador mitjançant cables DAC SFP+ passius i es configuren a la mateixa VLAN amb trames jumbo (MTU 9000).
Kubernetes 1.14.0 instal·lat a Ubuntu 18.04 LTS amb Docker 18.09.2 (la versió predeterminada de Docker en aquesta versió).
Per millorar la reproductibilitat, vam decidir configurar sempre el mestre al primer node, col·locar la part del servidor del benchmark al segon servidor i la part del client al tercer. Per fer-ho, utilitzem NodeSelector als desplegaments de Kubernetes.
Descriurem els resultats de referència a la següent escala:
Selecció d'un CNI per a un punt de referència
Aquest és un punt de referència només per a CNI de la llista de l'apartat Consulteu la documentació oficial de Kubernetes. Dels 9 CNI, n'agafarem només 6: exclourem els que siguin difícils d'instal·lar i/o no funcionin sense configuració segons la documentació (Romana, Contiv-VPP i JuniperContrail/TungstenFabric).
Compararem els següents CNI:
- Calico v3.6
- Canal v3.6 (essencialment Flannel per a xarxes + Calico com a tallafoc)
- Cilium 1.4.2
- Franela 0.11.0
- Kube-encaminador 0.2.5
- WeaveNet 2.5.1
Instal · lació
Com més fàcil sigui d'instal·lar el CNI, millor serà la nostra primera impressió. Tots els CNI del benchmark són molt fàcils d'instal·lar (amb una o dues ordres).
Com dèiem, els servidors i el commutador estan configurats amb trames jumbo habilitades (configurem la MTU a 9000). Ens agradaria que el CNI determini automàticament la MTU en funció de la configuració dels adaptadors. Tanmateix, només Cilium i Flannel ho van aconseguir. La resta de CNI tenen sol·licituds a GitHub per afegir un descobriment automàtic de MTU, però ho configurarem manualment canviant el ConfigMap per Calico, Canal i Kube-router, o passant una variable d'entorn per a WeaveNet.
Quin és el problema amb la MTU incorrecta? Aquest diagrama mostra la diferència entre WeaveNet amb MTU per defecte i trames jumbo habilitades:
Com afecta la MTU al rendiment?
Hem vist com d'important és el MTU per al rendiment, ara veiem com el determinen automàticament els nostres CNI:
CNI detecta automàticament MTU
El gràfic mostra que cal configurar la MTU per Calico, Canal, Kube-router i WeaveNet per obtenir un rendiment òptim. Cilium i Flannel van poder determinar correctament el MTU ells mateixos sense cap configuració.
Безопасность
Compararem la seguretat del CNI en dos aspectes: la capacitat de xifrar les dades transmeses i la implementació de polítiques de xarxa de Kubernetes (basades en proves reals, no en documentació).
Només dos CNI xifren dades: Cilium i WeaveNet. Xifratge WeaveNet activat establint la contrasenya de xifratge com a variable d'entorn CNI. EN WeaveNet ho descriu d'una manera complicada, però tot es fa simplement. Xifratge Cili configurat per ordres, mitjançant la creació de secrets de Kubernetes i mitjançant la modificació del daemonSet (una mica més complicat que a WeaveNet, però Cilium té pas a pas ).
Pel que fa a la implementació de la política de xarxa, ho han aconseguit Calico, Canal, Cilium i WeaveNet, on podeu configurar regles d'entrada i sortida. Per Kube-encaminador només hi ha regles per a Ingress, i Flanel No hi ha polítiques de xarxa en absolut.
Aquests són els resultats globals:
Resultats de referència de rendiment de seguretat
Productivitat
Aquest punt de referència mostra el rendiment mitjà d'almenys tres execucions de cada prova. Provem el rendiment de TCP i UDP (utilitzant iperf3), aplicacions reals com HTTP (amb Nginx i curl) o FTP (amb vsftpd i curl) i finalment el rendiment de l'aplicació mitjançant xifratge basat en SCP (utilitzant client i servidor OpenSSH).
Per a totes les proves, vam realitzar un punt de referència de metall nu (línia verda) per comparar el rendiment CNI amb el rendiment de la xarxa nativa. Aquí fem servir la mateixa escala, però en color:
- Groc = molt bo
- Taronja = bo
- Blau = tan així
- Vermell = dolent
No agafarem CNI configurats incorrectament i només mostrarem resultats per a CNI amb la MTU correcta. (Nota: Cilium no calcula correctament la MTU si activeu el xifratge, de manera que haureu de reduir manualment la MTU a 8900 a la versió 1.4. La següent versió, la 1.5, ho fa automàticament.)
Aquests són els resultats:
Rendiment TCP
Tots els CNI van tenir un bon rendiment en el benchmark TCP. CNI amb xifratge es queda molt enrere perquè el xifratge és car.
Rendiment UDP
També aquí tots els CNI van bé. CNI amb xifratge va mostrar gairebé el mateix resultat. Cilium està una mica per darrere de la competència, però només és un 2,3% de metall nu, així que no és un mal resultat. No oblideu que només Cilium i Flannel van determinar correctament el MTU ells mateixos, i aquests són els seus resultats sense cap configuració addicional.
Què passa amb una aplicació real? Com podeu veure, el rendiment general d'HTTP és lleugerament inferior al de TCP. Fins i tot si feu servir HTTP amb TCP, hem configurat iperf3 al punt de referència TCP per evitar un inici lent que afectaria el punt de referència HTTP. Aquí tothom va fer una bona feina. Kube-router té un avantatge clar, però WeaveNet no va funcionar bé: aproximadament un 20% pitjor que el metall nu. Cilium i WeaveNet amb xifratge semblen molt tristos.
Amb FTP, un altre protocol basat en TCP, els resultats varien. Flannel i Kube-router fan la feina, però Calico, Canal i Cilium estan una mica endarrerits i són un 10% més lents que el metall nu. WeaveNet està enrere fins a un 17%, però WeaveNet xifrat està un 40% per davant de Cilium xifrat.
Amb SCP podem veure immediatament quant ens costa el xifratge SSH. Gairebé tots els CNI ho estan fent bé, però WeaveNet torna a quedar enrere. S'espera que Cilium i WeaveNet amb xifratge siguin els pitjors a causa del doble xifratge (SSH + CNI).
Aquí teniu una taula resum amb els resultats:
Consum de recursos
Ara comparem com CNI consumeix recursos amb càrregues pesades (durant la transferència TCP, 10 Gbps). En les proves de rendiment comparem CNI amb metall nu (línia verda). Per al consum de recursos, mostrem Kubernetes purs (línia porpra) sense CNI i veiem quants recursos addicionals consumeix CNI.
Comencem per la memòria. Aquest és el valor mitjà de la memòria RAM dels nodes (exclosos els buffers i la memòria cau) en MB durant la transferència.
Consum de memòria
Flannel i Kube-router van mostrar excel·lents resultats: només 50 MB. Calico i Canal en tenen 70 cadascun. WeaveNet clarament consumeix més que els altres: 130 MB, i Cilium en fa servir fins a 400.
Ara comprovem el consum de temps de la CPU. Cal destacar: el diagrama no mostra percentatges, sinó ppm, és a dir, 38 ppm per "ferro nu" és un 3,8%. Aquests són els resultats:
Consum de CPU
Calico, Canal, Flannel i Kube-router són molt eficients amb la CPU: només un 2% més que Kubernetes sense CNI. WeaveNet es queda molt enrere amb un 5% addicional, seguit de Cilium amb un 7%.
Aquí teniu un resum del consum de recursos:
Resultats de
Taula amb tots els resultats:
Resultats generals de referència
Conclusió
A la darrera part expressaré la meva opinió subjectiva sobre els resultats. Recordeu que aquest punt de referència només prova el rendiment d'una única connexió en un clúster molt petit (3 nodes). No s'aplica a clústers grans (<50 nodes) ni a connexions paral·leles.
Recomano utilitzar els següents CNI segons l'escenari:
- Tens al teu clúster nodes amb pocs recursos (diversos GB de RAM, diversos nuclis) i no necessiteu funcions de seguretat: trieu Flanel. Aquest és un dels CNI més rendibles. I és compatible amb una gran varietat d'arquitectures (amd64, arm, arm64, etc.). A més, aquest és un dels dos CNI (l'altre és Cilium) que poden determinar automàticament la MTU, de manera que no cal que configureu res. Kube-router també és adequat, però no és tan estàndard i haureu de configurar manualment la MTU.
- Si és necessari xifrar la xarxa per seguretat, pren WeaveNet. No us oblideu d'especificar la mida de la MTU si feu servir trames jumbo i habiliteu el xifratge especificant una contrasenya mitjançant una variable d'entorn. Però és millor oblidar-se del rendiment: aquest és el cost del xifratge.
- Per ús normal Советую Calic. Aquest CNI s'utilitza àmpliament en diverses eines de desplegament de Kubernetes (Kops, Kubespray, Rancher, etc.). Igual que amb WeaveNet, assegureu-vos de configurar la MTU a ConfigMap si feu servir trames jumbo. És una eina multifuncional que és eficient pel que fa al consum de recursos, rendiment i seguretat.
I, finalment, us aconsello que seguiu el desenvolupament Cili. Aquest CNI té un equip molt actiu que treballa molt en el seu producte (funcions, estalvi de recursos, rendiment, seguretat, clustering...) i tenen plans molt interessants.
Diagrama visual per a la selecció del CNI
Font: www.habr.com