Kubernetes Network Plugin (CNI) Հենանիշի արդյունքները ավելի քան 10 Գբիտ/վրկ ցանց (Թարմացվել է՝ 2019 թվականի ապրիլ)

Սա իմ թարմացումն է նախորդ չափանիշը, որն այժմ աշխատում է Kubernetes 1.14-ով՝ 2019 թվականի ապրիլի վերջին CNI տարբերակով:

Նախ ուզում եմ շնորհակալություն հայտնել «Կիլիումի» թիմին. տղաներն ինձ օգնեցին ստուգել և ուղղել չափումների մոնիտորինգի սկրիպտները:

Ինչ է փոխվել 2018 թվականի նոյեմբերից

Ահա թե ինչ է փոխվել դրանից հետո (եթե ձեզ հետաքրքրում է).

Flannel-ը մնում է ամենաարագ և ամենապարզ CNI ինտերֆեյսը, բայց դեռ չի աջակցում ցանցային քաղաքականությանը և գաղտնագրմանը:

Romana-ն այլևս չի աջակցվում, ուստի մենք այն հանել ենք հենանիշից:

WeaveNet-ն այժմ աջակցում է Ingress-ի և Egress-ի ցանցային քաղաքականությանը: Բայց արտադրողականությունը նվազել է։

Calico-ում դուք դեռ պետք է ձեռքով կարգավորեք փաթեթի առավելագույն չափը (MTU) լավագույն կատարման համար: Calico-ն առաջարկում է CNI-ի տեղադրման երկու տարբերակ, այնպես որ կարող եք անել առանց առանձին ETCD պահեստի.

• վիճակի պահպանում Kubernetes API-ում որպես տվյալների պահեստ (կլաստերի չափը < 50 հանգույց);
• Պահպանելով վիճակը Kubernetes API-ում որպես տվյալների պահեստ՝ Typha պրոքսիով, որպեսզի բեռնաթափվի K8S API-ի վրա (կլաստերի չափը > 50 հանգույց):

Calico-ն հայտարարել է աջակցության մասին կիրառման մակարդակի քաղաքականություն Istio-ի վերևում՝ հավելվածի մակարդակի անվտանգության համար:

Cilium-ն այժմ աջակցում է կոդավորմանը: Cilium-ն ապահովում է գաղտնագրում IPSec թունելներով և առաջարկում է այլընտրանք գաղտնագրված WeaveNet ցանցին: Բայց WeaveNet-ն ավելի արագ է, քան Cilium-ը միացված գաղտնագրմամբ:

Cilium-ն այժմ ավելի հեշտ է տեղակայվել ներկառուցված ETCD օպերատորի շնորհիվ:

Cilium թիմը փորձել է կրճատել իր CNI-ի քաշը՝ նվազեցնելով հիշողության սպառումը և պրոցեսորի ծախսերը, սակայն նրա մրցակիցները դեռ ավելի թեթև են:

Հենանիշի համատեքստ

Հենանիշն աշխատում է երեք ոչ վիրտուալացված Supermicro սերվերների վրա՝ 10 Գբ Supermicro անջատիչով: Սերվերները միացված են անմիջապես անջատիչին պասիվ DAC SFP+ մալուխների միջոցով և կազմաձևված են նույն VLAN-ի վրա՝ Jumbo շրջանակներով (MTU 9000):

Kubernetes 1.14.0-ը տեղադրված է Ubuntu 18.04 LTS-ում Docker 18.09.2-ով (այս թողարկման մեջ Docker-ի կանխադրված տարբերակը):

Վերարտադրելիությունը բարելավելու համար մենք որոշեցինք միշտ կարգավորել վարպետը առաջին հանգույցի վրա, հենանիշի սերվերի մասը տեղադրել երկրորդ սերվերի վրա, իսկ հաճախորդի մասը՝ երրորդում: Դա անելու համար մենք օգտագործում ենք NodeSelector-ը Kubernetes-ի տեղակայումներում:

Մենք կնկարագրենք հենանիշի արդյունքները հետևյալ սանդղակով.

Հենանիշի համար CNI ընտրելը

Սա ուղենիշ է միայն CNI-ի համար բաժնի ցանկից kubeadm-ով մեկ գլխավոր կլաստերի ստեղծման մասին Տես պաշտոնական Kubernetes փաստաթղթերը: 9 CNI-ներից մենք կվերցնենք միայն 6-ը. մենք կբացառենք դրանք, որոնք դժվար է տեղադրել և/կամ չեն աշխատում առանց կազմաձևման՝ համաձայն փաստաթղթերի (Romana, Contiv-VPP և JuniperContrail/TungstenFabric):

Մենք համեմատելու ենք հետևյալ CNI-ները.

• Calico v3.6
• Canal v3.6 (ըստ էության, Flannel ցանցի համար + Calico որպես firewall)
• Կիլիում 1.4.2
• Ֆլանել 0.11.0
• Kube-երթուղիչ 0.2.5
• WeaveNet 2.5.1

Տեղակայում

Որքան հեշտ լինի CNI-ի տեղադրումը, այնքան ավելի լավ կլինի մեր առաջին տպավորությունը: Հենանիշի բոլոր CNI-ները շատ հեշտ են տեղադրվում (մեկ կամ երկու հրամաններով):

Ինչպես ասացինք, սերվերները և անջատիչը կազմաձևված են միացված Jumbo շրջանակներով (մենք MTU-ն դրեցինք 9000): Մենք ուրախ կլինենք, եթե CNI-ն ավտոմատ կերպով որոշի MTU-ն՝ հիմնվելով ադապտերների կոնֆիգուրացիայի վրա: Սակայն դա հաջողվեց միայն Կիլիումին և Ֆլանելին։ Մնացած CNI-ները հարցումներ ունեն GitHub-ում՝ ավելացնելու ավտոմատ MTU հայտնաբերում, բայց մենք այն ձեռքով կկարգավորենք՝ փոխելով ConfigMap-ը Calico-ի, Canal-ի և Kube-երթուղիչի համար, կամ փոխանցելով միջավայրի փոփոխական WeaveNet-ի համար:

Ո՞րն է սխալ MTU-ի խնդիրը: Այս դիագրամը ցույց է տալիս WeaveNet-ի տարբերությունը լռելյայն MTU-ի և Jumbo շրջանակների միացվածությամբ.

Ինչպե՞ս է MTU-ն ազդում թողունակության վրա:

Մենք տեսանք, թե որքան կարևոր է MTU-ն կատարման համար, հիմա տեսնենք, թե ինչպես են մեր CNI-ները ավտոմատ կերպով որոշում դա.

CNI-ն ավտոմատ կերպով հայտնաբերում է MTU-ն

Գրաֆիկը ցույց է տալիս, որ օպտիմալ կատարման համար անհրաժեշտ է կարգավորել MTU-ն Calico-ի, Canal-ի, Kube-երթուղիչի և WeaveNet-ի համար: Cilium-ը և Flannel-ը կարողացան ինքնուրույն որոշել MTU-ն առանց որևէ կարգավորումների:

Безопасность

Մենք կհամեմատենք CNI-ի անվտանգությունը երկու ասպեկտով՝ փոխանցված տվյալների գաղտնագրման կարողություն և Kubernetes ցանցային քաղաքականության իրականացում (հիմնված իրական թեստերի վրա, ոչ թե փաստաթղթերի):

Միայն երկու CNI գաղտնագրում են տվյալները՝ Cilium և WeaveNet: Կոդավորումը WeaveNet միացված է գաղտնագրման գաղտնաբառը որպես CNI միջավայրի փոփոխական սահմանելով: IN փաստաթղթավորում WeaveNet-ը նկարագրում է այն բարդ ձևով, բայց ամեն ինչ արվում է պարզ: Կոդավորումը Ցիլիում կազմաձևված է հրամաններով, Kubernetes-ի գաղտնիքների ստեղծմամբ և daemonSet-ի փոփոխությամբ (մի փոքր ավելի բարդ, քան WeaveNet-ում, բայց Cilium-ն ունի քայլ առ քայլ հրահանգներ).

Ինչ վերաբերում է ցանցային քաղաքականության իրականացմանը, ապա հաջողվել է Calico, Canal, Cilium և WeaveNet, որում կարող եք կարգավորել Ingress և Egress կանոնները: Համար Kube-երթուղիչ կան կանոններ միայն Ingress-ի համար, և Ֆլանել Ցանցային քաղաքականություն ընդհանրապես չկա:

Ահա ընդհանուր արդյունքները.

Անվտանգության կատարողականի հենանիշի արդյունքները

Արտադրողականություն

Այս հենանիշը ցույց է տալիս միջին թողունակությունը յուրաքանչյուր թեստի առնվազն երեք գործարկման ընթացքում: Մենք փորձարկում ենք TCP-ի և UDP-ի կատարումը (օգտագործելով iperf3), իրական հավելվածների, ինչպիսիք են HTTP-ը (Nginx-ով և curl-ով) կամ FTP-ն (vsftpd-ով և curl-ով) և վերջապես հավելվածի աշխատանքը՝ օգտագործելով SCP-ի վրա հիմնված գաղտնագրումը (օգտագործելով հաճախորդ և սերվեր OpenSSH):

Բոլոր թեստերի համար մենք կատարեցինք մերկ մետաղական հենանիշ (կանաչ գիծ)՝ համեմատելու CNI-ի կատարումը հայրենի ցանցի կատարողականի հետ: Այստեղ մենք օգտագործում ենք նույն սանդղակը, բայց գունավոր.

• Դեղին = շատ լավ
• Նարնջագույն = լավ
• Կապույտ = այսքանը
• Կարմիր = վատ

Մենք չենք վերցնի սխալ կազմաձևված CNI-ներ և ցույց կտանք արդյունքները միայն ճիշտ MTU-ով CNI-ների համար: (Նշում. Cilium-ը ճիշտ չի հաշվարկում MTU-ն, եթե դուք միացնում եք գաղտնագրումը, այնպես որ դուք ստիպված կլինեք ձեռքով նվազեցնել MTU-ն մինչև 8900 1.4 տարբերակում: Հաջորդ տարբերակը՝ 1.5-ը, դա անում է ավտոմատ կերպով:)

Ահա արդյունքները.

TCP-ի կատարումը

Բոլոր CNI-ները լավ են հանդես եկել TCP-ի չափանիշով: Գաղտնագրմամբ CNI-ն շատ հետ է մնում, քանի որ կոդավորումը թանկ է:

UDP կատարումը

Այստեղ նույնպես բոլոր CNI-ները լավ են աշխատում: CNI-ն գաղտնագրմամբ ցույց տվեց գրեթե նույն արդյունքը։ Cilium-ը մի փոքր զիջում է մրցակիցներին, բայց դա մերկ մետաղի ընդամենը 2,3%-ն է, ուստի դա վատ արդյունք չէ: Մի մոռացեք, որ միայն Cilium-ը և Flannel-ը իրենք են ճիշտ որոշել MTU-ն, և սրանք իրենց արդյունքներն են՝ առանց որևէ լրացուցիչ կոնֆիգուրացիայի:

Ինչ վերաբերում է իրական հավելվածին: Ինչպես տեսնում եք, HTTP-ի ընդհանուր կատարումը մի փոքր ավելի ցածր է, քան TCP-ի համար: Նույնիսկ եթե դուք օգտագործում եք HTTP TCP-ի հետ, մենք կարգավորել ենք iperf3-ը TCP-ի չափանիշում, որպեսզի խուսափենք դանդաղ մեկնարկից, որը կազդի HTTP հենանիշի վրա: Այստեղ բոլորը լավ աշխատանք են կատարել: Kube-router-ը ակնհայտ առավելություն ունի, սակայն WeaveNet-ը լավ չի գործել՝ մոտ 20%-ով ավելի վատ, քան մերկ մետաղը: Cilium-ը և գաղտնագրմամբ WeaveNet-ը իսկապես տխուր տեսք ունեն:

FTP-ի՝ TCP-ի վրա հիմնված մեկ այլ արձանագրության դեպքում, արդյունքները տարբերվում են: Flannel-ը և Kube-router-ը կատարում են աշխատանքը, սակայն Calico-ն, Canal-ը և Cilium-ը մի փոքր հետ են մնում և մոտ 10%-ով ավելի դանդաղ են, քան մերկ մետաղը: WeaveNet-ը զիջում է 17%-ով, սակայն կոդավորված WeaveNet-ը 40%-ով գերազանցում է կոդավորված Cilium-ին:

SCP-ով մենք կարող ենք անմիջապես տեսնել, թե որքան արժե մեզ SSH կոդավորումը: Գրեթե բոլոր CNI-ները լավ են աշխատում, բայց WeaveNet-ը կրկին հետ է մնում: Ծածկագրմամբ Cilium-ը և WeaveNet-ը, ակնկալվում է, որ ամենավատն են կրկնակի կոդավորման պատճառով (SSH + CNI):

Ահա ամփոփ աղյուսակը արդյունքներով.

Ռեսուրսների սպառում

Հիմա եկեք համեմատենք, թե ինչպես է CNI-ն սպառում ռեսուրսները մեծ բեռների տակ (TCP փոխանցման ժամանակ, 10 Գբիտ/վրկ): Կատարողական թեստերում մենք համեմատում ենք CNI-ն մերկ մետաղի հետ (կանաչ գիծ): Ռեսուրսների սպառման համար եկեք ցույց տանք մաքուր Kubernetes (մանուշակագույն գիծ) առանց CNI-ի և տեսնենք, թե որքան լրացուցիչ ռեսուրսներ է սպառում CNI-ն:

Սկսենք հիշողությունից։ Ահա հանգույցների RAM-ի միջին արժեքը (բացառությամբ բուֆերների և քեշի) փոխանցման ընթացքում ՄԲ-ով:

Հիշողության սպառում

Flannel-ը և Kube-router-ը ցույց են տվել գերազանց արդյունքներ՝ ընդամենը 50 ՄԲ: Calico-ն և Canal-ն ունեն 70-ական: WeaveNet-ը ակնհայտորեն ավելի շատ է սպառում, քան մյուսները՝ 130 ՄԲ, իսկ Cilium-ն օգտագործում է մինչև 400:
Հիմա եկեք ստուգենք պրոցեսորի ժամանակի սպառումը: Ուշագրավ էԴիագրամը ցույց է տալիս ոչ թե տոկոսներ, այլ ppm, այսինքն՝ 38 ppm «մերկ երկաթի» համար կազմում է 3,8%: Ահա արդյունքները.

CPU սպառումը

Calico-ն, Canal-ը, Flannel-ը և Kube-երթուղիչը շատ CPU-ի արդյունավետ են՝ ընդամենը 2%-ով ավելի, քան Kubernetes-ն առանց CNI-ի: WeaveNet-ը շատ հետ է մնում հավելյալ 5%-ով, որին հաջորդում է Cilium-ը՝ 7%:

Ահա ռեսուրսների սպառման ամփոփագիրը.

Արդյունքները

Աղյուսակ բոլոր արդյունքներով.

Ընդհանուր հենանիշի արդյունքներ

Ամփոփում

Վերջին մասում ես կհայտնեմ իմ սուբյեկտիվ կարծիքը արդյունքների վերաբերյալ։ Հիշեք, որ այս հենանիշը ստուգում է միայն մեկ կապի թողունակությունը շատ փոքր կլաստերի վրա (3 հանգույց): Այն չի տարածվում մեծ կլաստերների (<50 հանգույց) կամ զուգահեռ կապերի վրա։

Ես խորհուրդ եմ տալիս օգտագործել հետևյալ CNI-ները՝ կախված սցենարից.

• Ունեք ձեր կլաստերի մեջ քիչ ռեսուրսներով հանգույցներ (մի քանի ԳԲ օպերատիվ հիշողություն, մի քանի միջուկ) և ձեզ անվտանգության առանձնահատկություններ պետք չեն. ընտրեք Ֆլանել. Սա ամենաարդյունավետ CNI-ներից մեկն է: Եվ այն համատեղելի է տարբեր ճարտարապետությունների հետ (amd64, arm, arm64 և այլն): Բացի այդ, սա երկուսից մեկն է (մյուսը՝ Cilium) CNI-ն, որը կարող է ավտոմատ կերպով որոշել MTU-ն, այնպես որ դուք կարիք չունեք որևէ բան կարգավորելու: Kube-երթուղիչը նույնպես հարմար է, բայց այն այնքան էլ ստանդարտ չէ, և ձեզ հարկավոր է ձեռքով կարգավորել MTU-ն:
• Անհրաժեշտության դեպքում գաղտնագրել ցանցը անվտանգության համար վերցրեք WeaveNet. Մի մոռացեք նշել MTU չափը, եթե դուք օգտագործում եք jumbo շրջանակներ, և միացրեք կոդավորումը՝ նշելով գաղտնաբառ շրջակա միջավայրի փոփոխականի միջոցով: Բայց ավելի լավ է մոռանալ կատարողականի մասին, դա գաղտնագրման արժեքն է:
• Համար նորմալ օգտագործումը советую Calico- ն. Այս CNI-ն լայնորեն օգտագործվում է Kubernetes-ի տեղակայման տարբեր գործիքներում (Kops, Kubespray, Rancher և այլն): Ինչպես WeaveNet-ի դեպքում, համոզվեք, որ կարգավորեք MTU-ն ConfigMap-ում, եթե օգտագործում եք jumbo շրջանակներ: Այն բազմաֆունկցիոնալ գործիք է, որն արդյունավետ է ռեսուրսների սպառման, կատարողականի և անվտանգության տեսանկյունից:

Եվ վերջապես խորհուրդ եմ տալիս հետևել զարգացմանը Ցիլիում. Այս CNI-ն ունի շատ ակտիվ թիմ, որը շատ է աշխատում իր արտադրանքի վրա (հատկանիշներ, ռեսուրսների խնայողություն, կատարողականություն, անվտանգություն, կլաստերավորում...) և նրանք ունեն շատ հետաքրքիր ծրագրեր:

CNI ընտրության տեսողական դիագրամ

Source: www.habr.com