Tai mano atnaujinimas , kuri dabar veikia Kubernetes 1.14 su naujausia CNI versija nuo 2019 m. balandžio mėn.
Visų pirma noriu padėkoti „Cilium“ komandai: vaikinai padėjo patikrinti ir pakoreguoti metrikos stebėjimo scenarijus.
Kas pasikeitė nuo 2018 m. lapkričio mėn
Štai kas nuo to laiko pasikeitė (jei jus domina):
Flanelė išlieka greičiausia ir paprasčiausia CNI sąsaja, tačiau vis tiek nepalaiko tinklo politikos ir šifravimo.
Romana nebepalaikoma, todėl pašalinome ją iš etalono.
„WeaveNet“ dabar palaiko „Ingress“ ir „Egress“ tinklo politiką! Tačiau produktyvumas sumažėjo.
Calico vis tiek turite rankiniu būdu sukonfigūruoti maksimalų paketo dydį (MTU), kad užtikrintumėte geriausią našumą. „Calico“ siūlo dvi CNI diegimo parinktis, todėl galite apsieiti be atskiros ETCD saugyklos:
- saugojimo būsena Kubernetes API kaip duomenų saugykla (klasterio dydis < 50 mazgų);
- saugojimo būseną Kubernetes API kaip duomenų saugyklą su Typha tarpiniu serveriu, kad būtų sumažinta K8S API apkrova (klasterio dydis > 50 mazgų).
Calico paskelbė palaikymą Istio viršuje, kad būtų užtikrintas programos lygio saugumas.
„Cilium“ dabar palaiko šifravimą! „Cilium“ teikia šifravimą naudojant IPSec tunelius ir siūlo alternatyvą šifruotam „WeaveNet“ tinklui. Tačiau „WeaveNet“ yra greitesnis nei „Cilium“, kai įjungtas šifravimas.
Dėl integruoto ETCD operatoriaus „Cilium“ dabar lengviau įdiegti.
„Cilium“ komanda bandė sumažinti savo CNI svorį sumažindama atminties suvartojimą ir procesoriaus išlaidas, tačiau jos konkurentai vis dar yra lengvesni.
Palyginimo kontekstas
Etalonas vykdomas trijuose nevirtualizuotuose „Supermicro“ serveriuose su 10 Gb „Supermicro“ jungikliu. Serveriai yra tiesiogiai prijungti prie jungiklio pasyviaisiais DAC SFP+ kabeliais ir yra sukonfigūruoti tame pačiame VLAN su dideliais rėmeliais (MTU 9000).
Kubernetes 1.14.0 įdiegta Ubuntu 18.04 LTS su Docker 18.09.2 (numatytoji Docker versija šiame leidime).
Siekdami pagerinti atkuriamumą, nusprendėme visada konfigūruoti pagrindinį pagrindinį elementą pirmame mazge, serverio etalono dalį įdėti į antrąjį serverį, o kliento dalį – trečiajame. Norėdami tai padaryti, „Kubernetes“ diegimuose naudojame „NodeSelector“.
Lyginamuosius rezultatus apibūdinsime tokia skale:
CNI pasirinkimas etalonui
Tai yra tik CNI etalonas iš skyriaus sąrašo Peržiūrėkite oficialią „Kubernetes“ dokumentaciją. Iš 9 CNI paimsime tik 6: išskirsime tuos, kuriuos sunku įdiegti ir/ar neveikia be konfigūracijos pagal dokumentaciją (Romana, Contiv-VPP ir JuniperContrail/TungstenFabric).
Palyginsime šiuos CNI:
- Calico v3.6
- Canal v3.6 (iš esmės Flannel tinkle + Calico kaip ugniasienė)
- Cilium 1.4.2
- Flanelė 0.11.0
- Kube-maršrutizatorius 0.2.5
- WeaveNet 2.5.1
Montavimas
Kuo lengviau bus įdiegti CNI, tuo geresnis bus pirmasis įspūdis. Visus CNI iš etalono labai lengva įdiegti (su viena ar dviem komandomis).
Kaip jau minėjome, serveriai ir jungiklis sukonfigūruoti su įgalintais dideliais rėmeliais (MTU nustatėme į 9000). Būtume laimingi, jei CNI automatiškai nustatytų MTU pagal adapterių konfigūraciją. Tačiau tai sugebėjo tik Cilium ir Flannel. Likusios CNI turi užklausas „GitHub“ pridėti automatinį MTU aptikimą, tačiau sukonfigūruosime jį rankiniu būdu pakeisdami „ConfigMap“, skirtą „Calico“, „Canal“ ir „Kube-router“, arba perduodami aplinkos kintamąjį „WeaveNet“.
Kokia yra neteisingo MTU problema? Šioje diagramoje parodytas skirtumas tarp „WeaveNet“ su numatytuoju MTU ir įjungtais „jumbo“ rėmeliais:
Kaip MTU veikia pralaidumą?
Matėme, koks svarbus MTU našumui, dabar pažiūrėkime, kaip mūsų CNI automatiškai jį nustato:
CNI automatiškai aptinka MTU
Diagrama rodo, kad norint pasiekti optimalų našumą, reikia sukonfigūruoti MTU Calico, Canal, Kube-router ir WeaveNet. Cilium ir Flannel sugebėjo patys teisingai nustatyti MTU be jokių nustatymų.
saugumas
CNI saugumą lyginsime dviem aspektais: galimybė šifruoti perduodamus duomenis ir Kubernetes tinklo politikos įgyvendinimas (remiantis tikrais testais, o ne dokumentacija).
Duomenis šifruoja tik dvi CNI: Cilium ir WeaveNet. Šifravimas WeaveNet įjungiamas nustatant šifravimo slaptažodį kaip CNI aplinkos kintamąjį. IN WeaveNet tai apibūdina sudėtingai, tačiau viskas daroma paprastai. Šifravimas ciliumas sukonfigūruojama komandomis, kuriant Kubernetes paslaptis ir modifikuojant demonSet (šiek tiek sudėtingiau nei WeaveNet, bet Cilium turi žingsnis po žingsnio ).
Kalbant apie tinklo politikos įgyvendinimą, jiems pavyko Calico, Canal, Cilium ir WeaveNet, kuriame galite konfigūruoti įėjimo ir išėjimo taisykles. Dėl Kube maršrutizatorius yra taisyklės tik Ingress, ir Flanelė Tinklo politikos apskritai nėra.
Štai bendri rezultatai:
Saugos efektyvumo etalono rezultatai
Našumas
Šis etalonas rodo vidutinį pralaidumą per mažiausiai tris kiekvieno bandymo paleidimus. Testuojame TCP ir UDP (naudojant iperf3), realių programų, tokių kaip HTTP (su Nginx ir curl) arba FTP (su vsftpd ir curl), našumą ir galiausiai programos našumą naudodami SCP pagrįstą šifravimą (naudojant klientą ir serverį OpenSSH).
Visiems bandymams atlikome gryno metalo etaloną (žalia linija), kad palygintume CNI našumą su vietinio tinklo našumu. Čia mes naudojame tą pačią skalę, bet spalvos:
- Geltona = labai gerai
- Oranžinė = gerai
- Mėlyna = taip ir taip
- Raudona = blogai
Mes neimsime neteisingai sukonfigūruotų CNI ir rodysime tik CNI su teisingu MTU rezultatus. (Pastaba: Cilium netinkamai apskaičiuoja MTU, jei įjungsite šifravimą, todėl turėsite rankiniu būdu sumažinti MTU iki 8900 1.4 versijoje. Kita versija, 1.5, tai padarys automatiškai.)
Štai rezultatai:
TCP našumas
Visi CNI veikė gerai pagal TCP etaloną. CNI su šifravimu labai atsilieka, nes šifravimas yra brangus.
UDP našumas
Čia taip pat visoms CNI sekasi gerai. CNI su šifravimu parodė beveik tą patį rezultatą. Cilium šiek tiek atsilieka nuo konkurentų, bet tik 2,3% pliko metalo, tad tai neblogas rezultatas. Nepamirškite, kad tik Cilium ir Flannel patys teisingai nustatė MTU, ir tai yra jų rezultatai be jokios papildomos konfigūracijos.
O kaip su realia programa? Kaip matote, bendras HTTP našumas yra šiek tiek mažesnis nei TCP. Net jei naudojate HTTP su TCP, mes sukonfigūravome iperf3 TCP etalone, kad išvengtume lėto paleidimo, kuris paveiktų HTTP etaloną. Visi čia padarė gerą darbą. Kube maršrutizatorius turi aiškų pranašumą, tačiau WeaveNet neveikė gerai: apie 20% blogiau nei plikas metalas. Cilium ir WeaveNet su šifravimu atrodo tikrai liūdnai.
Naudojant FTP, kitą TCP pagrįstą protokolą, rezultatai skiriasi. „Flanel“ ir „Kube-router“ atlieka savo darbą, tačiau „Calico“, „Canal“ ir „Cilium“ šiek tiek atsilieka ir yra maždaug 10% lėtesni nei plikas metalas. „WeaveNet“ atsilieka net 17%, tačiau šifruotas „WeaveNet“ lenkia šifruotą „Cilium“ 40%.
Su SCP iš karto matome, kiek mums kainuoja SSH šifravimas. Beveik visoms CNI sekasi gerai, tačiau WeaveNet vėl atsilieka. Tikimasi, kad „Cilium“ ir „WeaveNet“ su šifravimu yra patys blogiausi dėl dvigubo šifravimo (SSH + CNI).
Pateikiame suvestinę lentelę su rezultatais:
Išteklių suvartojimas
Dabar palyginkime, kaip CNI sunaudoja resursus esant didelėms apkrovoms (TCP perdavimo metu, 10 Gbps). Veikimo testuose mes lyginame CNI su pliko metalo (žalia linija). Norėdami sunaudoti išteklius, parodykime gryną Kubernetes (violetinė linija) be CNI ir pažiūrėkime, kiek papildomų išteklių sunaudoja CNI.
Pradėkime nuo atminties. Čia yra vidutinė mazgų RAM vertė (išskyrus buferius ir talpyklą) MB perkėlimo metu.
Atminties suvartojimas
Flanel ir Kube-router parodė puikius rezultatus - tik 50 MB. „Calico“ ir „Canal“ turi po 70. „WeaveNet“ aiškiai sunaudoja daugiau nei kiti – 130 MB, o „Cilium“ – net 400.
Dabar patikrinkime procesoriaus laiko sąnaudas. Pažymėtina: diagramoje rodomi ne procentai, o ppm, tai yra, 38 ppm „pliko geležies“ yra 3,8%. Štai rezultatai:
CPU suvartojimas
„Calico“, „Canal“, „Flanel“ ir „Kube-router“ yra labai efektyvūs CPU – tik 2% daugiau nei „Kubernetes“ be CNI. „WeaveNet“ smarkiai atsilieka su papildomais 5%, po to „Cilium" su 7%.
Čia yra išteklių naudojimo santrauka:
rezultatai
Lentelė su visais rezultatais:
Bendrieji lyginamieji rezultatai
išvada
Paskutinėje dalyje išsakysiu savo subjektyvią nuomonę apie rezultatus. Atminkite, kad šis etalonas tikrina tik vieno ryšio pralaidumą labai mažame klasteryje (3 mazgai). Tai netaikoma didelėms grupėms (<50 mazgų) arba lygiagrečioms jungtims.
Atsižvelgiant į scenarijų, rekomenduoju naudoti šiuos CNI:
- Ar turite savo klasteryje mazgai, turintys nedaug išteklių (keli GB RAM, keli branduoliai) ir jums nereikia saugos funkcijų – rinkitės Flanelė. Tai vienas iš ekonomiškiausių CNI. Ir jis suderinamas su įvairiomis architektūromis (amd64, arm, arm64 ir kt.). Be to, tai yra vienas iš dviejų (kitas yra Cilium) CNI, kuris gali automatiškai nustatyti MTU, todėl jums nereikia nieko konfigūruoti. Kube maršrutizatorius taip pat tinka, tačiau jis nėra standartinis ir jums reikės rankiniu būdu sukonfigūruoti MTU.
- Jei reikia užšifruoti tinklą dėl saugumo paimkite WeaveNet. Nepamirškite nurodyti MTU dydžio, jei naudojate didžiuosius rėmelius, ir įgalinkite šifravimą nurodydami slaptažodį per aplinkos kintamąjį. Tačiau geriau pamiršti apie našumą - tai yra šifravimo kaina.
- Už įprastas naudojimas Patariu kartūnas. Šis CNI plačiai naudojamas įvairiuose Kubernetes diegimo įrankiuose (Kops, Kubespray, Rancher ir kt.). Kaip ir „WeaveNet“, būtinai sukonfigūruokite MTU „ConfigMap“, jei naudojate „jumbo“ rėmelius. Tai daugiafunkcis įrankis, efektyvus išteklių suvartojimo, našumo ir saugumo požiūriu.
Ir galiausiai patariu sekti raidą ciliumas. Šis CNI turi labai aktyvią komandą, kuri daug dirba su savo produktu (funkcijomis, išteklių taupymu, našumu, saugumu, grupavimu...) ir turi labai įdomių planų.
Vaizdinė CNI pasirinkimo schema
Šaltinis: www.habr.com