ProHoster > Blogs > Administrācija > CPU patēriņa etalons Istio un Linkerd

CPU patēriņa etalons Istio un Linkerd

CPU patēriņa etalons Istio un Linkerd

Ievads

Mes esam ieksa Shopify sāka izvietot Istio kā pakalpojumu tīklu. Principā viss ir kārtībā, izņemot vienu: tas ir dārgs.

Š’ publicētajiem etaloniem par Istio teikts:

Izmantojot Istio 1.1, starpniekserveris patērē aptuveni 0,6 vCPU (virtuālos kodolus) uz 1000 pieprasÄ«jumiem sekundē.

Pirmajā pakalpojumu tÄ«kla reÄ£ionā (2 starpniekserveri katrā savienojuma pusē) mums bÅ«s 1200 kodoli tikai starpniekserveram ar ātrumu viens miljons pieprasÄ«jumu sekundē. Saskaņā ar Google izmaksu kalkulatoru konfigurācijai tas ir aptuveni 40 ASV dolāri mēnesÄ«. n1-standard-64, tas ir, Å”is reÄ£ions vien mums izmaksās vairāk nekā 50 tÅ«kstoÅ”us dolāru mēnesÄ« par 1 miljonu pieprasÄ«jumu sekundē.

Ivans Sim (Ivans Sim) vizuāli salÄ«dzināt servisa tÄ«kla aizkavÄ“Å”anās pagājuÅ”ajā gadā un solÄ«ja to paÅ”u atmiņai un procesoram, taču tas neizdevās:

AcÄ«mredzot vērtÄ«bas-istio-test.yaml nopietni palielinās CPU pieprasÄ«jumus. Ja esmu pareizi aprēķinājis, jums ir nepiecieÅ”ami aptuveni 24 CPU kodoli vadÄ«bas panelim un 0,5 CPU katram starpniekserveram. Man nav tik daudz. Pārbaudes atkārtoÅ”u, kad man tiks pieŔķirti vairāk lÄ«dzekļu.

Es gribēju pats pārliecināties, cik Istio veiktspēja ir līdzīga citam atvērtā pirmkoda pakalpojumu tīklam: Linkerd.

Servisa tīkla uzstādīŔana

Pirmkārt, es to instalēju klasterī 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!

Es izmantoju SuperGloo, jo tas ievērojami atvieglo pakalpojuma tÄ«kla sāknÄ“Å”anu. Man nebija daudz jādara. SuperGloo ražoÅ”anā neizmantojam, taču tas ir ideāli piemērots Ŕādam uzdevumam. Man bija burtiski jāizmanto pāris komandas katram pakalpojuma tÄ«klam. Izolācijai izmantoju divus klasterus - pa vienam Istio un Linkerd.

Eksperiments tika veikts Google Kubernetes Engine. Es izmantoju Kubernetes 1.12.7-gke.7 un mezglu kopums n1-standard-4 ar automātisku mezglu mērogoÅ”anu (minimums 4, maksimums 16).

Pēc tam es instalēju abus pakalpojumu tīklus no komandrindas.

Pirmā saite:

$ 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 |
+---------+--------------+---------+---------------------------+

Tad Istio:

$ 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      |
+---------+------------+---------+---------------------------+

Avārijas cilpa ilga dažas minūtes, un tad vadības paneļi stabilizējās.

(PiezÄ«me: SuperGloo pagaidām atbalsta tikai Istio 1.0.x. Es atkārtoju eksperimentu ar Istio 1.1.3, bet nepamanÄ«ju nekādu ievērojamu atŔķirÄ«bu.)

Istio automātiskās izvietoŔanas iestatīŔana

Lai Istio uzstādÄ«tu blakusvāģa Envoy, mēs izmantojam blakusvāģa inžektoru āˆ’ MutatingAdmissionWebhook. Å ajā rakstā mēs par to nerunāsim. Ä»aujiet man tikai teikt, ka Å”is ir kontrolieris, kas uzrauga piekļuvi visiem jaunajiem podiem un dinamiski pievieno blakusvāģi un initContainer, kas ir atbildÄ«gs par uzdevumiem. iptables.

Mēs, Shopify, uzrakstÄ«jām paÅ”i savu piekļuves kontrolieri, lai ieviestu blakusvāģus, taču Å”im etalonam es izmantoju kontrolieri, kas tiek piegādāts kopā ar Istio. Kontrolieris pēc noklusējuma ievada blakusvāģus, ja nosaukumu telpā ir saÄ«sne 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

Automātiskās Linkerd izvietoŔanas iestatīŔana

Lai iestatÄ«tu Linkerd blakusvāģa iegulÅ”anu, mēs izmantojam anotācijas (es pievienoju tās manuāli, izmantojot 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 kļūdu tolerances simulators

Mēs izveidojām kļūdu tolerances simulatoru Istio, lai eksperimentētu ar Shopify unikālo trafiku. Mums bija nepiecieÅ”ams rÄ«ks, lai izveidotu pielāgotu topoloÄ£iju, kas attēlotu noteiktu mÅ«su pakalpojumu diagrammas daļu, kas dinamiski konfigurēta, lai modelētu noteiktas darba slodzes.

Flash pārdoÅ”anas laikā Shopify infrastruktÅ«ra ir pakļauta lielai slodzei. Tajā paŔā laikā Shopify iesaka pārdevējiem Ŕādas izpārdoÅ”anas rÄ«kot biežāk. Lielie klienti dažkārt brÄ«dina par plānoto zibatmiņu. Citi mums tos negaidÄ«ti novada jebkurā dienas vai nakts laikā.

Mēs vēlējāmies, lai mÅ«su noturÄ«bas simulators modelētu darbplÅ«smas, kas atbilst topoloÄ£ijām un darba slodzēm, kas iepriekÅ” ir pārslogojuÅ”as Shopify infrastruktÅ«ru. Servisa tÄ«kla izmantoÅ”anas galvenais mērÄ·is ir tas, ka mums ir nepiecieÅ”ama uzticamÄ«ba un kļūdu tolerance tÄ«kla lÄ«menÄ«, un mums ir svarÄ«gi, lai servisa tÄ«kls efektÄ«vi tiktu galā ar slodzēm, kas iepriekÅ” traucēja pakalpojumu darbÄ«bu.

Kļūdu pielaides simulatora centrā ir darbinieka mezgls, kas darbojas kā pakalpojuma tÄ«kla mezgls. Darbinieka mezglu var konfigurēt statiski startÄ“Å”anas laikā vai dinamiski, izmantojot REST API. Mēs izmantojam darbinieku mezglu dinamisko konfigurāciju, lai izveidotu darbplÅ«smas regresijas testu veidā.

Å eit ir Ŕāda procesa piemērs:

  • Mēs palaižam 10 serverus kā bar pakalpojumu, kas atgriež atbildi 200/OK pēc 100 ms.
  • Mēs palaižam 10 klientus ā€” katrs nosÅ«ta 100 pieprasÄ«jumus sekundē bar.
  • Ik pēc 10 sekundēm mēs noņemam 1 serveri un pārraugām kļūdas 5xx uz klientu.

Darbplūsmas beigās mēs pārbaudām žurnālus un metriku un pārbaudām, vai pārbaude ir izturēta. Tādā veidā mēs uzzinām par mūsu pakalpojumu tīkla veiktspēju un veicam regresijas testu, lai pārbaudītu mūsu pieņēmumus par kļūdu toleranci.

(PiezÄ«me: mēs domājam par Istio defektu tolerances simulatora atklāto avotu iegÅ«Å”anu, taču vēl neesam gatavi to darÄ«t.)

Istio defektu tolerances simulators servisa tīkla etalonam

Mēs uzstādījām vairākus simulatora darba mezglus:

  • irs-client-loadgen: 3 kopijas, kas nosÅ«ta 100 pieprasÄ«jumu sekundē irs-client.
  • irs-client: 3 kopijas, kas saņem pieprasÄ«jumu, uzgaidiet 100 ms un pārsÅ«tiet pieprasÄ«jumu uz irs-server.
  • irs-server: 3 replikas, kas atgriežas 200/OK pēc 100 ms.

Izmantojot Å”o konfigurāciju, mēs varam izmērÄ«t stabilu satiksmes plÅ«smu starp 9 galapunktiem. Blakusvāģi iekŔā irs-client-loadgen Šø irs-server saņemt 100 pieprasÄ«jumus sekundē, un irs-client ā€” 200 (ienākoÅ”ie un izejoÅ”ie).

Mēs izsekojam resursu izmantoÅ”anu DataDogjo mums nav Prometeja kopas.

rezultātus

Vadības paneļi

Pirmkārt, mēs pārbaudījām CPU patēriņu.

CPU patēriņa etalons Istio un Linkerd
Linkerd vadības panelis ~22 milicore

CPU patēriņa etalons Istio un Linkerd
Istio vadības panelis: ~750 milicore

Istio vadÄ«bas panelis izmanto aptuveni 35 reizes vairāk CPU resursunekā Linkerds. Protams, viss ir instalēts pēc noklusējuma, un istio-telemetrija Å”eit patērē daudz procesora resursu (to var atspējot, atspējojot dažas funkcijas). Ja mēs noņemam Å”o komponentu, mēs joprojām iegÅ«stam vairāk nekā 100 milicores, tas ir 4 reizes vairāknekā Linkerds.

Blakusvāģa starpniekserveris

Pēc tam mēs pārbaudÄ«jām starpniekservera izmantoÅ”anu. JābÅ«t lineārai saistÄ«bai ar pieprasÄ«jumu skaitu, taču katrai blakusvāģim ir dažas pieskaitāmās izmaksas, kas ietekmē lÄ«kni.

CPU patēriņa etalons Istio un Linkerd
Linkerd: ~ 100 milicores irs-client, ~ 50 milicores irs-client-loadgen

Rezultāti izskatās loÄ£iski, jo klienta starpniekserveris saņem divreiz vairāk trafika nekā loadgen starpniekserveris: katram izejoÅ”ajam pieprasÄ«jumam no loadgen klientam ir viens ienākoÅ”ais un viens izejoÅ”ais.

CPU patēriņa etalons Istio un Linkerd
Istio/Envoy: ~155 milicores irs-client, ~75 milicores irs-client-loadgen

Līdzīgus rezultātus redzam arī Istio blakusvāģiem.

Bet vispār Istio/Envoy proxy patērē par aptuveni 50% vairāk CPU resursunekā Linkerds.

Mēs redzam to paÅ”u shēmu servera pusē:

CPU patēriņa etalons Istio un Linkerd
Linkerd: ~50 milicore irs-serverim

CPU patēriņa etalons Istio un Linkerd
Istio/Envoy: ~80 milicore irs-serverim

Servera pusē patērē blakusvāģis Istio/Envoy par aptuveni 60% vairāk CPU resursunekā Linkerds.

Secinājums

Istio Envoy starpniekserveris patērē par 50+% vairāk CPU nekā Linkerd mÅ«su simulētajā darba slodzē. Linkerd vadÄ«bas panelis patērē daudz mazāk resursu nekā Istio, Ä«paÅ”i attiecÄ«bā uz galvenajiem komponentiem.

Joprojām domājam, kā Ŕīs izmaksas samazināt. Ja ir idejas, lūdzu padalieties!

Avots: www.habr.com

Pievieno komentāru