CPU սպառման չափանիշ Istio-ի և Linkerd-ի համար

Ներածություն

Մենք ներս ենք Shopify սկսեց տեղակայել Istio-ն որպես սպասարկման ցանց: Սկզբունքորեն ամեն ինչ լավ է, բացառությամբ մի բանի. դա թանկ է.

В հրապարակված հենանիշները Իստիոյի համար ասում է.

Istio 1.1-ի դեպքում վստահված անձը սպառում է մոտավորապես 0,6 vCPU (վիրտուալ միջուկներ) վայրկյանում 1000 հարցումների համար:

Ծառայությունների ցանցի առաջին շրջանի համար (միացման յուրաքանչյուր կողմում 2 պրոքսի), մենք կունենանք 1200 միջուկ միայն վստահված անձի համար, վայրկյանում մեկ միլիոն հարցումների արագությամբ: Ըստ Google-ի ծախսերի հաշվիչի, կազմաձևման համար այն կազմում է մոտավորապես $40/ամսական/միջուկ n1-standard-64, այսինքն՝ միայն այս տարածաշրջանը մեզ վրա ամսական ավելի քան 50 հազար դոլար կարժենա վայրկյանում 1 միլիոն խնդրանքի համար։

Իվան Սիմ (Իվան Սիմ) տեսողական համեմատ Անցյալ տարի սպասարկման ցանցը հետաձգվեց և նույնը խոստացավ հիշողության և պրոցեսորի համար, բայց դա չստացվեց.

Ըստ երևույթին, values-istio-test.yaml-ը լրջորեն կբարձրացնի պրոցեսորի հարցումները: Եթե ​​ես ճիշտ եմ արել իմ հաշվարկները, ապա ձեզ անհրաժեշտ է մոտավորապես 24 պրոցեսորի միջուկ կառավարման վահանակի համար և 0,5 պրոցեսոր յուրաքանչյուր վստահված անձի համար: Ես այդքան էլ չունեմ: Ես կկրկնեմ թեստերը, երբ ինձ ավելի շատ ռեսուրսներ հատկացնեն։

Ես ուզում էի ինքս տեսնել, թե որքանով է նման Istio-ի կատարումը մեկ այլ բաց կոդով ծառայության ցանցին. Linkerd.

Սպասարկման ցանցի տեղադրում

Առաջին հերթին ես այն տեղադրեցի կլաստերի մեջ SuperGloo:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

Ես օգտագործել եմ SuperGloo-ն, քանի որ այն շատ ավելի հեշտ է դարձնում ծառայության ցանցի բեռնաթափումը: Ես ստիպված չէի շատ բան անել: Մենք SuperGloo-ն չենք օգտագործում արտադրության մեջ, բայց այն իդեալական է նման առաջադրանքի համար: Ես պետք է օգտագործեի բառացիորեն մի քանի հրաման յուրաքանչյուր ծառայության ցանցի համար: Մեկուսացման համար ես օգտագործեցի երկու կլաստեր՝ մեկական Istio-ի և Linkerd-ի համար:

Փորձն անցկացվել է Google Kubernetes Engine-ում։ Ես օգտագործել եմ Kubernetes-ը 1.12.7-gke.7 և հանգույցների լողավազան n1-standard-4 հանգույցների ավտոմատ մասշտաբով (նվազագույնը 4, առավելագույնը 16):

Այնուհետև ես տեղադրեցի երկու սպասարկման ցանցերը հրամանի տողից:

Առաջին հղում.

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

Այնուհետև Իստիո.

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

Crash-loop-ը տևեց մի քանի րոպե, այնուհետև կառավարման վահանակները կայունացան:

(Նշում. SuperGloo-ն առայժմ աջակցում է միայն Istio 1.0.x-ին: Ես կրկնեցի փորձը Istio 1.1.3-ի հետ, բայց որևէ նկատելի տարբերություն չնկատեցի):

Istio ավտոմատ տեղակայման կարգավորում

Որպեսզի Istio-ն տեղադրի Envoy-ի կողային կառքը, մենք օգտագործում ենք կողային կառքի ներարկիչը − MutatingAdmissionWebhook. Այս հոդվածում մենք չենք խոսի դրա մասին: Թույլ տվեք միայն ասել, որ սա վերահսկիչ է, որը վերահսկում է բոլոր նոր բլոկների հասանելիությունը և դինամիկ կերպով ավելացնում է կողային սյուն և initContainer, որը պատասխանատու է առաջադրանքների համար: iptables.

Մենք Shopify-ում գրեցինք մեր սեփական մուտքի կարգավորիչը՝ կողային վահանակներ իրականացնելու համար, բայց այս հենանիշի համար ես օգտագործեցի վերահսկիչը, որը գալիս է Istio-ի հետ: Կարգավորիչը լռելյայնորեն ներարկում է կողային սայլեր, երբ անունների տարածքում դյուրանցում կա istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

Linkerd-ի ավտոմատ տեղակայման կարգավորում

Linkerd sidecar embedding-ը կարգավորելու համար մենք օգտագործում ենք ծանոթագրություններ (ես դրանք ավելացրել եմ ձեռքով kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Istio սխալների հանդուրժողականության սիմուլյատոր

Մենք կառուցեցինք սխալների հանդուրժողականության սիմուլյատոր, որը կոչվում է Istio, որպեսզի փորձարկենք երթևեկությունը, որը յուրահատուկ է Shopify-ին: Մեզ անհրաժեշտ էր գործիք՝ հատուկ տոպոլոգիա ստեղծելու համար, որը կներկայացնի մեր ծառայության գրաֆիկի որոշակի մասը՝ դինամիկ կերպով կազմաձևված՝ որոշակի աշխատանքային բեռներ մոդելավորելու համար:

Shopify-ի ենթակառուցվածքը մեծ ծանրաբեռնվածության տակ է ֆլեշ վաճառքի ժամանակ: Միևնույն ժամանակ, Shopify խորհուրդ է տալիս վաճառողներին ավելի հաճախ անցկացնել նման վաճառք. Խոշոր հաճախորդները երբեմն զգուշացնում են պլանավորված ֆլեշ վաճառքի մասին: Մյուսները դրանք մեզ համար անսպասելիորեն անցկացնում են օրվա կամ գիշերվա ցանկացած ժամի։

Մենք ցանկանում էինք, որ մեր ճկունության սիմուլյատորը մոդելավորի աշխատանքային հոսքեր, որոնք համապատասխանում են տոպոլոգիաներին և աշխատանքային ծանրաբեռնվածությանը, որոնք նախկինում ծանրաբեռնել են Shopify-ի ենթակառուցվածքը: Սպասարկման ցանց օգտագործելու հիմնական նպատակն այն է, որ մեզ անհրաժեշտ է հուսալիություն և անսարքության հանդուրժողականություն ցանցի մակարդակում, և մեզ համար կարևոր է, որ սպասարկման ցանցն արդյունավետորեն դիմագրավի այն բեռներին, որոնք նախկինում խաթարում էին ծառայությունները:

Սխալների հանդուրժողականության սիմուլյատորի հիմքում աշխատող հանգույցն է, որը գործում է որպես սպասարկման ցանցային հանգույց: Աշխատող հանգույցը կարող է կարգավորվել ստատիկ կերպով գործարկման ժամանակ կամ դինամիկ կերպով REST API-ի միջոցով: Մենք օգտագործում ենք աշխատանքային հանգույցների դինամիկ կոնֆիգուրացիա՝ ռեգրեսիոն թեստերի տեսքով աշխատանքային հոսքեր ստեղծելու համար։

Ահա այսպիսի գործընթացի օրինակ.

• Մենք գործարկում ենք 10 սերվեր որպես bar ծառայություն, որը պատասխան է տալիս 200/OK 100 ms-ից հետո:
• Մենք գործարկում ենք 10 հաճախորդ՝ յուրաքանչյուրը վայրկյանում 100 հարցում է ուղարկում bar.
• Ամեն 10 վայրկյանը մեկ մենք հեռացնում ենք 1 սերվերի և մոնիտորինգի սխալ 5xx հաճախորդի վրա:

Աշխատանքային հոսքի վերջում մենք ուսումնասիրում ենք տեղեկամատյանները և չափումները և ստուգում, թե արդյոք թեստն անցել է: Այս կերպ մենք սովորում ենք մեր ծառայության ցանցի աշխատանքի մասին և կատարում ռեգրեսիայի թեստ՝ սխալների հանդուրժողականության վերաբերյալ մեր ենթադրությունները ստուգելու համար:

(Նշում. Մենք մտածում ենք Istio սխալների հանդուրժողականության սիմուլյատորի բաց աղբյուրի մասին, բայց դեռ պատրաստ չենք դա անել:)

Istio անսարքության հանդուրժողականության սիմուլյատոր ծառայության ցանցի հենանիշի համար

Մենք ստեղծեցինք սիմուլյատորի մի քանի աշխատանքային հանգույցներ.

• irs-client-loadgen3 կրկնօրինակներ, որոնք վայրկյանում 100 հարցում են ուղարկում irs-client.
• irs-client3 կրկնօրինակներ, որոնք ստանում են հարցումը, սպասեք 100 ms և ուղարկեք հարցումը irs-server.
• irs-server3 կրկնօրինակներ, որոնք վերադառնում են 200/OK 100 ms-ից հետո:

Այս կոնֆիգուրացիայի միջոցով մենք կարող ենք չափել կայուն երթևեկության հոսքը 9 վերջնակետերի միջև: Կողային մեքենաները ներսում irs-client-loadgen и irs-server ստանալ 100 հարցում վայրկյանում, և irs-client — 200 (մուտքային և ելքային):

Մենք հետևում ենք ռեսուրսների օգտագործմանը DataDogքանի որ մենք Պրոմեթևսի կլաստեր չունենք:

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

Կառավարման վահանակներ

Նախ, մենք ուսումնասիրեցինք պրոցեսորի սպառումը:

Linkerd կառավարման վահանակ ~22 միլիկոր

Istio կառավարման վահանակ՝ ~ 750 միլիկոր

Istio կառավարման վահանակն օգտագործում է մոտավորապես 35 անգամ ավելի շատ CPU ռեսուրսներքան Linkerd-ը: Իհարկե, ամեն ինչ տեղադրված է լռելյայն, և istio-telemetry-ն այստեղ շատ պրոցեսորային ռեսուրսներ է սպառում (այն կարելի է անջատել՝ անջատելով որոշ գործառույթներ): Եթե ​​մենք հանենք այս բաղադրիչը, մենք դեռ ստանում ենք ավելի քան 100 միլիկոր, այսինքն 4 անգամ ավելիքան Linkerd-ը:

Sidecar վստահված անձ

Այնուհետև մենք փորձարկեցինք վստահված անձի օգտագործումը: Պետք է լինի գծային կապ հարցումների քանակի հետ, բայց յուրաքանչյուր կողային սայլի համար կա որոշակի վերին ծախս, որն ազդում է կորի վրա:

Linkerd՝ ~ 100 միլիկոր irs-client-ի համար, ~50 millicores irs-client-loadgen-ի համար

Արդյունքները տրամաբանական են թվում, քանի որ հաճախորդի վստահված անձը ստանում է երկու անգամ ավելի շատ տրաֆիկ, քան loadgen պրոքսիը. loadgen-ից յուրաքանչյուր ելքային հարցման համար հաճախորդն ունի մեկ մուտքային և մեկ ելքային:

Istio/Envoy՝ ~ 155 միլիկոր irs-client-ի համար, ~75 millicores irs-client-loadgen-ի համար

Մենք տեսնում ենք նմանատիպ արդյունքներ Istio կողային մեքենաների համար:

Բայց ընդհանուր առմամբ, Istio/Envoy վստահված անձինք սպառում են մոտավորապես 50% ավելի CPU ռեսուրսներքան Linkerd-ը:

Մենք տեսնում ենք նույն սխեման սերվերի կողմից.

Linkerd՝ ~50 millicore irs-server-ի համար

Istio/Envoy՝ ~80 millicore irs-server-ի համար

Սերվերի կողմից կողային մեքենան Istio/Envoy սպառում է մոտավորապես 60% ավելի CPU ռեսուրսներքան Linkerd-ը:

Ամփոփում

Istio Envoy վստահված անձը սպառում է 50+% ավելի շատ պրոցեսոր, քան Linkerd-ը մեր մոդելավորված աշխատանքային ծանրաբեռնվածության դեպքում: Linkerd կառավարման վահանակը շատ ավելի քիչ ռեսուրսներ է սպառում, քան Istio-ն, հատկապես հիմնական բաղադրիչների համար:

Մենք դեռ մտածում ենք, թե ինչպես նվազեցնել այդ ծախսերը։ Եթե ​​ունեք գաղափարներ, խնդրում ենք կիսվել:

Source: www.habr.com