Pasiuna
Naa mi sa nagsugod sa pagdeploy sa Istio isip usa ka service mesh. Sa prinsipyo, maayo ang tanan, gawas sa usa ka butang: mahal kini.
Π kay si Istio nag-ingon:
Uban sa Istio 1.1, ang proxy naggamit sa gibana-bana nga 0,6 vCPUs (virtual cores) kada 1000 ka hangyo kada segundo.
Para sa unang rehiyon sa service mesh (2 ka proxy sa matag kilid sa koneksyon), aduna kitay 1200 ka core para lang sa proxy, sa gikusgon nga usa ka milyon nga hangyo kada segundo. Sumala sa calculator sa gasto sa Google, kini molihok nga gibana-bana nga $ 40 / bulan / kinauyokan alang sa pag-configure n1-standard-64, nga mao, kini nga rehiyon lamang ang mogasto kanato labaw pa sa 50 ka libo nga dolyar matag bulan alang sa 1 ka milyon nga mga hangyo matag segundo.
Ivan Sim () Ang serbisyo sa mesh nalangan sa miaging tuig ug misaad sa parehas alang sa memorya ug processor, apan wala kini molihok:
Dayag, ang values-istio-test.yaml seryosong mopataas sa mga hangyo sa CPU. Kung nabuhat nako sa husto ang akong matematika, kinahanglan nimo ang mga 24 nga CPU cores alang sa control panel ug 0,5 CPU alang sa matag proxy. Wala kaayo ko. Akong balikon ang mga pagsulay kung daghang mga kapanguhaan ang gigahin kanako.
Gusto nako nga makita sa akong kaugalingon kung unsa ka parehas ang pasundayag ni Istio sa lain nga open source service mesh: .
Pag-instalar sa serbisyo sa mesh
Una sa tanan, gi-install ko kini sa usa ka cluster :
$ 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!Gigamit nako ang SuperGloo tungod kay gipadali niini ang pag-bootstrap sa service mesh. Wala ko kinahanglana nga buhaton. Wala kami mogamit sa SuperGloo sa produksiyon, apan kini maayo alang sa ingon nga buluhaton. Kinahanglan kong mogamit sa literal nga duha ka mga sugo alang sa matag mesh sa serbisyo. Gigamit nako ang duha ka kumpol alang sa pag-inusara - usa matag usa alang sa Istio ug Linkerd.
Ang eksperimento gihimo sa Google Kubernetes Engine. Gigamit nako ang Kubernetes 1.12.7-gke.7 ug usa ka pool sa mga node n1-standard-4 nga adunay awtomatik nga pag-scale sa node (minimum 4, maximum 16).
Dayon akong gi-install ang duha ka service meshes gikan sa command line.
Unang 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 |
+---------+--------------+---------+---------------------------+Unya si 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 |
+---------+------------+---------+---------------------------+Ang crash-loop milungtad og pipila ka minuto, ug dayon ang mga control panel mi-stabilize.
(Pahinumdom: Gisuportahan lang sa SuperGloo ang Istio 1.0.x sa pagkakaron. Gisubli nako ang eksperimento sa Istio 1.1.3, apan wala makamatikod sa bisan unsang mamatikdan nga kalainan.)
Pag-set up sa Istio Automatic Deployment
Aron ma-install ni Istio ang sidecar Envoy, among gigamit ang sidecar injector β MutatingAdmissionWebhook. Dili kami maghisgot bahin niini sa kini nga artikulo. Isulti lang nako nga kini usa ka controller nga nagmonitor sa pag-access sa tanan nga mga bag-ong pod ug dinamikong nagdugang usa ka sidecar ug initContainer, nga responsable sa mga buluhaton. iptables.
Kami sa Shopify nagsulat sa among kaugalingon nga access controller aron ipatuman ang mga sidecar, apan alang niini nga benchmark gigamit nako ang controller nga kauban sa Istio. Ang controller nag-inject sa mga sidecar pinaagi sa default kung adunay usa ka shortcut sa namespace 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 labeledPag-set up sa awtomatikong pag-deploy sa Linkerd
Aron ma-set up ang Linkerd sidecar embedding, gigamit namo ang mga anotasyon (gidugang ko kini sa mano-mano pinaagi sa 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
Nagtukod kami og fault tolerance simulator nga gitawag og Istio aron mag-eksperimento sa trapiko nga talagsaon sa Shopify. Nagkinahanglan kami og himan aron makahimo og custom nga topology nga magrepresentar sa usa ka piho nga bahin sa among service graph, nga dinamikong gi-configure aron sa pagmodelo sa piho nga mga workloads.
Ang imprastraktura sa Shopify ubos sa bug-at nga karga sa panahon sa pagbaligya sa flash. Sa parehas nga oras, Shopify . Ang dagkong mga kustomer usahay magpasidaan bahin sa giplano nga flash sale. Ang uban naghimo niini nga wala damha alang kanato sa bisan unsang oras sa adlaw o gabii.
Gusto namo nga ang among resiliency simulator mag-modelo sa mga workflow nga mohaum sa mga topologies ug workloads nga nakapasamot sa imprastraktura sa Shopify kaniadto. Ang panguna nga katuyoan sa paggamit sa usa ka serbisyo nga mesh mao nga kinahanglan namon ang kasaligan ug pagtugot sa sayup sa lebel sa network, ug hinungdanon alang kanamo nga ang serbisyo nga mesh epektibo nga makasagubang sa mga karga nga kaniadto nakabalda sa mga serbisyo.
Sa kasingkasing sa fault tolerance simulator mao ang worker node, nga naglihok isip service mesh node. Ang worker node mahimong ma-configure sa statically sa pagsugod o dinamikong paagi pinaagi sa REST API. Gigamit namo ang dinamikong pag-configure sa mga worker node aron makahimo og mga workflow sa porma sa regression tests.
Ania ang usa ka pananglitan sa ingon nga proseso:
- Naglunsad kami og 10 ka mga server isip
barserbisyo nga nagbalik sa tubag200/OKpagkahuman sa 100 ms. - Naglunsad kami og 10 ka mga kliyente - ang matag usa nagpadala ug 100 ka hangyo kada segundo ngadto sa
bar. - Matag 10 segundos among tangtangon ang 1 server ug monitoron ang mga sayop
5xxsa kliyente.
Sa pagtapos sa dagan sa trabaho, among susihon ang mga log ug sukatan ug susihon kung nakapasar ba ang pagsulay. Niining paagiha makakat-on kami mahitungod sa performance sa among service mesh ug magpadagan og regression test aron sulayan ang among mga pangagpas mahitungod sa fault tolerance.
(Pahinumdom: Naghunahuna kami bahin sa bukas nga pagpangita sa Istio fault tolerance simulator, apan dili pa andam nga buhaton kini.)
Istio fault tolerance simulator alang sa service mesh benchmark
Nag-set up kami og daghang mga working node sa simulator:
irs-client-loadgen: 3 replika nga nagpadala ug 100 ka hangyo kada segundo kadairs-client.irs-client: 3 replika nga nakadawat sa hangyo, paghulat 100ms ug ipasa ang hangyo sairs-server.irs-server: 3 replika nga nagbalik200/OKpagkahuman sa 100 ms.
Uban niini nga pag-configure, mahimo natong sukdon ang usa ka lig-on nga dagan sa trapiko tali sa 9 nga mga endpoint. Mga sidecar sa irs-client-loadgen ΠΈ irs-server makadawat og 100 ka hangyo kada segundo, ug irs-client β 200 (umaabot ug mogawas).
Among gisubay ang paggamit sa kahinguhaan pinaagi sa kay wala mi cluster nga Prometheus.
Π Π΅Π·ΡΠ»ΡΡΠ°ΡΡ
Mga control panel
Una, among gisusi ang pagkonsumo sa CPU.
Linkerd control panel ~22 millicore
Istio control panel: ~750 millicore
Ang Istio control panel naggamit sa gibanabana 35 ka beses nga mas daghang kapanguhaan sa CPUkaysa sa Linkerd. Siyempre, ang tanan gi-install pinaagi sa default, ug ang istio-telemetry naggamit sa daghang mga kapanguhaan sa processor dinhi (mahimong ma-disable kini pinaagi sa pag-disable sa pipila nga mga function). Kung atong tangtangon kini nga sangkap, makakuha gihapon kita labaw pa sa 100 millicores, kana 4 ka beses pakaysa sa Linkerd.
Sidecar proxy
Gisulayan dayon namo ang paggamit sa proxy. Kinahanglan nga adunay usa ka linear nga relasyon sa gidaghanon sa mga hangyo, apan alang sa matag sidecar adunay pipila ka overhead nga makaapekto sa kurba.
Linkerd: ~100 millicores para sa irs-client, ~50 millicores para sa irs-client-loadgen
Ang mga resulta tan-awon nga lohikal, tungod kay ang kliyente nga proxy makadawat og doble nga trapiko kaysa sa loadgen proxy: alang sa matag mogawas nga hangyo gikan sa loadgen, ang kliyente adunay usa ka umaabot ug usa nga mogawas.
Istio/Envoy: ~155 millicores para sa irs-client, ~75 millicores para sa irs-client-loadgen
Nakita namon ang parehas nga mga resulta para sa mga sidecar sa Istio.
Apan sa kinatibuk-an, ang Istio/Envoy proxy nagkonsumo gibana-bana nga 50% nga dugang nga mga kapanguhaan sa CPUkaysa sa Linkerd.
Nakita namon ang parehas nga laraw sa kilid sa server:
Linkerd: ~ 50 millicore para sa irs-server
Istio/Envoy: ~80 millicore para sa irs-server
Sa kilid sa server, gigamit ang sidecar nga Istio/Envoy gibana-bana nga 60% nga dugang nga mga kapanguhaan sa CPUkaysa sa Linkerd.
konklusyon
Ang Istio Envoy proxy naggamit ug 50+% nga mas daghang CPU kaysa Linkerd sa among simulate nga workload. Ang Linkerd control panel naggamit og mas gamay nga mga kapanguhaan kay sa Istio, ilabi na alang sa mga core component.
Naghunahuna pa kami kung giunsa ang pagkunhod sa kini nga mga gasto. Kung naa kay idea, palihog share!
Source: www.habr.com