Enkonduko
Ni estas en komencis deploji Istio kiel servomaŝo. Principe ĉio estas en ordo, krom unu afero: ĝi estas multekosta.
В por Istio ĝi diras:
Kun Istio 1.1, la prokurilo konsumas proksimume 0,6 vCPUs (virtualaj kernoj) po 1000 petoj sekundo.
Por la unua regiono en la servomaŝo (2 prokuriloj sur ĉiu flanko de la konekto), ni havos 1200 kernojn nur por la prokurilo, kun rapideco de unu miliono da petoj sekundo. Laŭ la kostkalkulilo de Guglo, ĝi rezultas proksimume $ 40/monato/kerno por agordo n1-standard-64, tio estas, ĉi tiu regiono sola kostos al ni pli ol 50 mil dolarojn monate por 1 miliono da petoj sekundo.
Ivan Sim () servo maŝo prokrastis pasintjare kaj promesis la samon por memoro kaj procesoro, sed ĝi ne funkciis:
Ŝajne, values-istio-test.yaml grave pliigos CPU-petojn. Se mi ĝuste faris mian matematikon, vi bezonas proksimume 24 CPU-kernojn por la kontrolpanelo kaj 0,5 CPU por ĉiu prokurilo. Mi ne havas tiom multe. Mi ripetos la provojn kiam pli da rimedoj estos asignitaj al mi.
Mi volis mem vidi kiom similas la agado de Istio al alia malfermfonta servomaŝo: .
Serva maŝo-instalado
Antaŭ ĉio, mi instalis ĝin en areto :
$ 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!Mi uzis SuperGloo ĉar ĝi multe pli facilas ekfunkciigi la servon. Mi ne devis fari multon. Ni ne uzas SuperGloo en produktado, sed ĝi estas ideala por tia tasko. Mi devis uzi laŭvorte kelkajn komandojn por ĉiu servomaŝo. Mi uzis du aretojn por izolado - po unu por Istio kaj Linkerd.
La eksperimento estis farita sur Google Kubernetes Engine. Mi uzis Kubernetes 1.12.7-gke.7 kaj aro da nodoj n1-standard-4 kun aŭtomata nodo-skalado (minimume 4, maksimume 16).
Poste mi instalis ambaŭ servajn retojn de la komandlinio.
Unua Linkerd:
$ 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 |
+---------+--------------+---------+---------------------------+Tiam 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 |
+---------+------------+---------+---------------------------+La kraŝ-buklo daŭris kelkajn minutojn, kaj tiam la kontrolpaneloj stabiliĝis.
(Noto: SuperGloo nur subtenas Istio 1.0.x nuntempe. Mi ripetis la eksperimenton kun Istio 1.1.3, sed ne rimarkis rimarkindan diferencon.)
Agordi Istio Aŭtomatan Deplojon
Por ke Istio instalu la kromĉaron Envoy, ni uzas la kromĉaron injektilon − MutatingAdmissionWebhook. Ni ne parolos pri ĝi en ĉi tiu artikolo. Mi nur diru, ke ĉi tio estas regilo, kiu kontrolas la aliron de ĉiuj novaj podoj kaj dinamike aldonas kromĉaron kaj initContainer, kiu respondecas pri taskoj. iptables.
Ni ĉe Shopify skribis nian propran alirregilon por efektivigi kromĉarojn, sed por ĉi tiu komparnormo mi uzis la regilon kiu venas kun Istio. La regilo injektas kromĉarojn defaŭlte kiam estas ŝparvojo en la nomspaco 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 labeledAgordo de aŭtomata disfaldo de Linkerd
Por agordi Linkerd-flankan enkonstruadon, ni uzas komentadojn (mi aldonis ilin permane per 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 Fault Tolerance Simulator
Ni konstruis simulilon pri mistoleremo nomita Istio por eksperimenti kun trafiko unika al Shopify. Ni bezonis ilon por krei kutiman topologion, kiu reprezentus specifan parton de nia serva grafikaĵo, dinamike agordita por modeligi specifajn laborŝarĝojn.
La infrastrukturo de Shopify estas sub peza ŝarĝo dum fulmaj vendoj. Samtempe, Shopify . Grandaj klientoj foje avertas pri planita fulmvendo. Aliaj kondukas ilin neatendite por ni en ajna momento de la tago aŭ nokto.
Ni volis, ke nia rezisteca simulilo modeligu laborfluojn, kiuj kongruas kun la topologioj kaj laborŝarĝoj, kiuj superfortis la infrastrukturon de Shopify en la pasinteco. La ĉefa celo de uzado de servomaŝo estas, ke ni bezonas fidindecon kaj faŭltoleremon ĉe la reto-nivelo, kaj gravas por ni, ke la servomaŝo efike traktas ŝarĝojn, kiuj antaŭe interrompis servojn.
Ĉe la kerno de la faŭltoleremo-simulilo estas laborista nodo, kiu funkcias kiel serva retnodo. La laborista nodo povas esti agordita statike ĉe ekfunkciigo aŭ dinamike per REST-API. Ni uzas dinamikan agordon de labornodoj por krei laborfluojn en formo de regresaj testoj.
Jen ekzemplo de tia procezo:
- Ni lanĉas 10 servilojn kiel
barservo kiu resendas respondon200/OKpost 100 ms. - Ni lanĉas 10 klientojn - ĉiu sendas 100 petojn sekundo al
bar. - Ĉiujn 10 sekundojn ni forigas 1 servilon kaj kontrolas erarojn
5xxsur la kliento.
Ĉe la fino de la laborfluo, ni ekzamenas la protokolojn kaj metrikojn kaj kontrolas ĉu la testo pasis. Tiel ni lernas pri la agado de nia servo-maŝo kaj faras regresan teston por testi niajn supozojn pri misfunkciado.
(Noto: Ni pripensas malferman fonton de la simulilo pri misfunkciado de Istio, sed ankoraŭ ne pretas fari tion.)
Istio faŭltoleremo simulilo por servo mesh komparnormo
Ni starigis plurajn labornodojn de la simulilo:
irs-client-loadgen: 3 kopioj kiuj sendas 100 petojn sekundo poirs-client.irs-client: 3 kopioj kiuj ricevas la peton, atendu 100ms kaj plusendas la peton alirs-server.irs-server: 3 kopioj kiuj revenas200/OKpost 100 ms.
Kun ĉi tiu agordo, ni povas mezuri stabilan trafikfluon inter 9 finpunktoj. Kromĉaroj en irs-client-loadgen и irs-server ricevi 100 petojn sekundo, kaj irs-client — 200 (envenantaj kaj elirantaj).
Ni spuras la uzadon de rimedoj ĉar ni ne havas Prometeo-areton.
Результаты
Kontrolaj paneloj
Unue, ni ekzamenis la CPU-konsumon.
Linkerd-kontrolpanelo ~22 milikoroj
Istio kontrolpanelo: ~750 milikorno
La kontrolpanelo Istio uzas proksimume 35 fojojn pli da CPU-resursojol Linkerd. Kompreneble, ĉio estas instalita defaŭlte, kaj istio-telemetrio konsumas multajn procesorajn rimedojn ĉi tie (ĝi povas esti malŝaltita malŝaltante iujn funkciojn). Se ni forigas ĉi tiun komponanton, ni ankoraŭ ricevas pli ol 100 milikorojn, tio estas 4 fojojn pliol Linkerd.
Sidecar prokurilo
Ni tiam testis la uzon de prokurilo. Devus ekzisti linia rilato kun la nombro da petoj, sed por ĉiu kromĉaro estas iom da supra kosto, kiu influas la kurbon.
Linkerd: ~100 milikoroj por irs-kliento, ~50 milikoroj por irs-client-loadgen
La rezultoj aspektas logikaj, ĉar la klienta prokurilo ricevas duoble pli da trafiko ol la loadgen-prokurilo: por ĉiu eksiĝinta peto de loadgen, kliento havas unu envenantan kaj unu elirantan.
Istio/Envoy: ~155 milikoroj por irs-kliento, ~75 milikonoj por irs-client-loadgen
Ni vidas similajn rezultojn por Istio kromĉaroj.
Sed ĝenerale, Istio/Envoy-prokuriloj konsumas proksimume 50% pli da CPU-resursojol Linkerd.
Ni vidas la saman skemon ĉe la servilo:
Linkerd: ~50 milikero por irs-servilo
Istio/Envoy: ~80 milikorno por irs-servilo
Sur la servilflanko, kromĉaro Istio/Envoy konsumas proksimume 60% pli da CPU-resursojol Linkerd.
konkludo
La prokurilo Istio Envoy konsumas 50+% pli da CPU ol Linkerd sur nia ŝajniga laborkvanto. La kontrolpanelo Linkerd konsumas multe malpli da rimedoj ol Istio, precipe por la kernaj komponantoj.
Ni ankoraŭ pensas pri kiel redukti ĉi tiujn kostojn. Se vi havas ideojn, bonvolu dividi!
fonto: www.habr.com