See on minu värskendus , mis töötab nüüd Kubernetes 1.14-s koos uusima CNI-versiooniga 2019. aasta aprillis.
Kõigepealt tahan tänada Ciliumi meeskonda: poisid aitasid mul mõõdikute jälgimise skripte kontrollida ja parandada.
Mis on muutunud alates 2018. aasta novembrist
Pärast seda on muutunud (kui olete huvitatud):
Flanell jääb kiireimaks ja lihtsaimaks CNI-liideseks, kuid siiski ei toeta võrgupoliitikat ja krüptimist.
Romanat enam ei toetata, seega eemaldasime selle võrdlusalusest.
WeaveNet toetab nüüd Ingressi ja Egressi võrgupoliitikaid! Kuid tootlikkus on langenud.
Calico puhul peate parima jõudluse saavutamiseks siiski käsitsi konfigureerima maksimaalse paketi suuruse (MTU). Calico pakub CNI installimiseks kahte võimalust, nii et saate teha ilma eraldi ETCD hoidlata:
- oleku salvestamine Kubernetes API-s andmehoidlana (klastri suurus < 50 sõlme);
- oleku salvestamine Kubernetes API-sse Typha puhverserveriga andmehoidlana, et leevendada K8S API koormust (klastri suurus > 50 sõlme).
Calico teatas toetusest Istio peal rakenduse tasemel turvalisuse tagamiseks.
Cilium toetab nüüd krüptimist! Cilium pakub krüptimist IPSec-tunnelitega ja pakub alternatiivi krüptitud WeaveNeti võrgule. Kuid WeaveNet on lubatud krüptimisega kiirem kui Cilium.
Tänu sisseehitatud ETCD operaatorile on Ciliumit nüüd lihtsam juurutada.
Ciliumi meeskond on püüdnud oma CNI-st mõnevõrra vähendada, vähendades mälutarbimist ja protsessorikulusid, kuid tema konkurendid on siiski kergemad.
Võrdlusuuringu kontekst
Etalon töötab kolmes mittevirtualiseeritavas Supermicro serveris, millel on 10 Gb Supermicro lüliti. Serverid on passiivsete DAC SFP+ kaablite kaudu otse kommutaatoriga ühendatud ja konfigureeritud samasse VLAN-i koos jumbo raamidega (MTU 9000).
Kubernetes 1.14.0 installitud Ubuntu 18.04 LTS-ile koos versiooniga Docker 18.09.2 (selles versioonis Dockeri vaikeversioon).
Reprodutseeritavuse parandamiseks otsustasime alati konfigureerida ülemseadme esimeses sõlmes, asetada võrdlusaluse serveriosa teise serverisse ja kliendiosa kolmandasse serverisse. Selleks kasutame Kubernetese juurutustes NodeSelectorit.
Kirjeldame võrdlusuuringu tulemusi järgmisel skaalal:
CNI valimine võrdlusaluseks
See on võrdlusalus ainult jaotises olevas loendis oleva CNI jaoks Vaadake ametlikku Kubernetese dokumentatsiooni. 9 CNI-st võtame ainult 6: välistame need, mida on raske paigaldada ja/või mis ei tööta ilma konfiguratsioonita vastavalt dokumentatsioonile (Romana, Contiv-VPP ja JuniperContrail/TungstenFabric).
Võrdleme järgmisi CNI-sid:
- Calico v3.6
- Canal v3.6 (põhimõtteliselt Flannel võrgu loomiseks + Calico tulemüürina)
- Cilium 1.4.2
- Flanell 0.11.0
- Kube-ruuter 0.2.5
- WeaveNet 2.5.1
Paigaldamine
Mida lihtsam on CNI-d paigaldada, seda parem on meie esmamulje. Kõiki võrdlusaluse CNI-sid on väga lihtne paigaldada (ühe või kahe käsuga).
Nagu me ütlesime, on serverid ja lüliti konfigureeritud suure raamiga (seadisime MTU väärtuseks 9000). Meil oleks hea meel, kui CNI määraks automaatselt MTU adapterite konfiguratsiooni põhjal. Kuid ainult Cilium ja Flannel said sellega hakkama. Ülejäänud CNI-del on GitHubis taotlused automaatse MTU avastamise lisamiseks, kuid me konfigureerime selle käsitsi, muutes Calico, Canali ja Kube-ruuteri ConfigMapi või edastades WeaveNeti jaoks keskkonnamuutuja.
Mis on vale MTU probleem? See diagramm näitab erinevust WeaveNeti vahel, kui MTU vaikeraamid on lubatud ja Jumbo kaadrid on lubatud:
Kuidas mõjutab MTU läbilaskevõimet?
Oleme näinud, kui oluline on MTU jõudluse jaoks. Nüüd vaatame, kuidas meie CNI-d selle automaatselt määravad.
CNI tuvastab automaatselt MTU
Graafik näitab, et optimaalse jõudluse tagamiseks peate konfigureerima MTU Calico, Canali, Kube-ruuteri ja WeaveNeti jaoks. Cilium ja Flannel suutsid MTU ise õigesti määrata ilma igasuguste seadistusteta.
turvalisus
Võrdleme CNI-turvalisust kahes aspektis: edastatud andmete krüpteerimise võimalus ja Kubernetese võrgupoliitika rakendamine (põhineb reaalsetel testidel, mitte dokumentatsioonil).
Ainult kaks CNI-d krüpteerivad andmeid: Cilium ja WeaveNet. Krüpteerimine WeaveNet See on lubatud, määrates krüpteerimisparooli CNI keskkonnamuutujaks. IN WeaveNet kirjeldab seda keeruliselt, kuid kõik tehakse lihtsalt. Krüpteerimine tsilium konfigureeritud käskude, Kubernetese saladuste loomise ja deemonSeti muutmise kaudu (veidi keerulisem kui WeaveNetis, kuid Ciliumil on samm-sammult ).
Mis puutub võrgupoliitika elluviimisse, siis see on neil õnnestunud Calico, Canal, Cilium ja WeaveNet, milles saate konfigureerida sisenemise ja väljumise reegleid. Sest Kube-ruuter reeglid kehtivad ainult Ingressi jaoks ja Flanell Võrgupoliitikad puuduvad.
Siin on üldised tulemused:
Ohutuse tulemuslikkuse võrdlusaluste tulemused
Производительность
See võrdlusalus näitab keskmist läbilaskevõimet iga testi vähemalt kolme jooksu jooksul. Testime TCP ja UDP (kasutades iperf3), reaalsete rakenduste nagu HTTP (koos Nginxi ja curliga) või FTP (koos vsftpd ja curliga) ja lõpuks rakenduste jõudlust SCP-põhist krüptimist kasutades (kasutades klienti ja serverit OpenSSH).
Kõigi testide jaoks tegime metallist võrdlusaluse (roheline joon), et võrrelda CNI jõudlust oma võrgu jõudlusega. Siin kasutame sama skaalat, kuid värviliselt:
- Kollane = väga hea
- Oranž = hea
- Sinine = nii-nii
- Punane = halb
Me ei võta valesti konfigureeritud CNI-sid ja näitame ainult õige MTU-ga CNI-de tulemusi. (Märkus. Kui lubate krüptimise, ei arvuta Cilium MTU-d õigesti, seega peate versioonis 8900 käsitsi MTU-d vähendama 1.4-ni. Järgmine versioon 1.5 teeb seda automaatselt.)
Siin on tulemused:
TCP jõudlus
Kõik CNI-d toimisid TCP võrdlusaluses hästi. Krüpteerimisega CNI jääb kõvasti maha, sest krüptimine on kallis.
UDP jõudlus
Ka siin läheb kõigil CNIdel hästi. Krüptimisega CNI näitas peaaegu sama tulemust. Cilium jääb küll konkurentidest veidi maha, kuid see on vaid 2,3% paljast metallist, nii et see pole halb tulemus. Ärge unustage, et ainult Cilium ja Flannel määrasid MTU õigesti ise ja need on nende tulemused ilma täiendava konfiguratsioonita.
Aga reaalne rakendus? Nagu näete, on HTTP üldine jõudlus pisut madalam kui TCP puhul. Isegi kui kasutate HTTP-d koos TCP-ga, konfigureerisime TCP-etaldis iperf3, et vältida aeglast käivitumist, mis mõjutaks HTTP-etaloni. Kõik tegid siin head tööd. Kube-ruuteril on selge eelis, kuid WeaveNet ei toiminud hästi: umbes 20% halvem kui paljas metall. Krüpteeringuga Cilium ja WeaveNet näevad tõesti kurvad välja.
Teise TCP-põhise protokolli FTP puhul on tulemused erinevad. Flanell ja Kube-ruuter teevad selle töö ära, kuid Calico, Canal ja Cilium jäävad veidi maha ja on umbes 10% aeglasemad kui paljas metall. WeaveNet jääb maha koguni 17%, kuid krüpteeritud WeaveNet edestab krüpteeritud Ciliumit 40%.
SCP-ga näeme kohe, kui palju SSH-krüptimine meile maksab. Peaaegu kõigil CNI-del läheb hästi, kuid WeaveNet on jälle maha jäänud. Krüptimisega Cilium ja WeaveNet on topeltkrüptimise (SSH + CNI) tõttu eeldatavalt halvimad.
Siin on kokkuvõtlik tabel tulemustega:
Ressursi tarbimine
Nüüd võrdleme, kuidas CNI tarbib ressursse suure koormuse korral (TCP ülekande ajal, 10 Gbps). Toimivustestides võrdleme CNI-d palja metalliga (roheline joon). Ressursitarbimise jaoks näitame puhast Kubernetes (lilla joon) ilma CNI-ta ja vaatame, kui palju lisaressursse CNI tarbib.
Alustame mälust. Siin on sõlmede RAM-i keskmine väärtus (välja arvatud puhvrid ja vahemälu) MB-des ülekande ajal.
Mälu tarbimine
Flanell ja Kube-ruuter näitasid suurepäraseid tulemusi - ainult 50 MB. Calicol ja Canal on mõlemal 70. WeaveNet tarbib selgelt rohkem kui teised – 130 MB ja Cilium koguni 400.
Nüüd kontrollime protsessori ajakulu. Tähelepanuväärne: diagramm näitab mitte protsente, vaid ppm, see tähendab, et 38 ppm "palja raua" puhul on 3,8%. Siin on tulemused:
CPU tarbimine
Calico, Canal, Flannel ja Kube-ruuter on CPU-d väga tõhusad – ainult 2% rohkem kui Kubernetes ilma CNI-ta. WeaveNet jääb 5% lisaprotsendiga kaugele maha, millele järgneb Cilium 7%.
Siin on kokkuvõte ressursside tarbimisest:
Tulemused
Tabel kõigi tulemustega:
Üldised võrdlusuuringu tulemused
Järeldus
Viimases osas avaldan oma subjektiivset arvamust tulemuste kohta. Pidage meeles, et see võrdlusalus testib ainult ühe ühenduse läbilaskevõimet väga väikeses klastris (3 sõlme). See ei kehti suurte klastrite (<50 sõlme) ega paralleelühenduste puhul.
Olenevalt stsenaariumist soovitan kasutada järgmisi CNI-sid:
- Kas teil on oma klastris väheste ressurssidega sõlmed (mitu GB RAM-i, mitu tuuma) ja te ei vaja turvafunktsioone – valige Flanell. See on üks kuluefektiivsemaid CNI-sid. Ja see ühildub paljude erinevate arhitektuuridega (amd64, arm, arm64 jne). Lisaks on see üks kahest (teine on Cilium) CNI-st, mis suudab automaatselt määrata MTU, nii et te ei pea midagi konfigureerima. Kube-ruuter sobib ka, kuid see pole standardne ja peate MTU käsitsi konfigureerima.
- Vajadusel krüptida võrku turvalisuse huvides võta WeaveNet. Ärge unustage määrata MTU suurust, kui kasutate suurkaadreid, ja lubage krüpteerimine, määrates keskkonnamuutuja kaudu parooli. Kuid parem on jõudlus unustada - see on krüpteerimise hind.
- eest tavakasutus Soovitada Calico. Seda CNI-d kasutatakse laialdaselt erinevates Kubernetese juurutustööriistades (Kops, Kubespray, Rancher jne). Nagu WeaveNeti puhul, konfigureerige Jumbo raamide kasutamisel kindlasti MTU ConfigMapis. See on multifunktsionaalne tööriist, mis on tõhus ressursside tarbimise, jõudluse ja turvalisuse osas.
Ja lõpuks soovitan teil arengut jälgida tsilium. Sellel CNI-l on väga aktiivne meeskond, kes töötab palju oma toote kallal (funktsioonid, ressursi kokkuhoid, jõudlus, turvalisus, klasterdamine ...) ja neil on väga huvitavad plaanid.
Visuaalne diagramm CNI valiku jaoks
Allikas: www.habr.com