Hii ni sasisho langu , ambayo sasa inaendeshwa kwenye Kubernetes 1.14 ikiwa na toleo jipya zaidi la CNI kuanzia Aprili 2019.
Kwanza kabisa, nataka kuwashukuru timu ya Cilium: wavulana walinisaidia kuangalia na kusahihisha hati za ufuatiliaji wa metriki.
Nini kimebadilika tangu Novemba 2018
Haya ndiyo yaliyobadilika tangu wakati huo (ikiwa una nia):
Flana inasalia kuwa kiolesura cha haraka zaidi na rahisi zaidi cha CNI, lakini bado hakiauni sera za mtandao na usimbaji fiche.
Romana haitumiki tena, kwa hivyo tumeiondoa kwenye kigezo.
WeaveNet sasa inasaidia sera za mtandao za Ingress na Egress! Lakini tija imepungua.
Katika Calico, bado unahitaji kusanidi mwenyewe ukubwa wa juu wa pakiti (MTU) kwa utendakazi bora. Calico inatoa chaguzi mbili za kusakinisha CNI, kwa hivyo unaweza kufanya bila hazina tofauti ya ETCD:
- hali ya kuhifadhi katika Kubernetes API kama hifadhi ya data (ukubwa wa nguzo < nodi 50);
- hali ya kuhifadhi katika Kubernetes API kama hifadhi ya data iliyo na proksi ya Typha ili kupunguza mzigo kwenye API ya K8S (ukubwa wa nguzo > nodi 50).
Calico alitangaza msaada juu ya Istio kwa usalama wa kiwango cha maombi.
Cilium sasa inasaidia usimbaji fiche! Cilium hutoa usimbaji fiche kwa vichuguu vya IPSec na inatoa njia mbadala kwa mtandao uliosimbwa wa WeaveNet. Lakini WeaveNet ina kasi zaidi kuliko Cilium na usimbaji fiche umewezeshwa.
Cilium sasa ni rahisi kupeleka shukrani kwa mwendeshaji wa ETCD aliyejengewa ndani.
Timu ya Cilium imejaribu kupunguza uzito kutoka kwa CNI yake kwa kupunguza matumizi ya kumbukumbu na gharama za CPU, lakini washindani wake bado ni wepesi.
Muktadha wa kulinganisha
Kigezo kinaendeshwa kwenye seva tatu za Supermicro zisizo na mtandao zilizo na swichi ya 10 Gb Supermicro. Seva zimeunganishwa moja kwa moja kwenye swichi kupitia nyaya za DAC SFP+ na zimesanidiwa kwenye VLAN sawa na fremu kubwa (MTU 9000).
Kubernetes 1.14.0 iliyosakinishwa kwenye Ubuntu 18.04 LTS na Docker 18.09.2 (toleo chaguo-msingi la Docker katika toleo hili).
Ili kuboresha uzazi, tuliamua kusanidi bwana kila wakati kwenye nodi ya kwanza, weka sehemu ya seva ya alama kwenye seva ya pili, na sehemu ya mteja kwenye ya tatu. Ili kufanya hivyo, tunatumia NodeSelector katika uwekaji wa Kubernetes.
Tutaelezea matokeo ya benchmark kwa mizani ifuatayo:
Kuchagua CNI kwa alama
Hiki ni kigezo cha CNI pekee kutoka kwenye orodha katika sehemu Tazama hati rasmi ya Kubernetes. Kati ya CNI 9, tutachukua 6 tu: tutatenga wale ambao ni vigumu kufunga na / au hawafanyi kazi bila usanidi kulingana na nyaraka (Romana, Contiv-VPP na JuniperContrail/TungstenFabric).
Tutalinganisha CNI zifuatazo:
- Kaliko v3.6
- Mfereji v3.6 (kimsingi Flannel ya mitandao + Calico kama ngome)
- Cilium 1.4.2
- Flannel 0.11.0
- Kube-ruta 0.2.5
- WeaveNet 2.5.1
Ufungaji
Kadiri CNI inavyokuwa rahisi kusakinisha, ndivyo maoni yetu ya kwanza yatakavyokuwa bora. CNI zote kutoka kwa benchmark ni rahisi sana kusakinisha (kwa amri moja au mbili).
Kama tulivyosema, seva na swichi zimesanidiwa na fremu za jumbo zilizowezeshwa (tunaweka MTU hadi 9000). Tungefurahi ikiwa CNI itaamua kiotomatiki MTU kulingana na usanidi wa adapta. Walakini, Cilium na Flannel pekee ndio walisimamia hii. CNIs zingine zina maombi kwenye GitHub ya kuongeza ugunduzi wa MTU kiotomatiki, lakini tutaisanidi sisi wenyewe kwa kubadilisha ConfigMap ya Calico, Canal na Kube-router, au kupitisha mabadiliko ya mazingira kwa WeaveNet.
Kuna tatizo gani na MTU asiye sahihi? Mchoro huu unaonyesha tofauti kati ya WeaveNet na MTU chaguo-msingi na fremu kubwa zilizowezeshwa:
Je, MTU inaathiri vipi matokeo?
Tumeona jinsi MTU ilivyo muhimu kwa utendakazi, sasa hebu tuone jinsi CNI zetu zinavyoibainisha kiotomatiki:
CNI hutambua MTU kiotomatiki
Grafu inaonyesha kuwa unahitaji kusanidi MTU ya Calico, Canal, Kube-router na WeaveNet kwa utendakazi bora. Cilium na Flannel waliweza kuamua kwa usahihi MTU wenyewe bila mipangilio yoyote.
usalama
Tutalinganisha usalama wa CNI katika vipengele viwili: uwezo wa kusimba data inayotumwa kwa njia fiche na utekelezaji wa sera za mtandao wa Kubernetes (kulingana na majaribio halisi, si nyaraka).
Data mbili tu za CNI zilizosimbwa kwa njia fiche: Cilium na WeaveNet. Usimbaji fiche WeaveNet kuwezeshwa kwa kuweka nenosiri la usimbaji fiche kama kigeu cha mazingira cha CNI. KATIKA WeaveNet inaelezea kwa njia ngumu, lakini kila kitu kinafanywa kwa urahisi. Usimbaji fiche Kilio imeundwa na amri, kwa kuunda siri za Kubernetes, na kupitia urekebishaji wa daemonSet (ngumu zaidi kuliko katika WeaveNet, lakini Cilium ina hatua kwa hatua. ).
Kuhusu utekelezaji wa sera ya mtandao, wamefanikiwa Calico, Canal, Cilium na WeaveNet, ambayo unaweza kusanidi sheria za Ingress na Egress. Kwa Kube-router kuna sheria za Ingress tu, na Flannel Hakuna sera za mtandao hata kidogo.
Hapa kuna matokeo ya jumla:
Matokeo ya Benchmark ya Utendaji wa Usalama
Uzalishaji
Kigezo hiki kinaonyesha wastani wa matokeo zaidi ya angalau mara tatu za kila jaribio. Tunajaribu utendakazi wa TCP na UDP (kwa kutumia iperf3), programu-tumizi halisi kama HTTP (iliyo na Nginx na curl) au FTP (iliyo na vsftpd na curl) na hatimaye utendakazi wa programu kwa kutumia usimbaji fiche unaotegemea SCP (kwa kutumia mteja na seva ya OpenSSH).
Kwa majaribio yote, tulifanya alama ya chuma tupu (mstari wa kijani) ili kulinganisha utendaji wa CNI na utendakazi wa asili wa mtandao. Hapa tunatumia kiwango sawa, lakini kwa rangi:
- Njano = nzuri sana
- Orange = nzuri
- Bluu = hivyo-hivyo
- Nyekundu = mbaya
Hatutachukua CNI zilizosanidiwa vibaya na tutaonyesha tu matokeo ya CNI na MTU sahihi. (Kumbuka: Cilium haihesabu MTU kwa usahihi ikiwa utawezesha usimbaji fiche, kwa hivyo itabidi upunguze MTU mwenyewe hadi 8900 katika toleo la 1.4. Toleo linalofuata, 1.5, hufanya hivi kiotomatiki.)
Haya hapa matokeo:
Utendaji wa TCP
CNI zote zilifanya vyema katika kigezo cha TCP. CNI iliyo na usimbaji fiche iko nyuma sana kwa sababu usimbaji fiche ni ghali.
Utendaji wa UDP
Hapa, pia, CNI zote zinafanya vizuri. CNI iliyo na usimbaji fiche ilionyesha karibu matokeo sawa. Cilium ni nyuma kidogo ya ushindani, lakini ni 2,3% tu ya chuma tupu, hivyo sio matokeo mabaya. Usisahau kwamba tu Cilium na Flannel waliamua MTU kwa usahihi wenyewe, na haya ni matokeo yao bila usanidi wowote wa ziada.
Vipi kuhusu maombi halisi? Kama unavyoona, utendaji wa jumla wa HTTP uko chini kidogo kuliko TCP. Hata ukitumia HTTP na TCP, tulisanidi iperf3 katika alama ya TCP ili kuepuka kuanza polepole ambako kutaathiri alama ya HTTP. Kila mtu alifanya kazi nzuri hapa. Kube-router ina faida ya wazi, lakini WeaveNet haikufanya vizuri: karibu 20% mbaya zaidi kuliko chuma tupu. Cilium na WeaveNet zilizo na usimbaji fiche zinaonekana kusikitisha sana.
Kwa FTP, itifaki nyingine ya TCP, matokeo hutofautiana. Flannel na Kube-router hufanya kazi hiyo, lakini Calico, Canal na Cilium ziko nyuma kidogo na ziko polepole kwa 10% kuliko chuma tupu. WeaveNet iko nyuma kwa kiasi cha 17%, lakini WeaveNet iliyosimbwa kwa 40% iko mbele ya Cilium iliyosimbwa kwa njia fiche.
Kwa SCP tunaweza kuona mara moja ni kiasi gani cha usimbaji fiche wa SSH kinatugharimu. Takriban CNI zote zinaendelea vizuri, lakini WeaveNet iko nyuma tena. Cilium na WeaveNet zilizo na usimbaji fiche zinatarajiwa kuwa mbaya zaidi kutokana na usimbaji fiche mara mbili (SSH + CNI).
Hapa kuna jedwali la muhtasari na matokeo:
Matumizi ya rasilimali
Sasa hebu tulinganishe jinsi CNI hutumia rasilimali chini ya mizigo nzito (wakati wa uhamisho wa TCP, 10 Gbps). Katika vipimo vya utendaji tunalinganisha CNI na chuma tupu (mstari wa kijani). Kwa matumizi ya rasilimali, hebu tuonyeshe Kubernetes safi (mstari wa zambarau) bila CNI na tuone ni rasilimali ngapi za ziada ambazo CNI hutumia.
Wacha tuanze na kumbukumbu. Hapa kuna thamani ya wastani ya RAM ya nodi (bila kujumuisha bafa na akiba) katika MB wakati wa uhamishaji.
Matumizi ya kumbukumbu
Flannel na Kube-router ilionyesha matokeo bora - 50 MB tu. Calico na Canal kila moja ina 70. WeaveNet hutumia kwa uwazi zaidi kuliko zingine - 130 MB, na Cilium hutumia hadi 400.
Sasa hebu tuangalie matumizi ya wakati wa CPU. Ikumbukwe: mchoro hauonyeshi asilimia, lakini ppm, yaani, 38 ppm kwa "chuma tupu" ni 3,8%. Haya hapa matokeo:
Matumizi ya CPU
Calico, Canal, Flannel na Kube-router zina ufanisi wa CPU - 2% tu zaidi ya Kubernetes bila CNI. WeaveNet iko nyuma sana ikiwa na 5% ya ziada, ikifuatiwa na Cilium kwa 7%.
Hapa kuna muhtasari wa matumizi ya rasilimali:
Matokeo ya
Jedwali na matokeo yote:
Matokeo ya benchmark ya jumla
Hitimisho
Katika sehemu ya mwisho nitatoa maoni yangu juu ya matokeo. Kumbuka kuwa alama hii inajaribu tu upitishaji wa muunganisho mmoja kwenye nguzo ndogo sana (nodi 3). Haitumiki kwa makundi makubwa (<50 nodes) au miunganisho sambamba.
Ninapendekeza kutumia CNI zifuatazo kulingana na hali:
- Je! unayo kwenye nguzo yako nodi zilizo na rasilimali chache (GB kadhaa za RAM, cores kadhaa) na huhitaji vipengele vya usalama - chagua Flannel. Hii ni mojawapo ya CNI za gharama nafuu zaidi. Na ni sambamba na aina mbalimbali za usanifu (amd64, mkono, arm64, nk). Kwa kuongeza, hii ni moja ya mbili (nyingine ni Cilium) CNI ambayo inaweza kuamua moja kwa moja MTU, kwa hivyo huna kusanidi chochote. Kube-router pia inafaa, lakini sio kawaida na utahitaji kusanidi MTU kwa mikono.
- Ikiwa inahitajika encrypt mtandao kwa usalama, chukua WeaveNet. Usisahau kutaja ukubwa wa MTU ikiwa unatumia fremu za jumbo, na uwashe usimbaji fiche kwa kubainisha nenosiri kupitia kitofauti cha mazingira. Lakini ni bora kusahau juu ya utendaji - hiyo ni gharama ya usimbuaji.
- Kwa matumizi ya kawaida ΡΠΎΠ²Π΅ΡΡΡ Calico. CNI hii inatumika sana katika zana mbalimbali za kupeleka Kubernetes (Kops, Kubespray, Rancher, nk.). Kama ilivyo kwa WeaveNet, hakikisha kuwa umesanidi MTU katika ConfigMap ikiwa unatumia fremu kubwa. Ni chombo chenye kazi nyingi ambacho ni bora katika suala la matumizi ya rasilimali, utendaji na usalama.
Na hatimaye, nakushauri ufuate maendeleo Kilio. CNI hii ina timu inayofanya kazi sana ambayo inafanya kazi sana kwenye bidhaa zao (vipengele, akiba ya rasilimali, utendaji, usalama, kuunganisha...) na wana mipango ya kuvutia sana.
Mchoro unaoonekana wa uteuzi wa CNI
Chanzo: mapenzi.com