Aceasta este actualizarea mea , care rulează acum pe Kubernetes 1.14 cu cea mai recentă versiune CNI din aprilie 2019.
În primul rând, vreau să mulțumesc echipei Cilium: băieții m-au ajutat să verific și să corectez scripturile de monitorizare a metricilor.
Ce s-a schimbat din noiembrie 2018
Iată ce s-a schimbat de atunci (dacă sunteți interesat):
Flannel rămâne cea mai rapidă și simplă interfață CNI, dar încă nu acceptă politicile de rețea și criptarea.
Romana nu mai este suportata, asa ca am scos-o din benchmark.
WeaveNet acceptă acum politicile de rețea pentru Intrare și Ieșire! Dar productivitatea a scăzut.
În Calico, mai trebuie să configurați manual dimensiunea maximă a pachetului (MTU) pentru performanță optimă. Calico oferă două opțiuni pentru instalarea CNI, astfel încât să puteți face fără un depozit ETCD separat:
- starea de stocare în API-ul Kubernetes ca depozit de date (dimensiunea clusterului < 50 de noduri);
- starea de stocare în API-ul Kubernetes ca depozit de date cu un proxy Typha pentru a ușura încărcarea API-ului K8S (dimensiunea clusterului > 50 de noduri).
Calico a anunțat sprijin peste Istio pentru securitate la nivel de aplicație.
Cilium acceptă acum criptarea! Cilium oferă criptare cu tuneluri IPSec și oferă o alternativă la rețeaua criptată WeaveNet. Dar WeaveNet este mai rapid decât Cilium cu criptarea activată.
Cilium este acum mai ușor de implementat datorită operatorului ETCD încorporat.
Echipa Cilium a încercat să reducă din greutatea CNI-ului său prin reducerea consumului de memorie și a costurilor cu procesorul, dar concurenții săi sunt încă mai ușori.
Context de referință
Benchmark-ul este rulat pe trei servere Supermicro nevirtualizate cu un comutator Supermicro de 10 Gb. Serverele sunt conectate direct la switch prin cabluri DAC SFP+ pasive și sunt configurate pe același VLAN cu cadre jumbo (MTU 9000).
Kubernetes 1.14.0 instalat pe Ubuntu 18.04 LTS cu Docker 18.09.2 (versiunea implicită Docker în această versiune).
Pentru a îmbunătăți reproductibilitatea, am decis să configuram întotdeauna masterul pe primul nod, să plasăm partea server a benchmark-ului pe al doilea server și partea client pe al treilea. Pentru a face acest lucru, folosim NodeSelector în implementările Kubernetes.
Vom descrie rezultatele benchmark-ului pe următoarea scară:
Selectarea unui CNI pentru un benchmark
Acesta este un benchmark doar pentru CNI din lista din sectiune Consultați documentația oficială Kubernetes. Din cele 9 CNI-uri, vom lua doar 6: le vom exclude pe cele care sunt greu de instalat și/sau nu funcționează fără configurare conform documentației (Romana, Contiv-VPP și JuniperContrail/TungstenFabric).
Vom compara următoarele CNI-uri:
- Calico v3.6
- Canal v3.6 (în esență Flannel pentru rețea + Calico ca firewall)
- Cilium 1.4.2
- Flanel 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Instalare
Cu cât CNI-ul este mai ușor de instalat, cu atât prima noastră impresie va fi mai bună. Toate CNI-urile din benchmark sunt foarte ușor de instalat (cu una sau două comenzi).
După cum am spus, serverele și comutatorul sunt configurate cu cadre jumbo activate (am setat MTU-ul la 9000). Ne-am bucura dacă CNI ar determina automat MTU-ul pe baza configurației adaptoarelor. Cu toate acestea, doar Cilium și Flannel au reușit acest lucru. Restul CNI-urilor au solicitări pe GitHub pentru a adăuga descoperirea automată a MTU, dar o vom configura manual schimbând ConfigMap pentru Calico, Canal și Kube-router sau trecând o variabilă de mediu pentru WeaveNet.
Care este problema cu MTU incorect? Această diagramă arată diferența dintre WeaveNet cu MTU implicit și cadrele jumbo activate:
Cum afectează MTU debitul?
Am văzut cât de important este MTU pentru performanță, acum să vedem cum îl determină automat CNI-urile noastre:
CNI detectează automat MTU
Graficul arată că trebuie să configurați MTU pentru Calico, Canal, Kube-router și WeaveNet pentru o performanță optimă. Cilium și Flannel au reușit să determine corect MTU-ul fără nicio setare.
Безопасность
Vom compara securitatea CNI sub două aspecte: capacitatea de a cripta datele transmise și implementarea politicilor de rețea Kubernetes (bazate pe teste reale, nu pe documentație).
Doar două CNI-uri criptează datele: Cilium și WeaveNet. Criptare WeaveNet activată prin setarea parolei de criptare ca variabilă de mediu CNI. ÎN WeaveNet îl descrie într-un mod complicat, dar totul se face simplu. Criptare ciliu configurat prin comenzi, prin crearea de secrete Kubernetes și prin modificarea daemonSet-ului (puțin mai complicat decât în WeaveNet, dar Cilium are pas cu pas ).
În ceea ce privește implementarea politicii de rețea, acestea au reușit Calico, Canal, Cilium și WeaveNet, în care puteți configura regulile de intrare și ieșire. Pentru Kube-router există reguli doar pentru Ingress și Flanel Nu există politici de rețea deloc.
Iată rezultatele generale:
Rezultate de referință de performanță de siguranță
productivitate
Acest benchmark arată debitul mediu pe cel puțin trei runde ale fiecărui test. Testăm performanța TCP și UDP (folosind iperf3), aplicații reale precum HTTP (cu Nginx și curl) sau FTP (cu vsftpd și curl) și în final performanța aplicației folosind criptarea bazată pe SCP (folosind client și server OpenSSH).
Pentru toate testele, am efectuat un benchmark bare metal (linia verde) pentru a compara performanța CNI cu performanța rețelei native. Aici folosim aceeași scară, dar în culoare:
- Galben = foarte bun
- Portocaliu = bun
- Albastru = așa-așa
- Roșu = rău
Nu vom lua CNI-uri configurate incorect și vom afișa numai rezultate pentru CNI-urile cu MTU-ul corect. (Notă: Cilium nu calculează corect MTU dacă activați criptarea, așa că va trebui să reduceți manual MTU la 8900 în versiunea 1.4. Următoarea versiune, 1.5, face acest lucru automat.)
Iată rezultatele:
Performanță TCP
Toate CNI-urile au avut rezultate bune în benchmark-ul TCP. CNI cu criptare rămâne cu mult în urmă, deoarece criptarea este costisitoare.
Performanță UDP
Și aici toate CNI-urile merg bine. CNI cu criptare a arătat aproape același rezultat. Cilium este puțin în urmă față de concurență, dar este doar 2,3% bare metal, așa că nu este un rezultat rău. Nu uitați că doar Cilium și Flannel au determinat MTU-ul corect, iar acestea sunt rezultatele lor fără nicio configurație suplimentară.
Dar o aplicație reală? După cum puteți vedea, performanța generală pentru HTTP este puțin mai mică decât pentru TCP. Chiar dacă utilizați HTTP cu TCP, am configurat iperf3 în benchmarkul TCP pentru a evita o pornire lentă care ar afecta benchmarkul HTTP. Toată lumea a făcut o treabă bună aici. Kube-router are un avantaj clar, dar WeaveNet nu a funcționat bine: cu aproximativ 20% mai rău decât bare metal. Cilium și WeaveNet cu criptare arată foarte trist.
Cu FTP, un alt protocol bazat pe TCP, rezultatele variază. Flannel și Kube-router fac treaba, dar Calico, Canal și Cilium sunt puțin în urmă și sunt cu aproximativ 10% mai lente decât bare metal. WeaveNet este în urmă cu până la 17%, dar WeaveNet criptat este cu 40% înaintea Cilium criptat.
Cu SCP putem vedea imediat cât ne costă criptarea SSH. Aproape toate CNI-urile merg bine, dar WeaveNet rămâne din nou în urmă. Cilium și WeaveNet cu criptare sunt de așteptat cele mai proaste datorită criptării duble (SSH + CNI).
Iată un tabel rezumativ cu rezultatele:
Consumul de resurse
Acum haideți să comparăm modul în care CNI consumă resurse sub sarcini grele (în timpul transferului TCP, 10 Gbps). În testele de performanță comparăm CNI cu metalul gol (linia verde). Pentru consumul de resurse, să arătăm Kubernetes pur (linia violetă) fără CNI și să vedem câte resurse suplimentare consumă CNI.
Să începem cu memoria. Iată valoarea medie a RAM-ului nodurilor (excluzând bufferele și memoria cache) în MB în timpul transferului.
Consumul de memorie
Flannel și Kube-router au arătat rezultate excelente - doar 50 MB. Calico și Canal au fiecare câte 70. WeaveNet consumă în mod clar mai mult decât celelalte - 130 MB, iar Cilium folosește până la 400.
Acum să verificăm consumul de timp al procesorului. De remarcat: diagrama nu arată procente, ci ppm, adică 38 ppm pentru „fier gol” este 3,8%. Iată rezultatele:
consum CPU
Calico, Canal, Flannel și Kube-router sunt foarte eficiente CPU - cu doar 2% mai mult decât Kubernetes fără CNI. WeaveNet rămâne cu mult în urmă cu un plus de 5%, urmat de Cilium cu 7%.
Iată un rezumat al consumului de resurse:
Rezultatele
Tabel cu toate rezultatele:
Rezultate de referință generale
Concluzie
În ultima parte îmi voi exprima opinia subiectivă asupra rezultatelor. Rețineți că acest benchmark testează doar debitul unei singure conexiuni pe un cluster foarte mic (3 noduri). Nu se aplică clusterelor mari (<50 de noduri) sau conexiunilor paralele.
Recomand să utilizați următoarele CNI-uri în funcție de scenariu:
- Ai în cluster noduri cu putine resurse (mai mulți GB de RAM, mai multe nuclee) și nu aveți nevoie de funcții de securitate - alegeți Flanel. Acesta este unul dintre cele mai rentabile CNI-uri. Și este compatibil cu o mare varietate de arhitecturi (amd64, arm, arm64 etc.). În plus, acesta este unul dintre cele două (celălalt este Cilium) CNI care pot determina automat MTU-ul, deci nu trebuie să configurați nimic. Kube-router este, de asemenea, potrivit, dar nu este la fel de standard și va trebui să configurați manual MTU-ul.
- Dacă este necesar criptați rețeaua pentru siguranță, luați WeaveNet. Nu uitați să specificați dimensiunea MTU dacă utilizați cadre jumbo și să activați criptarea specificând o parolă printr-o variabilă de mediu. Dar este mai bine să uităm de performanță - acesta este costul criptării.
- Pentru utilizare normală recomanda Stambă. Acest CNI este utilizat pe scară largă în diferite instrumente de implementare Kubernetes (Kops, Kubespray, Rancher etc.). Ca și în cazul WeaveNet, asigurați-vă că configurați MTU-ul în ConfigMap dacă utilizați cadre jumbo. Este un instrument multifuncțional care este eficient în ceea ce privește consumul de resurse, performanța și securitatea.
Și, în sfârșit, vă sfătuiesc să urmăriți evoluția ciliu. Acest CNI are o echipă foarte activă care lucrează mult la produsul lor (funcții, economii de resurse, performanță, securitate, clustering...) și au planuri foarte interesante.
Diagrama vizuală pentru selecția CNI
Sursa: www.habr.com