To je moja posodobitev , ki zdaj deluje na Kubernetes 1.14 z najnovejšo različico CNI od aprila 2019.
Najprej se želim zahvaliti ekipi Cilium: fantje so mi pomagali preveriti in popraviti skripte za spremljanje metrik.
Kaj se je spremenilo od novembra 2018
Tukaj je tisto, kar se je od takrat spremenilo (če vas zanima):
Flannel ostaja najhitrejši in najpreprostejši vmesnik CNI, vendar še vedno ne podpira omrežnih politik in šifriranja.
Romana ni več podprta, zato smo jo odstranili iz primerjalne vrednosti.
WeaveNet zdaj podpira omrežne politike za Ingress in Egress! Toda produktivnost se je zmanjšala.
V Calicu morate še vedno ročno konfigurirati največjo velikost paketa (MTU) za najboljše delovanje. Calico ponuja dve možnosti za namestitev CNI, tako da lahko storite brez ločenega repozitorija ETCD:
- shranjevanje stanja v Kubernetes API kot shramba podatkov (velikost gruče < 50 vozlišč);
- shranjevanje stanja v API-ju Kubernetes kot shrambe podatkov s proxyjem Typha za razbremenitev API-ja K8S (velikost gruče > 50 vozlišč).
Calico je napovedal podporo na vrhu Istio za varnost na ravni aplikacije.
Cilium zdaj podpira šifriranje! Cilium zagotavlja šifriranje s tuneli IPSec in ponuja alternativo šifriranemu omrežju WeaveNet. Vendar je WeaveNet hitrejši od Ciliuma z omogočenim šifriranjem.
Cilium je zdaj lažji za uvajanje zahvaljujoč vgrajenemu operaterju ETCD.
Ekipa Cilium je poskušala zmanjšati težo svojega CNI z zmanjšanjem porabe pomnilnika in stroškov procesorja, vendar so njeni konkurenti še vedno lažji.
Primerjalni kontekst
Primerjalno merilo se izvaja na treh nevirtualiziranih strežnikih Supermicro s stikalom Supermicro 10 Gb. Strežniki so povezani neposredno s stikalom prek pasivnih kablov DAC SFP+ in so konfigurirani na istem VLAN z jumbo okvirji (MTU 9000).
Kubernetes 1.14.0 je nameščen na Ubuntu 18.04 LTS z Dockerjem 18.09.2 (privzeta različica Dockerja v tej izdaji).
Za izboljšanje ponovljivosti smo se odločili, da glavno enoto vedno konfiguriramo na prvem vozlišču, strežniški del merila uspešnosti postavimo na drugi strežnik in odjemalski del na tretjega. Za to uporabljamo NodeSelector v uvedbah Kubernetes.
Rezultate primerjalne analize bomo opisali na naslednji lestvici:
Izbira CNI za merilo uspešnosti
To je merilo samo za CNI s seznama v razdelku Oglejte si uradno dokumentacijo Kubernetes. Od 9 CNI-jev jih bomo vzeli le 6: izločili bomo tiste, ki jih je težko namestiti in/ali ne delujejo brez konfiguracije v skladu z dokumentacijo (Romana, Contiv-VPP in JuniperContrail/TungstenFabric).
Primerjali bomo naslednje CNI:
- Calico v3.6
- Canal v3.6 (v bistvu Flannel za mreženje + Calico kot požarni zid)
- Cilij 1.4.2
- Flanela 0.11.0
- Kube-usmerjevalnik 0.2.5
- WeaveNet 2.5.1
Namestitev
Lažje ko je CNI nameščen, boljši bo naš prvi vtis. Vse CNI-je iz primerjalnega preizkusa je zelo enostavno namestiti (z enim ali dvema ukazoma).
Kot smo rekli, so strežniki in stikalo konfigurirani z omogočenimi jumbo okvirji (MTU smo nastavili na 9000). Veseli bi bili, če bi CNI samodejno določil MTU na podlagi konfiguracije adapterjev. Vendar je to uspelo le Ciliumu in Flanelu. Preostali CNI-ji imajo na GitHubu zahteve za dodajanje samodejnega odkrivanja MTU, vendar ga bomo konfigurirali ročno, tako da spremenimo ConfigMap za Calico, Canal in Kube-router ali posredujemo spremenljivko okolja za WeaveNet.
V čem je težava z nepravilnim MTU? Ta diagram prikazuje razliko med WeaveNet s privzetim MTU in omogočenimi velikimi okvirji:
Kako MTU vpliva na prepustnost?
Videli smo, kako pomemben je MTU za zmogljivost, zdaj pa poglejmo, kako ga naši CNI samodejno določijo:
CNI samodejno zazna MTU
Graf prikazuje, da morate za optimalno delovanje konfigurirati MTU za Calico, Canal, Kube-router in WeaveNet. Cilium in Flannel sta lahko sama pravilno določila MTU brez kakršnih koli nastavitev.
varnost
Varnost CNI bomo primerjali v dveh vidikih: zmožnost šifriranja prenesenih podatkov in implementacija omrežnih politik Kubernetes (na podlagi resničnih testov, ne dokumentacije).
Samo dva CNI šifrirata podatke: Cilium in WeaveNet. Šifriranje WeaveNet omogočeno z nastavitvijo gesla za šifriranje kot spremenljivke okolja CNI. IN WeaveNet to opisuje na zapleten način, vendar je vse narejeno preprosto. Šifriranje Cilij konfiguriran z ukazi, z ustvarjanjem skrivnosti Kubernetes in s spreminjanjem daemonSet (malo bolj zapleteno kot v WeaveNetu, vendar ima Cilium korak za korakom ).
Kar zadeva izvajanje omrežne politike, jim je uspelo Calico, Canal, Cilium in WeaveNet, v katerem lahko konfigurirate pravila za vstop in izstop. Za Kube-usmerjevalnik obstajajo pravila samo za Ingress in Flannel Omrežnih pravilnikov sploh ni.
Tukaj so skupni rezultati:
Rezultati merila uspešnosti varnosti
Produktivnost
Ta primerjalna vrednost prikazuje povprečno prepustnost v vsaj treh zagonih vsakega preskusa. Preizkušamo delovanje TCP in UDP (z uporabo iperf3), resničnih aplikacij, kot je HTTP (z Nginx in curl) ali FTP (z vsftpd in curl) in končno delovanje aplikacij z uporabo šifriranja, ki temelji na SCP (z uporabo odjemalca in strežnika OpenSSH).
Za vse teste smo izvedli primerjalno merilo gole kovine (zelena črta), da bi primerjali zmogljivost CNI z zmogljivostjo domačega omrežja. Tukaj uporabljamo isto lestvico, vendar v barvah:
- Rumena = zelo dobra
- Oranžna = dobro
- Modra = tako-tako
- Rdeča = slabo
Ne bomo vzeli nepravilno konfiguriranih CNI-jev in bomo prikazali samo rezultate za CNI-je s pravilnim MTU. (Opomba: Cilium ne izračuna pravilno MTU, če omogočite šifriranje, zato boste morali ročno zmanjšati MTU na 8900 v različici 1.4. Naslednja različica, 1.5, to naredi samodejno.)
Tukaj so rezultati:
Učinkovitost TCP
Vsi CNI so se dobro odrezali pri merilu uspešnosti TCP. CNI s šifriranjem močno zaostaja, ker je šifriranje drago.
Zmogljivost UDP
Tudi tukaj gre vsem CNI dobro. CNI s šifriranjem je pokazal skoraj enak rezultat. Cilium malo zaostaja za konkurenco, vendar je le 2,3% gole kovine, tako da ni slab rezultat. Ne pozabite, da sta le Cilium in Flannel sama pravilno določila MTU in to so njuni rezultati brez dodatne konfiguracije.
Kaj pa prava aplikacija? Kot lahko vidite, je splošna zmogljivost za HTTP nekoliko nižja kot za TCP. Tudi če uporabljate HTTP s TCP, smo iperf3 konfigurirali v primerjalnem preizkusu TCP, da bi se izognili počasnemu zagonu, ki bi vplival na primerjalni preizkus HTTP. Tukaj so vsi dobro opravili svoje delo. Kube-usmerjevalnik ima jasno prednost, vendar WeaveNet ni dobro deloval: približno 20 % slabše od gole kovine. Cilium in WeaveNet s šifriranjem sta res žalostna.
Pri FTP, drugem protokolu, ki temelji na TCP, se rezultati razlikujejo. Flannel in Kube-router opravita delo, Calico, Canal in Cilium pa malo zaostajajo in so približno 10 % počasnejši od gole kovine. WeaveNet zaostaja za kar 17%, vendar je šifrirani WeaveNet 40% pred šifriranim Ciliumom.
S SCP lahko takoj vidimo, koliko nas stane šifriranje SSH. Skoraj vsem CNI gre dobro, vendar WeaveNet spet zaostaja. Cilium in WeaveNet s šifriranjem sta pričakovano najslabša zaradi dvojnega šifriranja (SSH + CNI).
Tukaj je zbirna tabela z rezultati:
Poraba virov
Zdaj pa primerjajmo, kako CNI porablja vire pod velikimi obremenitvami (med prenosom TCP, 10 Gbps). V testih zmogljivosti primerjamo CNI z golo kovino (zelena črta). Za porabo virov pokažimo čisti Kubernetes (vijolična črta) brez CNI in poglejmo, koliko dodatnih virov porabi CNI.
Začnimo s spominom. Tukaj je povprečna vrednost RAM-a vozlišč (brez medpomnilnikov in predpomnilnika) v MB med prenosom.
Poraba pomnilnika
Flannel in Kube-router sta pokazala odlične rezultate - le 50 MB. Calico in Canal jih imata vsak po 70. WeaveNet porabi očitno več kot drugi - 130 MB, Cilium pa kar 400.
Zdaj pa preverimo porabo časa procesorja. Omembe vredno: diagram ne prikazuje odstotkov, ampak ppm, to je 38 ppm za "golo železo" 3,8%. Tukaj so rezultati:
Poraba procesorja
Calico, Canal, Flannel in Kube-router so zelo učinkoviti pri procesorju – le 2 % več kot Kubernetes brez CNI. WeaveNet močno zaostaja z dodatnimi 5 %, sledi mu Cilium s 7 %.
Tukaj je povzetek porabe virov:
Rezultati
Tabela z vsemi rezultati:
Splošni rezultati primerjalnih testov
Zaključek
V zadnjem delu bom izrazil svoje subjektivno mnenje o rezultatih. Ne pozabite, da to merilo uspešnosti preizkuša samo prepustnost ene same povezave v zelo majhni gruči (3 vozlišča). Ne velja za velike gruče (<50 vozlišč) ali vzporedne povezave.
Glede na scenarij priporočam uporabo naslednjih CNI:
- Ali imate v svojem grozdu vozlišča z malo viri (več GB RAM-a, več jeder) in ne potrebujete varnostnih funkcij - izberite Flannel. To je eden izmed stroškovno najučinkovitejših CNI. Združljiv je z najrazličnejšimi arhitekturami (amd64, arm, arm64 itd.). Poleg tega je to eden od dveh (drugi je Cilium) CNI, ki lahko samodejno določi MTU, tako da vam ni treba ničesar konfigurirati. Primeren je tudi usmerjevalnik Kube, vendar ni standarden in boste morali ročno nastaviti MTU.
- Če je potrebno šifrirati omrežje zaradi varnosti vzemite WeaveNet. Ne pozabite določiti velikosti MTU, če uporabljate velike okvirje, in omogočite šifriranje tako, da podate geslo prek spremenljivke okolja. Vendar je bolje pozabiti na zmogljivost - to je strošek šifriranja.
- Za običajna uporaba sovetuû Calico. Ta CNI se pogosto uporablja v različnih orodjih za uvajanje Kubernetes (Kops, Kubespray, Rancher itd.). Kot pri WeaveNet, ne pozabite konfigurirati MTU v ConfigMap, če uporabljate velike okvirje. Je večnamensko orodje, ki je učinkovito v smislu porabe virov, zmogljivosti in varnosti.
In na koncu vam svetujem, da sledite razvoju Cilij. Ta CNI ima zelo aktivno ekipo, ki veliko dela na svojem izdelku (funkcije, prihranek virov, zmogljivost, varnost, grozdenje ...) in imajo zelo zanimive načrte.
Vizualni diagram za izbiro CNI
Vir: www.habr.com