Þetta er uppfærslan mín , sem keyrir nú á Kubernetes 1.14 með nýjustu CNI útgáfunni frá og með apríl 2019.
Fyrst af öllu vil ég þakka Cilium teyminu: strákarnir hjálpuðu mér að athuga og leiðrétta mælikvarðaforskriftirnar.
Hvað hefur breyst síðan í nóvember 2018
Hér er það sem hefur breyst síðan þá (ef þú hefur áhuga):
Flannel er áfram hraðasta og einfaldasta CNI viðmótið, en styður samt ekki netstefnur og dulkóðun.
Romana er ekki lengur stutt, svo við höfum fjarlægt það úr viðmiðinu.
WeaveNet styður nú netstefnur fyrir Ingress og Egress! En framleiðni hefur minnkað.
Í Calico þarftu samt að stilla hámarks pakkastærð (MTU) handvirkt fyrir bestu frammistöðu. Calico býður upp á tvo valkosti til að setja upp CNI, svo þú getur verið án sérstakrar ETCD geymslu:
- geymsluástand í Kubernetes API sem gagnageymslu (þyrpingastærð < 50 hnútar);
- að geyma ástand í Kubernetes API sem gagnageymslu með Typha proxy til að létta álagi á K8S API (þyrpingastærð > 50 hnútar).
Calico tilkynnti um stuðning ofan á Istio fyrir öryggi á forritastigi.
Cilium styður nú dulkóðun! Cilium veitir dulkóðun með IPSec göngum og býður upp á val við dulkóðaða WeaveNet netið. En WeaveNet er hraðari en Cilium með dulkóðun virka.
Cilium er nú auðveldara að dreifa þökk sé innbyggða ETCD rekstraraðilanum.
Cilium teymið hefur reynt að draga úr þyngd frá CNI með því að draga úr minnisnotkun og örgjörvakostnaði, en keppinautar þess eru enn léttari.
Viðmiðunarsamhengi
Viðmiðið er keyrt á þremur ó sýndargerðum Supermicro netþjónum með 10 Gb Supermicro rofi. Netþjónarnir eru tengdir beint við rofann með óvirkum DAC SFP+ snúrum og eru stilltir á sama VLAN með júmbó ramma (MTU 9000).
Kubernetes 1.14.0 sett upp á Ubuntu 18.04 LTS með Docker 18.09.2 (sjálfgefin Docker útgáfa í þessari útgáfu).
Til að bæta endurgerðanleika ákváðum við að stilla meistarann alltaf á fyrsta hnút, setja miðlarahlutann af viðmiðinu á annan netþjóninn og biðlarahlutann á þann þriðja. Til að gera þetta notum við NodeSelector í Kubernetes dreifingum.
Við munum lýsa viðmiðunarniðurstöðum á eftirfarandi mælikvarða:
Að velja CNI fyrir viðmið
Þetta er viðmiðun aðeins fyrir CNI af listanum í hlutanum Sjá opinber Kubernetes skjöl. Af 9 CNI tökum við aðeins 6: við munum útiloka þá sem erfitt er að setja upp og/eða virka ekki án stillingar samkvæmt skjölunum (Romana, Contiv-VPP og JuniperContrail/TungstenFabric).
Við munum bera saman eftirfarandi CNI:
- Calico v3.6
- Canal v3.6 (í meginatriðum Flannel fyrir netkerfi + Calico sem eldveggur)
- Cilium 1.4.2
- Flanell 0.11.0
- Kube-beini 0.2.5
- WeaveNet 2.5.1
Uppsetning
Því auðveldara sem CNI er að setja upp, því betri verður fyrstu sýn okkar. Mjög auðvelt er að setja upp allar CNIs frá viðmiðinu (með einni eða tveimur skipunum).
Eins og við sögðum eru netþjónarnir og rofinn stilltur með jumbo ramma virkt (við stillum MTU á 9000). Við værum ánægð ef CNI ákvarði MTU sjálfkrafa út frá uppsetningu millistykkisins. Hins vegar tókst aðeins Cilium og Flannel þetta. Restin af CNIs hafa beiðnir á GitHub um að bæta við sjálfvirkri MTU uppgötvun, en við munum stilla það handvirkt með því að breyta ConfigMap fyrir Calico, Canal og Kube-beini, eða senda umhverfisbreytu fyrir WeaveNet.
Hvað er vandamálið með rangt MTU? Þessi skýringarmynd sýnir muninn á WeaveNet með sjálfgefna MTU og jumbo ramma virkt:
Hvernig hefur MTU færibreytan áhrif á afköst?
Við höfum séð hversu mikilvægt MTU er fyrir frammistöðu, nú skulum við sjá hvernig CNI okkar ákvarða það sjálfkrafa:
CNI finnur sjálfkrafa MTU
Línuritið sýnir að þú þarft að stilla MTU fyrir Calico, Canal, Kube-beini og WeaveNet til að ná sem bestum árangri. Cilium og Flannel gátu sjálfir ákvarðað MTU rétt án nokkurra stillinga.
öryggi
Við munum bera saman CNI öryggi í tveimur þáttum: getu til að dulkóða send gögn og innleiðingu Kubernetes netstefnu (byggt á raunverulegum prófum, ekki skjölum).
Aðeins tvö CNI dulkóða gögn: Cilium og WeaveNet. Dulkóðun WeaveNet virkjað með því að stilla dulkóðunarlykilorðið sem CNI umhverfisbreytu. IN WeaveNet lýsir því á flókinn hátt, en allt er gert einfaldlega. Dulkóðun cilium stillt með skipunum, með því að búa til Kubernetes leyndarmál og með breytingu á daemonSet (aðeins flóknara en í WeaveNet, en Cilium hefur skref-fyrir-skref ).
Hvað varðar innleiðingu netstefnunnar hefur þeim tekist Calico, Canal, Cilium og WeaveNet, þar sem þú getur stillt Ingress og Egress reglur. Fyrir Kube-beini það eru reglur aðeins fyrir Ingress, og Flannel Það eru alls engar netstefnur.
Hér eru heildarúrslitin:
Niðurstöður öryggisárangurs
Framleiðni
Þetta viðmið sýnir meðalafköst yfir að minnsta kosti þrjár keyrslur hvers prófs. Við prófum frammistöðu TCP og UDP (með iperf3), alvöru forritum eins og HTTP (með Nginx og curl) eða FTP (með vsftpd og curl) og loks frammistöðu forrita með því að nota SCP-byggða dulkóðun (með því að nota biðlara og netþjón OpenSSH).
Fyrir allar prófanir gerðum við viðmið fyrir berum málm (græn lína) til að bera saman CNI árangur við innfæddan netafköst. Hér notum við sama kvarða, en í lit:
- Gult = mjög gott
- Appelsínugult = gott
- Blár = svo sem
- Rauður = slæmur
Við munum ekki taka rangt stillt CNI og munum aðeins sýna niðurstöður fyrir CNI með réttu MTU. (Athugið: Cilium reiknar MTU ekki rétt út ef þú kveikir á dulkóðun, þannig að þú verður að minnka MTU handvirkt í 8900 í útgáfu 1.4. Næsta útgáfa, 1.5, gerir þetta sjálfkrafa.)
Hér eru úrslitin:
TCP árangur
Öll CNI stóðu sig vel í TCP viðmiðinu. CNI með dulkóðun er langt á eftir því dulkóðun er dýr.
UDP árangur
Hér eru líka öll CNI að standa sig vel. CNI með dulkóðun sýndi næstum sömu niðurstöðu. Cilium er aðeins á eftir keppninni, en það er aðeins 2,3% af berum málmi, svo það er ekki slæmur árangur. Ekki gleyma því að aðeins Cilium og Flannel ákváðu MTU rétt sjálfir og þetta eru niðurstöður þeirra án frekari uppsetningar.
Hvað með alvöru umsókn? Eins og þú sérð er heildarafköst fyrir HTTP aðeins lægri en fyrir TCP. Jafnvel ef þú notar HTTP með TCP, stilltum við iperf3 í TCP viðmiðinu til að forðast hæga byrjun sem myndi hafa áhrif á HTTP viðmiðið. Hér stóðu allir sig vel. Kube-router hefur greinilega yfirburði, en WeaveNet stóð sig ekki vel: um það bil 20% verri en ber málmur. Cilium og WeaveNet með dulkóðun líta mjög sorglegt út.
Með FTP, annarri TCP-undirstaða siðareglur, eru niðurstöður mismunandi. Flannel og Kube-router gera verkið, en Calico, Canal og Cilium eru aðeins á eftir og eru um 10% hægari en beinn málmur. WeaveNet er á eftir um allt að 17%, en dulkóðað WeaveNet er 40% á undan dulkóðuðu Cilium.
Með SCP getum við strax séð hversu mikið SSH dulkóðun kostar okkur. Næstum öll CNI eru að standa sig vel, en WeaveNet er aftur á eftir. Cilium og WeaveNet með dulkóðun eru væntanlega verst vegna tvöfaldrar dulkóðunar (SSH + CNI).
Hér er yfirlitstafla með niðurstöðum:
Auðlindanotkun
Nú skulum við bera saman hvernig CNI notar auðlindir undir miklu álagi (við TCP flutning, 10 Gbps). Í frammistöðuprófum berum við saman CNI og ber málm (græn lína). Fyrir auðlindanotkun skulum við sýna hreina Kubernetes (fjólubláa lína) án CNI og sjá hversu margar aukaauðlindir CNI eyðir.
Byrjum á minni. Hér er meðalgildi fyrir vinnsluminni hnúta (án biðminni og skyndiminni) í MB meðan á flutningi stendur.
Minnisnotkun
Flannel og Kube-beini sýndu framúrskarandi árangur - aðeins 50 MB. Calico og Canal eru hver með 70. WeaveNet eyðir greinilega meira en hin - 130 MB og Cilium notar allt að 400.
Nú skulum við athuga CPU tímanotkun. Eftirtektarvert: skýringarmyndin sýnir ekki prósentur, heldur ppm, það er, 38 ppm fyrir „bert járn“ er 3,8%. Hér eru úrslitin:
CPU neysla
Calico, Canal, Flannel og Kube-beini eru mjög örgjörva duglegur - aðeins 2% meira en Kubernetes án CNI. WeaveNet er langt á eftir með 5% aukalega, þar á eftir kemur Cilium með 7%.
Hér er yfirlit yfir auðlindanotkun:
Niðurstöður
Tafla með öllum niðurstöðum:
Almennar niðurstöður viðmiðunar
Ályktun
Í síðasta hlutanum mun ég lýsa huglægu áliti mínu á niðurstöðunum. Mundu að þetta viðmið prófar aðeins afköst einnar tengingar á mjög litlum klasa (3 hnúta). Það á ekki við um stóra klasa (<50 hnúta) eða samhliða tengingar.
Ég mæli með því að nota eftirfarandi CNI eftir atburðarásinni:
- Ertu með í klasanum þínum hnúta með fáum auðlindum (nokkrir GB af vinnsluminni, nokkrir kjarna) og þú þarft ekki öryggiseiginleika - veldu Flannel. Þetta er ein hagkvæmasta CNI. Og það er samhæft við margs konar arkitektúr (amd64, arm, arm64, osfrv.). Að auki er þetta annað af tveimur (hinn er Cilium) CNI sem getur sjálfkrafa ákvarðað MTU, svo þú þarft ekki að stilla neitt. Kube-beini hentar líka, en hann er ekki eins og staðalbúnaður og þú þarft að stilla MTU handvirkt.
- Ef nauðsyn krefur dulkóða netið til öryggis, taktu WeaveNet. Ekki gleyma að tilgreina MTU stærðina ef þú ert að nota risaramma og virkja dulkóðun með því að tilgreina lykilorð í gegnum umhverfisbreytu. En það er betra að gleyma frammistöðu - það er kostnaðurinn við dulkóðun.
- Fyrir eðlileg notkun Советую Calico. Þetta CNI er mikið notað í ýmsum Kubernetes dreifingarverkfærum (Kops, Kubespray, Rancher, osfrv.). Eins og með WeaveNet, vertu viss um að stilla MTU í ConfigMap ef þú notar jumbo ramma. Það er fjölvirkt tól sem er skilvirkt hvað varðar auðlindanotkun, afköst og öryggi.
Og að lokum ráðlegg ég þér að fylgjast með þróuninni cilium. Þetta CNI hefur mjög virkt teymi sem vinnur mikið að vörunni sinni (eiginleikar, auðlindasparnaður, frammistaða, öryggi, þyrping...) og þeir hafa mjög áhugaverðar áætlanir.
Sjónræn skýringarmynd fyrir CNI val
Heimild: www.habr.com