{"id":34366,"date":"2019-10-31T21:57:56","date_gmt":"2019-10-31T18:57:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd\/"},"modified":"2019-10-31T21:57:56","modified_gmt":"2019-10-31T18:57:56","slug":"benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmarkul consumului de CPU pentru Istio \u0219i Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmarkul<\/p>\n

<\/p>\n

Introducere<\/h2>\n

<\/p>\n

Noi, la Shopify<\/a><\/noindex> am \u00eenceput s\u0103 desf\u0103\u0219ur\u0103m Istio ca service mesh. \u00cen principiu, totul este \u00een regul\u0103, cu o singur\u0103 excep\u021bie: este scump<\/strong>.<\/p>\n

<\/p>\n

\u00cen benchmark-urile publicate<\/a><\/noindex> pentru Istio se men\u021bioneaz\u0103:<\/p>\n

<\/p>\n

Cu Istio 1.1, proxy-ul consum\u0103 aproximativ 0,6 vCPU (nuclee virtuale) la 1000 de cereri pe secund\u0103.<\/p><\/blockquote>\n

Pentru prima zon\u0103 din service mesh (c\u00e2te 2 proxy de fiecare parte a conexiunii), avem nevoie de 1200 de nuclee doar pentru proxy, calcul\u00e2nd pentru un milion de cereri pe secund\u0103. Conform calculatorului de costuri de la Google, costul este de aproximativ $40\/lun\u0103\/nucleu pentru configura\u021bia n1-standard-64<\/code>, adic\u0103 aceast\u0103 zon\u0103 ne va costa mai mult de 50.000 de dolari pe lun\u0103 pentru 1 milion de cereri pe secund\u0103.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) a comparat vizibil<\/a><\/noindex> laten\u021bele service mesh din anul trecut \u0219i a promis acela\u0219i lucru pentru memorie \u0219i procesor, dar nu a reu\u0219it:<\/p>\n

<\/p>\n

Se pare c\u0103 values-istio-test.yaml va cre\u0219te semnificativ cererile c\u0103tre procesor. Dac\u0103 am calculat corect, sunt necesare aproximativ 24 de nuclee de procesor pentru panoul de control \u0219i 0,5 CPU pentru fiecare proxy. Nu am asemenea resurse. Voi repeta testele c\u00e2nd mi se vor aloca mai multe resurse.<\/p><\/blockquote>\n

Am vrut s\u0103 m\u0103 asigur personal c\u00e2t de asem\u0103n\u0103toare sunt performan\u021bele Istio cu alt service mesh cu cod deschis: Linkerd<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Instalarea service mesh<\/h3>\n

<\/p>\n

Mai \u00eent\u00e2i am instalat \u00een cluster SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstalling supergloo version 0.3.12\nusing chart uri https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources created\nserviceaccount\/supergloo created\nserviceaccount\/discovery created\nserviceaccount\/mesh-discovery created\nclusterrole.rbac.authorization.k8s.io\/discovery created\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery created\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding created\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding created\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding created\ndeployment.extensions\/supergloo created\ndeployment.extensions\/discovery created\ndeployment.extensions\/mesh-discovery created\ninstall successful!<\/code><\/pre>\n
<\/p>\n
Am folosit SuperGloo pentru c\u0103 simplific\u0103 semnificativ ini\u021bializarea service mesh. Pratic, nu a trebuit s\u0103 fac mare lucru. \u00cen produc\u021bie, nu folosim SuperGloo, dar pentru o astfel de sarcin\u0103 este perfect. A trebuit s\u0103 aplic literalmente doar c\u00e2teva comenzi pentru fiecare service mesh. Am folosit dou\u0103 clustere pentru izolare \u2014 c\u00e2te unul pentru Istio \u0219i Linkerd.<\/p>\n
<\/p>\n
Experimentul a fost realizat pe Google Kubernetes Engine. Am folosit Kubernetes 1.12.7-gke.7<\/code> \u0219i un pool de noduri n1-standard-4<\/code> cu scalare automat\u0103 a nodurilor (minimum 4, maximum 16).<\/p>\n
<\/p>\n
Apoi am instalat ambele service mesh din linia de comand\u0103.<\/p>\n
<\/p>\n
Mai \u00eent\u00e2i Linkerd:<\/p>\n
<\/p>\n
$ supergloo install linkerd --name linkerd\n+---------+--------------+---------+---------------------------+\n| INSTALL |     TYPE     | STATUS  |          DETAILS          |\n+---------+--------------+---------+---------------------------+\n| linkerd | Linkerd Mesh | Pending | enabled: true             |\n|         |              |         | version: stable-2.3.0     |\n|         |              |         | namespace: linkerd        |\n|         |              |         | mtls enabled: true        |\n|         |              |         | auto inject enabled: true |\n+---------+--------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Apoi Istio:<\/p>\n
<\/p>\n
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true\n+---------+------------+---------+---------------------------+\n| INSTALL |    TYPE    | STATUS  |          DETAILS          |\n+---------+------------+---------+---------------------------+\n| istio   | Istio Mesh | Pending | enabled: true             |\n|         |            |         | version: 1.0.6            |\n|         |            |         | namespace: istio-system   |\n|         |            |         | mtls enabled: true        |\n|         |            |         | auto inject enabled: true |\n|         |            |         | grafana enabled: true     |\n|         |            |         | prometheus enabled: true  |\n|         |            |         | jaeger enabled: true      |\n+---------+------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Crash-loop a durat c\u00e2teva minute, dup\u0103 care panourile de control s-au stabilizat.<\/p>\n
<\/p>\n
(Not\u0103. SuperGloo suport\u0103 momentan doar Istio 1.0.x. Am repetat experimentul cu Istio 1.1.3, dar nu am observat nicio diferen\u021b\u0103 semnificativ\u0103.)<\/em><\/p>\n
<\/p>\n
Configurarea inject\u0103rii automate Istio<\/h3>\n
<\/p>\n
Pentru ca Istio s\u0103 instaleze sidecar-ul Envoy, folosim injectorul de sidecar \u2014 MutatingAdmissionWebhook<\/code>. Nu vom discuta despre el \u00een acest articol. Voi men\u021biona doar c\u0103 acesta este un controller care supravegheaz\u0103 accesul tuturor noilor pod-uri \u0219i adaug\u0103 dinamic sidecar-uri \u0219i initContainer, care se ocup\u0103 de sarcini iptables<\/code>.<\/p>\n
<\/p>\n
Noi, la Shopify, am scris propriul nostru controller de acces pentru injectarea sidecar-urilor, dar \u00een acest benchmark am utilizat controllerul livrat cu Istio. Controllerul implicit injecteaz\u0103 sidecar-uri atunci c\u00e2nd exist\u0103 un label \u00een spa\u021biul de nume istio-injection: enabled<\/code>:<\/p>\n
<\/p>\n
$ kubectl label namespace irs-client-dev istio-injection=enabled\nnamespace\/irs-client-dev labeled\n\n$ kubectl label namespace irs-server-dev istio-injection=enabled\nnamespace\/irs-server-dev labeled<\/code><\/pre>\n
<\/p>\n
Configurarea inject\u0103rii automate Linkerd<\/h3>\n
<\/p>\n
Pentru a configura injectarea sidecar-urilor Linkerd, folosim adnot\u0103ri (le-am ad\u0103ugat manual prin kubectl edit<\/code>):<\/p>\n
<\/p>\n
metadata:\n  annotations:\n    linkerd.io\/inject: enabled<\/code><\/pre>\n
<\/p>\n
$ k edit ns irs-server-dev \nnamespace\/irs-server-dev edited\n\n$ k get ns irs-server-dev -o yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  annotations:\n    linkerd.io\/inject: enabled\n  name: irs-server-dev\nspec:\n  finalizers:\n  - kubernetes\nstatus:\n  phase: Active<\/code><\/pre>\n
<\/p>\n
Simulator de rezilien\u021b\u0103 Istio<\/h3>\n
<\/p>\n
Am creat un simulator de rezilien\u021b\u0103 Istio pentru a experimenta cu traficul unic pentru Shopify. Aveam nevoie de un instrument pentru a construi o topologie arbitrar\u0103 care s\u0103 reprezinte o parte specific\u0103 a grafului serviciului nostru, cu configurare dinamic\u0103 pentru a modela sarcini de lucru specifice.<\/p>\n
<\/p>\n
Infrastructura Shopify suport\u0103 o \u00eenc\u0103rcare mare \u00een timpul v\u00e2nz\u0103rilor flash. \u00cen acest timp, Shopify recomand\u0103 comercian\u021bilor s\u0103 organizeze mai frecvent astfel de v\u00e2nz\u0103ri<\/a><\/noindex>. Clien\u021bii mari uneori anun\u021b\u0103 o v\u00e2nzare flash planificat\u0103. Al\u021bii le desf\u0103\u0219oar\u0103 nea\u0219teptat, \u00een orice moment al zilei \u0219i al nop\u021bii.<\/p>\n
<\/p>\n
Am dorit ca simulatorul nostru de rezilien\u021b\u0103 s\u0103 modeleze fluxuri de lucru care corespund topologiilor \u0219i sarcinilor de lucru care au dus la supra\u00eenc\u0103rcarea infrastructurii Shopify \u00een trecut. Scopul principal al utiliz\u0103rii service mesh este c\u0103 avem nevoie de fiabilitate \u0219i rezilien\u021b\u0103 la nivel de re\u021bea, iar este important pentru noi ca service mesh s\u0103 fac\u0103 fa\u021b\u0103 eficient sarcinilor care anterior perturbau func\u021bionarea serviciilor.<\/p>\n
<\/p>\n
\u00cen centrul simulatorului de rezilien\u021b\u0103 se afl\u0103 un nod de lucru care ac\u021bioneaz\u0103 ca un nod \u00een service mesh. Nodul de lucru poate fi configurat static la pornire sau dinamic prin REST API. Folosim configurarea dinamic\u0103 a nodurilor de lucru pentru a crea fluxuri de lucru sub form\u0103 de teste regresive.<\/p>\n
<\/p>\n
Iat\u0103 un exemplu de acest proces:<\/p>\n
<\/p>\n