{"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\/sq\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmark i p\u00ebrdorimit t\u00eb CPU p\u00ebr Istio dhe Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmark<\/p>\n

<\/p>\n

Hyrje<\/h2>\n

<\/p>\n

Ne n\u00eb Shopify<\/a><\/noindex> kemi u angazhuam n\u00eb vendosjen e Istio si service mesh. N\u00eb thelb, gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull, p\u00ebrve\u00e7 nj\u00eb gj\u00ebje: \u00ebsht\u00eb e shtrenjt\u00eb<\/strong>.<\/p>\n

<\/p>\n

N\u00eb benchmark-\u00ebve t\u00eb publikuara<\/a><\/noindex> p\u00ebr Istio thuhet:<\/p>\n

<\/p>\n

Me Istio 1.1, proxy konsumon rreth 0.6 vCPU (n\u00eb b\u00ebrtham\u00eb virtuale) p\u00ebr 1000 k\u00ebrkesa p\u00ebr sekond\u00eb.<\/p><\/blockquote>\n

P\u00ebr rajonin e par\u00eb n\u00eb service mesh (me 2 proxy n\u00eb \u00e7do an\u00eb t\u00eb lidhjes) do t\u00eb kemi 1200 b\u00ebrthama vet\u00ebm p\u00ebr proxy, duke llogaritur nj\u00eb milion k\u00ebrkesa p\u00ebr sekond\u00eb. Sipas kalkulatorit t\u00eb kostos nga Google, del rreth $40\/muaj\/b\u00ebrtham\u00eb p\u00ebr konfigurimin n1-standard-64<\/code>, pra ky rajon do t\u00eb na kushtoj\u00eb m\u00eb shum\u00eb se 50 mij\u00eb dollar\u00eb n\u00eb muaj p\u00ebr 1 milion k\u00ebrkesa p\u00ebr sekond\u00eb.<\/p>\n

<\/p>\n

Aiven Sim (Ivan Sim<\/a><\/noindex>) ) tregoi qart\u00eb<\/a><\/noindex> ndalimet e service mesh vitin e kaluar dhe premtoi t\u00eb nj\u00ebjt\u00ebn gj\u00eb p\u00ebr kujtes\u00ebn dhe procesorin, por nuk ia doli:<\/p>\n

<\/p>\n

Duket se values-istio-test.yaml do t\u00eb rris\u00eb ndjesh\u00ebm k\u00ebrkesat p\u00ebr procesor. N\u00ebse e kam llogaritur sakt\u00eb, nevojiten rreth 24 b\u00ebrthama p\u00ebr procesorin p\u00ebr panelin e kontrollit dhe 0.5 CPU p\u00ebr \u00e7do proxy. Nuk kam aq. Do t\u00eb p\u00ebrs\u00ebris testet kur t\u00eb m\u00eb jepen m\u00eb shum\u00eb burime.<\/p><\/blockquote>\n

D\u00ebshiroja t\u00eb sigurohesha vet\u00eb, sa t\u00eb ngjashme jan\u00eb treguesit e Istio me nj\u00eb service mesh me kod t\u00eb hapur tjet\u00ebr: Linkerd<\/a><\/noindex>.<\/p>\n

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

Instalimi i service mesh<\/h3>\n

<\/p>\n

E para q\u00eb b\u00ebra ishte t\u00eb instaloja n\u00eb klastri 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
P\u00ebrdora SuperGloo sepse ndihmon shum\u00eb n\u00eb ngarkimin fillestar t\u00eb service mesh. M'u desh thuajse t\u00eb mos b\u00ebja asgj\u00eb. N\u00eb prodhim nuk p\u00ebrdorim SuperGloo, por p\u00ebr nj\u00eb detyr\u00eb t\u00eb till\u00eb \u00ebsht\u00eb perfekt. M\u00eb duhej t\u00eb aplikoja vet\u00ebm disa komanda p\u00ebr \u00e7do service mesh. P\u00ebrdora dy klaster\u00eb p\u00ebr izolim \u2014 nj\u00eb p\u00ebr Istio dhe nj\u00eb p\u00ebr Linkerd.<\/p>\n
<\/p>\n
Eksperimenti u zhvillua n\u00eb Google Kubernetes Engine. P\u00ebrdora Kubernetes 1.12.7-gke.7<\/code> dhe grupin e nod\u00ebve n1-standard-4<\/code> me shkall\u00ebzim automatik t\u00eb nod\u00ebve (minimum 4, maksimum 16).<\/p>\n
<\/p>\n
Pastaj instalova t\u00eb dy service mesh nga linja e komand\u00ebs.<\/p>\n
<\/p>\n
Fillimisht 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
Pastaj 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 zgjati disa minuta, dhe pastaj panelat kontrolli u stabilizuan.<\/p>\n
<\/p>\n
(Sh\u00ebnim. SuperGloo p\u00ebr momentin mb\u00ebshtet vet\u00ebm Istio 1.0.x. E p\u00ebrs\u00ebrita eksperimentin me Istio 1.1.3, por nuk vura re ndonj\u00eb ndryshim t\u00eb duksh\u00ebm.)<\/em><\/p>\n
<\/p>\n
Konfigurimi i injektimit automatik p\u00ebr Istio<\/h3>\n
<\/p>\n
P\u00ebr t\u00eb instaluar sidecar Envoy me Istio, p\u00ebrdorim injektor-in e sidecar-it \u2014 MutatingAdmissionWebhook<\/code>. Nuk do t\u00eb flasim p\u00ebr t\u00eb n\u00eb k\u00ebt\u00eb artikull. Thjesht do t\u00eb them se \u00ebsht\u00eb nj\u00eb kontrollues q\u00eb monitoron aksesin e t\u00eb gjith\u00eb pod\u2019\u00ebve t\u00eb rinj dhe dinamikisht shton sidecar dhe initContainer, i cili merret me detyrat iptables<\/code>.<\/p>\n
<\/p>\n
Ne n\u00eb Shopify shkruam kontrolluesin ton\u00eb p\u00ebr injektimin e sidecar-ve, por n\u00eb k\u00ebt\u00eb benchmark kam marr\u00eb kontrolluesin q\u00eb vjen me Istio. Kontrolluesi p\u00ebr default-in injekton sidecar-et kur ka nj\u00eb etiket\u00eb n\u00eb hap\u00ebsir\u00ebn e emrave 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
Konfigurimi i injektimit automatik p\u00ebr Linkerd<\/h3>\n
<\/p>\n
P\u00ebr t\u00eb konfiguruar injektimin e sidecar-ve t\u00eb Linkerd, p\u00ebrdorim annotacione (i kam shtuar ato manualisht p\u00ebrmes 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 i q\u00ebndrueshm\u00ebris\u00eb Istio<\/h3>\n
<\/p>\n
Kemi krijuar nj\u00eb simulator q\u00ebndrestariteti Istio p\u00ebr t\u00eb eksperimentuar me trafikun unik p\u00ebr Shopify. Na nevojitej nj\u00eb mjet p\u00ebr t\u00eb krijuar topologji t\u00eb rast\u00ebsishme q\u00eb do t\u00eb p\u00ebrfaq\u00ebsonte nj\u00eb pjes\u00eb t\u00eb caktuar t\u00eb grafit t\u00eb sh\u00ebrbimit ton\u00eb me konfigurim dinamik p\u00ebr modelimin e ngarkesave specifike t\u00eb pun\u00ebs.<\/p>\n
<\/p>\n
Infrastruktura e Shopify p\u00ebrjeton nj\u00eb ngarkes\u00eb t\u00eb madhe gjat\u00eb shitjeve flash. N\u00eb k\u00ebt\u00eb rast, Shopify i rekomandon tregtar\u00ebt t\u00eb b\u00ebjn\u00eb shpesh shitje t\u00eb tilla<\/a><\/noindex>. Klient\u00ebt e m\u00ebdhenj ndonj\u00ebher\u00eb paralajm\u00ebrojn\u00eb p\u00ebr nj\u00eb shitje flash t\u00eb planifikuar. T\u00eb tjer\u00ebt i kryejn\u00eb ato papritur p\u00ebr ne, n\u00eb \u00e7do koh\u00eb t\u00eb dit\u00ebs e nat\u00ebs.<\/p>\n
<\/p>\n
Ne d\u00ebshironim q\u00eb simulatori yn\u00eb i q\u00ebndrestaritetit t\u00eb modelonte proceset e pun\u00ebs q\u00eb i p\u00ebrkasin topologjive dhe ngarkesave t\u00eb pun\u00ebs q\u00eb \u00e7uan n\u00eb mbingarkes\u00ebn e infrastruktrur\u00ebs s\u00eb Shopify n\u00eb t\u00eb kaluar\u00ebn. Q\u00ebllimi kryesor i p\u00ebrdorimit t\u00eb service mesh \u00ebsht\u00eb se na nevojitet q\u00ebndrueshm\u00ebri dhe q\u00ebndrestaritet n\u00eb nivelin e rrjetit dhe \u00ebsht\u00eb e r\u00ebnd\u00ebsishme q\u00eb service mesh t\u00eb p\u00ebrballoj\u00eb ngarkesat q\u00eb m\u00eb par\u00eb e kishin shqet\u00ebsuar funksionin e sh\u00ebrbimeve.<\/p>\n
<\/p>\n
N\u00eb thelbin e simulatorit t\u00eb q\u00ebndrestaritetit \u00ebsht\u00eb nj\u00eb nod pune q\u00eb vepron si nod i service mesh. Nodi i pun\u00ebs mund t\u00eb konfigurohet statikisht gjat\u00eb nisjes ose dinamikisht p\u00ebrmes REST API. Ne p\u00ebrdorim konfigurimin dinamik t\u00eb noderve t\u00eb pun\u00ebs p\u00ebr t\u00eb krijuar proceset e pun\u00ebs si teste regresive.<\/p>\n
<\/p>\n
Ja nj\u00eb shembull i nj\u00eb procesi:<\/p>\n
<\/p>\n