{"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\/sk\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmark spotreby CPU pre Istio a Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmark<\/p>\n

<\/p>\n

\u00davod<\/h2>\n

<\/p>\n

My v Shopify<\/a><\/noindex> sme zaoberali nasaden\u00edm Istio ako service mesh. V z\u00e1sade je v\u0161etko v poriadku, okrem jednej veci: je to drah\u00e9<\/strong>.<\/p>\n

<\/p>\n

V publikovan\u00fdch benchmarkoch<\/a><\/noindex> pre Istio sa uv\u00e1dza:<\/p>\n

<\/p>\n

S Istio 1.1 proxy spotrebuje pribli\u017ene 0,6 vCPU (virtu\u00e1lnych jadier) na 1000 po\u017eiadaviek za sekundu.<\/p><\/blockquote>\n

Pre prv\u00fa oblas\u0165 v service mesh (po 2 proxy na ka\u017edej strane pripojenia) budeme potrebova\u0165 1200 jadier len pre proxy, pri\u010dom po\u010d\u00edtame s jedn\u00fdm mili\u00f3nom po\u017eiadaviek za sekundu. Pod\u013ea kalkula\u010dky n\u00e1kladov od Google to vych\u00e1dza na pribli\u017ene 40 dol\u00e1rov\/mesiac\/jadro pre konfigur\u00e1ciu n1-standard-64<\/code>, teda jedna t\u00e1to oblas\u0165 n\u00e1s bude st\u00e1\u0165 viac ako 50 tis\u00edc dol\u00e1rov mesa\u010dne za 1 mili\u00f3n po\u017eiadaviek za sekundu.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) jasne porovnal<\/a><\/noindex> latencie service mesh z minul\u00e9ho roka a s\u013e\u00fabil to ist\u00e9 pre pam\u00e4\u0165 a procesor, ale nepodarilo sa:<\/p>\n

<\/p>\n

Zrejme values-istio-test.yaml v\u00e1\u017ene zv\u00fd\u0161i po\u017eiadavky na procesor. Ak som to spr\u00e1vne vypo\u010d\u00edtal, potrebujem pribli\u017ene 24 procesorov\u00fdch jadier pre ovl\u00e1dac\u00ed panel a 0,5 CPU pre ka\u017ed\u00fd proxy. Nem\u00e1m to\u013eko. Opakujem testy, ke\u010f mi pridelia viac zdrojov.<\/p><\/blockquote>\n

Chcel som sa s\u00e1m presved\u010di\u0165, ako sa ukazovatele Istio porovn\u00e1vaj\u00fa s inou service mesh s otvoren\u00fdm k\u00f3dom: Linkerd<\/a><\/noindex>.<\/p>\n

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

In\u0161tal\u00e1cia service mesh<\/h3>\n

<\/p>\n

Najprv som nain\u0161taloval v 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
Pou\u017eil som SuperGloo, preto\u017ee v\u00fdrazne u\u013eah\u010duje za\u010diatok nasadenia service mesh. Takmer som nemusel ni\u010d robi\u0165. V produkcii nepou\u017e\u00edvame SuperGloo, ale na podobn\u00fa \u00falohu je ide\u00e1lny. Musel som pou\u017ei\u0165 len p\u00e1r pr\u00edkazov pre ka\u017ed\u00fa service mesh. Pou\u017eil som dve klastry na izol\u00e1ciu \u2014 po jednom pre Istio a Linkerd.<\/p>\n
<\/p>\n
Experiment sa uskuto\u010dnil na Google Kubernetes Engine. Pou\u017eil som Kubernetes 1.12.7-gke.7<\/code> a uzolov\u00fd pool n1-standard-4<\/code> s automatick\u00fdm \u0161k\u00e1lovan\u00edm uzlov (minim\u00e1lne 4, maxim\u00e1lne 16).<\/p>\n
<\/p>\n
Potom som nain\u0161taloval obe service mesh z pr\u00edkazov\u00e9ho riadku.<\/p>\n
<\/p>\n
Najprv 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
Potom 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 trval nieko\u013eko min\u00fat, a potom sa ovl\u00e1dacie panely stabilizovali.<\/p>\n
<\/p>\n
(Pozn\u00e1mka: SuperGloo zatia\u013e podporuje len Istio 1.0.x. Opakoval som experiment s Istio 1.1.3, ale nezaznamenal som \u017eiadny v\u00fdznamn\u00fd rozdiel.)<\/em><\/p>\n
<\/p>\n
Nastavenie automatick\u00e9ho vkladania Istio<\/h3>\n
<\/p>\n
Aby Istio nain\u0161taloval sidecar Envoy, pou\u017e\u00edvame sidecar-injektor \u2014 MutatingAdmissionWebhook<\/code>. Nebudeme o \u0148om hovori\u0165 v tomto \u010dl\u00e1nku. Len poviem, \u017ee je to kontrol\u00e9r, ktor\u00fd sleduje pr\u00edstup v\u0161etk\u00fdch nov\u00fdch podov a dynamicky prid\u00e1va sidecar a initContainer, ktor\u00fd sa zaober\u00e1 \u00falohami iptables<\/code>.<\/p>\n
<\/p>\n
V Shopify sme nap\u00edsali svoj kontrol\u00e9r pr\u00edstupu na vkladanie sidecar-ov, ale v tomto benchmarku som vzal kontrol\u00e9r, ktor\u00fd dod\u00e1va Istio. Predvolen\u00fd kontrol\u00e9r vklad\u00e1 sidecar-y, ke\u010f v n\u00e1zvoslovnom priestore existuje \u0161t\u00edtok 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
Nastavenie automatick\u00e9ho vkladania Linkerd<\/h3>\n
<\/p>\n
Aby sme nastavili vkladanie sidecar-ov Linkerd, pou\u017e\u00edvame anot\u00e1cie (pridal som ich ru\u010dne cez 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
Simul\u00e1tor odolnosti Istio<\/h3>\n
<\/p>\n
Vytvorili sme simul\u00e1tor odolnosti Istio, aby sme experimentovali s prev\u00e1dzkov\u00fdm tokom \u0161pecifick\u00fdm pre Shopify. Potrebovali sme n\u00e1stroj na vytv\u00e1ranie \u013eubovo\u013enej topol\u00f3gie, ktor\u00e1 bude predstavova\u0165 konkr\u00e9tnu \u010das\u0165 grafu na\u0161ej slu\u017eby s dynamick\u00fdm nastaven\u00edm na modelovanie \u0161pecifick\u00fdch pracovn\u00fdch z\u00e1\u0165a\u017e\u00ed.<\/p>\n
<\/p>\n
Infrastrukt\u00fara Shopify za\u017e\u00edva ve\u013ek\u00e9 za\u0165a\u017eenie po\u010das bleskov\u00fdch v\u00fdpredajov. Shopify odpor\u00fa\u010da predajcom \u010dastej\u0161ie organizova\u0165 tak\u00e9to v\u00fdpredaje<\/a><\/noindex>. Ve\u013ek\u00ed z\u00e1kazn\u00edci niekedy varuj\u00fa o pl\u00e1novanej bleskovej akcii. In\u00ed ich vykon\u00e1vaj\u00fa ne\u010dakane pre n\u00e1s v akomko\u013evek \u010dase po\u010das d\u0148a a noci.<\/p>\n
<\/p>\n
Chceli sme, aby n\u00e1\u0161 simul\u00e1tor odolnosti modeloval pracovn\u00e9 procesy, ktor\u00e9 s\u00fa v s\u00falade s topol\u00f3giami a pracovn\u00fdmi z\u00e1\u0165a\u017eami, ktor\u00e9 v minulosti viedli k pre\u0165a\u017eeniu infra\u0161trukt\u00fary Shopify. Hlavn\u00fdm cie\u013eom pou\u017eitia service mesh je, \u017ee potrebujeme spo\u013eahlivos\u0165 a odolnos\u0165 na \u00farovni siete a je pre n\u00e1s d\u00f4le\u017eit\u00e9, aby si service mesh efekt\u00edvne poradila s za\u0165a\u017eeniami, ktor\u00e9 predt\u00fdm nar\u00fa\u0161ali prev\u00e1dzku slu\u017eieb.<\/p>\n
<\/p>\n
Na z\u00e1klade simul\u00e1tora odolnosti stoj\u00ed pracovn\u00fd uzol, ktor\u00fd funguje ako uzol service mesh. Pracovn\u00fd uzol je mo\u017en\u00e9 nakonfigurova\u0165 staticky pri spusten\u00ed alebo dynamicky prostredn\u00edctvom REST API. Pou\u017e\u00edvame dynamick\u00e9 nastavenie pracovn\u00fdch uzlov na vytv\u00e1ranie pracovn\u00fdch procesov vo forme regresn\u00fdch testov.<\/p>\n
<\/p>\n
Tu je pr\u00edklad tak\u00e9hoto procesu:<\/p>\n
<\/p>\n