Cyflwyniad
Rydyn ni i mewn dechrau defnyddio Istio fel rhwyll gwasanaeth. Mewn egwyddor, mae popeth yn iawn, ac eithrio un peth: mae'n ddrud.
Π i Istio mae'n dweud:
Gydag Istio 1.1, mae'r dirprwy yn defnyddio tua 0,6 vCPU (credydau rhithwir) fesul 1000 o geisiadau yr eiliad.
Ar gyfer y rhanbarth cyntaf yn y rhwyll gwasanaeth (2 ddirprwy ar bob ochr i'r cysylltiad), bydd gennym 1200 o greiddiau ar gyfer y dirprwy yn unig, ar gyfradd o filiwn o geisiadau yr eiliad. Yn Γ΄l cyfrifiannell costau Google, mae'n gweithio allan i fod tua $40/mis/craidd ar gyfer cyfluniad n1-standard-64, hynny yw, bydd y rhanbarth hwn yn unig yn costio mwy na 50 mil o ddoleri y mis i ni am 1 miliwn o geisiadau yr eiliad.
Ivan Sim () oedi rhwyll gwasanaeth y llynedd ac addo yr un peth ar gyfer cof a phrosesydd, ond ni weithiodd allan:
Yn Γ΄l pob tebyg, bydd gwerthoedd-istio-test.yaml yn cynyddu ceisiadau CPU o ddifrif. Os ydw i wedi gwneud fy mathemateg yn gywir, mae angen tua 24 craidd CPU arnoch ar gyfer y panel rheoli a 0,5 CPU ar gyfer pob dirprwy. Does gen i ddim cymaint Γ’ hynny. Byddaf yn ailadrodd y profion pan fydd mwy o adnoddau'n cael eu dyrannu i mi.
Roeddwn i eisiau gweld drosof fy hun pa mor debyg yw perfformiad Istio i rwyll gwasanaeth ffynhonnell agored arall: .
Gosod rhwyll gwasanaeth
Yn gyntaf oll, fe'i gosodais mewn clwstwr :
$ 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!Defnyddiais SuperGloo oherwydd mae'n ei gwneud hi'n haws o lawer strapio'r rhwyll gwasanaeth. Doedd dim rhaid i mi wneud llawer. Nid ydym yn defnyddio SuperGloo wrth gynhyrchu, ond mae'n ddelfrydol ar gyfer tasg o'r fath. Roedd yn rhaid i mi ddefnyddio'n llythrennol ychydig o orchmynion ar gyfer pob rhwyll gwasanaeth. Defnyddiais ddau glwstwr ar gyfer ynysu - un yr un ar gyfer Istio a Linkerd.
Cynhaliwyd yr arbrawf ar Google Kubernetes Engine. Defnyddiais Kubernetes 1.12.7-gke.7 a phwll o nodau n1-standard-4 gyda graddio nodau awtomatig (lleiafswm 4, uchafswm 16).
Yna gosodais y ddau rwyll gwasanaeth o'r llinell orchymyn.
Linkerd Cyntaf:
$ 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 |
+---------+--------------+---------+---------------------------+Yna 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 |
+---------+------------+---------+---------------------------+Cymerodd y ddolen ddamwain ychydig funudau, ac yna sefydlogodd y paneli rheoli.
(Sylwer: Dim ond am y tro y mae SuperGloo yn cefnogi Istio 1.0.x. Ailadroddais yr arbrawf gydag Istio 1.1.3, ond ni sylwais ar unrhyw wahaniaeth amlwg.)
Sefydlu Istio Awtomatig Defnyddio
Er mwyn gwneud i Istio osod y Cennad car ochr, rydyn ni'n defnyddio'r chwistrellwr car ochr β MutatingAdmissionWebhook. Ni fyddwn yn siarad amdano yn yr erthygl hon. Gadewch imi ddweud mai rheolydd yw hwn sy'n monitro mynediad pob cod newydd ac yn ychwanegu car ochr ac initContainer yn ddeinamig, sy'n gyfrifol am dasgau iptables.
Fe wnaethom ni yn Shopify ysgrifennu ein rheolydd mynediad ein hunain i weithredu ceir ochr, ond ar gyfer y meincnod hwn defnyddiais y rheolydd sy'n dod gydag Istio. Mae'r rheolydd yn chwistrellu ceir ochr yn ddiofyn pan fo llwybr byr yn y gofod enw 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 labeledSefydlu gosodiad Linkerd yn awtomatig
I sefydlu mewnosod car ochr Linkerd, rydym yn defnyddio anodiadau (fe wnes i eu hychwanegu Γ’ llaw trwy 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: ActiveIstio Efelychydd Goddefgarwch Nam
Fe wnaethom adeiladu efelychydd goddef diffygion o'r enw Istio i arbrofi gyda thraffig sy'n unigryw i Shopify. Roedd angen teclyn arnom i greu topoleg wedi'i deilwra a fyddai'n cynrychioli cyfran benodol o'n graff gwasanaeth, wedi'i ffurfweddu'n ddeinamig i fodelu llwythi gwaith penodol.
Mae seilwaith Shopify dan lwyth trwm yn ystod gwerthiannau fflach. Ar yr un pryd, Shopify . Mae cwsmeriaid mawr weithiau'n rhybuddio am werthu fflach arfaethedig. Mae eraill yn eu harwain yn annisgwyl ar ein rhan ar unrhyw adeg o'r dydd neu'r nos.
Roeddem am i'n hefelychydd gwydnwch fodelu llifoedd gwaith sy'n cyd-fynd Γ’'r topolegau a'r llwythi gwaith sydd wedi llethu seilwaith Shopify yn y gorffennol. Prif ddiben defnyddio rhwyll gwasanaeth yw bod angen dibynadwyedd a goddefgarwch namau arnom ar lefel y rhwydwaith, ac mae'n bwysig i ni fod y rhwyll gwasanaeth yn ymdopi'n effeithiol Γ’ llwythi a oedd yn tarfu ar wasanaethau yn flaenorol.
Wrth wraidd yr efelychydd goddefgarwch bai mae nod gweithiwr, sy'n gweithredu fel nod rhwyll gwasanaeth. Gellir ffurfweddu nod y gweithiwr yn statig wrth gychwyn neu'n ddeinamig trwy API REST. Rydym yn defnyddio cyfluniad deinamig o nodau gweithwyr i greu llifoedd gwaith ar ffurf profion atchweliad.
Dyma enghraifft o broses o'r fath:
- Rydym yn lansio 10 gweinydd fel
bargwasanaeth sy'n dychwelyd ymateb200/OKar Γ΄l 100 ms. - Rydym yn lansio 10 cleient - pob un yn anfon 100 cais yr eiliad i
bar. - Bob 10 eiliad rydym yn cael gwared ar 1 gweinydd ac yn monitro gwallau
5xxar y cleient.
Ar ddiwedd y llif gwaith, rydym yn archwilio'r logiau a'r metrigau ac yn gwirio a basiodd y prawf. Fel hyn rydym yn dysgu am berfformiad ein rhwyll gwasanaeth ac yn cynnal prawf atchweliad i brofi ein rhagdybiaethau ynghylch goddef diffygion.
(Sylwer: Rydym yn ystyried cyrchu'r efelychydd goddefgarwch bai Istio yn agored, ond nid ydym yn barod i wneud hynny eto.)
Efelychydd goddefgarwch fai ar gyfer meincnod rhwyll gwasanaeth
Fe wnaethon ni sefydlu sawl nod gweithio o'r efelychydd:
irs-client-loadgen: 3 atgynhyrchiad sy'n anfon 100 cais yr eiliad yr eiliadirs-client.irs-client: 3 atgynhyrchiad sy'n derbyn y cais, arhoswch 100ms ac anfon y cais ymlaen atirs-server.irs-server: 3 replicas sy'n dychwelyd200/OKar Γ΄l 100 ms.
Gyda'r cyfluniad hwn, gallwn fesur llif traffig sefydlog rhwng 9 pwynt terfyn. Ceir ochr i mewn irs-client-loadgen ΠΈ irs-server derbyn 100 o geisiadau yr eiliad, a irs-client - 200 (yn dod i mewn ac yn mynd allan).
Rydym yn olrhain y defnydd o adnoddau drwodd oherwydd nid oes gennym glwstwr Prometheus.
Canfyddiadau
Paneli rheoli
Yn gyntaf, archwiliwyd y defnydd CPU.
Panel rheoli Linkerd ~ 22 milicore
Panel rheoli: ~ 750 milicore
Mae panel rheoli Istio yn defnyddio tua 35 gwaith yn fwy o adnoddau CPUna Linkerd. Wrth gwrs, mae popeth wedi'i osod yn ddiofyn, ac mae istio-telemetreg yn defnyddio llawer o adnoddau prosesydd yma (gellir ei analluogi trwy analluogi rhai swyddogaethau). Os byddwn yn cael gwared ar y gydran hon, rydym yn dal i gael mwy na 100 miligor, hynny yw 4 gwaith yn fwyna Linkerd.
dirprwy car ochr
Yna gwnaethom brofi'r defnydd o ddirprwy. Dylai fod perthynas linellol Γ’ nifer y ceisiadau, ond ar gyfer pob car ochr mae rhywfaint o orbenion sy'n effeithio ar y gromlin.
Linkerd: ~ 100 milicore ar gyfer ir-cleient, ~ 50 milicro ar gyfer ir-cleient-loadgen
Mae'r canlyniadau'n edrych yn rhesymegol, oherwydd mae dirprwy'r cleient yn derbyn dwywaith cymaint o draffig na'r dirprwy loadgen: am bob cais gan loadgen sy'n mynd allan, mae gan y cleient un yn dod i mewn ac un yn mynd allan.
Istio / Cenhadwr: ~ 155 milicore ar gyfer ier-cleient, ~ 75 milicore ar gyfer ieir-cleient-loadgen
Rydym yn gweld canlyniadau tebyg ar gyfer sidecars Istio.
Ond yn gyffredinol, mae dirprwyon Istio/Envoy yn defnyddio tua 50% yn fwy o adnoddau CPUna Linkerd.
Rydym yn gweld yr un cynllun ar ochr y gweinydd:
Linkerd: ~ 50 milicore ar gyfer iir-gweinydd
Istio / Cennad: ~80 milicore ar gyfer iir-server
Ar ochr y gweinydd, mae Istio/Envoy yn defnyddio car ochr tua 60% yn fwy o adnoddau CPUna Linkerd.
Casgliad
Mae dirprwy Istio Envoy yn defnyddio 50+% yn fwy o CPU na Linkerd ar ein llwyth gwaith efelychiedig. Mae panel rheoli Linkerd yn defnyddio llawer llai o adnoddau nag Istio, yn enwedig ar gyfer y cydrannau craidd.
Rydym yn dal i feddwl am sut i leihauβr costau hyn. Os oes gennych chi syniadau, plis rhannwch!
Ffynhonnell: hab.com