د اسټیو او لینکرډ لپاره د CPU مصرف معیار

پېژندنه

موږ دننه یو Shopify د خدمت میش په توګه د اسټیو ګمارل پیل کړل. په اصل کې، هرڅه سم دي، پرته له یو شی څخه: دا ګران دی.

В خپاره شوي معیارونه د اسټیو لپاره دا وايي:

د Istio 1.1 سره، پراکسي په هر ثانیه کې نږدې 0,6 vCPUs (مجازی کور) په هر 1000 غوښتنو کې مصرفوي.

د خدمت میش کې د لومړۍ سیمې لپاره (د اتصال په هر اړخ کې 2 پراکسي) ، موږ به یوازې د پراکسي لپاره 1200 کورونه ولرو ، په هره ثانیه کې د یو ملیون غوښتنو په نرخ کې. د ګوګل د لګښت محاسبه کونکي په وینا، دا د ترتیب لپاره نږدې $ 40 / میاشت / کور کار کوي n1-standard-64يعنې يوازې دا سيمه به موږ ته په هره ثانيه کې د يو ميليون غوښتنو لپاره په مياشت کې له 50 زرو ډالرو څخه زيات لګښت ولرو.

ایوان سیم (ایوان سم) په لید سره پرتله کول د خدماتو میش تیر کال ځنډ وکړ او د حافظې او پروسیسر لپاره ورته ژمنه وکړه ، مګر دا کار ونکړ:

په ښکاره ډول، ارزښتونه-istio-test.yaml به په جدي توګه د CPU غوښتنې زیاتې کړي. که ما خپل ریاضی په سمه توګه ترسره کړی وي، تاسو د کنټرول پینل لپاره نږدې 24 CPU کور او د هر پراکسي لپاره 0,5 CPU ته اړتیا لرئ. زه دومره نه لرم. زه به ازموینې تکرار کړم کله چې ما ته ډیرې سرچینې تخصیص شي.

ما غوښتل د ځان لپاره وګورم چې د اسټیو فعالیت د بل خلاصې سرچینې خدمت میش ته څومره ورته دی: لینکرډ.

د خدمت میش نصب کول

لومړی، ما دا په کلستر کې نصب کړ سوپر ګلو:

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

ما سوپر ګلو کارولی ځکه چې دا د خدماتو میش بوټسټراپ کول خورا اسانه کوي. ما باید ډیر څه ونه کړل. موږ په تولید کې SuperGloo نه کاروو، مګر دا د داسې دندې لپاره مثالی دی. ما باید د هر خدمت میش لپاره په لفظي ډول یو څو کمانډونه وکاروو. ما د جلا کولو لپاره دوه کلسترونه کارولي - یو هر یو د اسټیو او لینکرډ لپاره.

تجربه د ګوګل کوبرنیټس انجن کې ترسره شوې. ما Kubernetes وکارول 1.12.7-gke.7 او د نوډونو حوض n1-standard-4 د اتوماتیک نوډ اندازه کولو سره (لږترلږه 4، اعظمي 16).

بیا ما د کمانډ لاین څخه دواړه خدمت میشونه نصب کړل.

لومړی لینکر:

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

بیا 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      |
+---------+------------+---------+---------------------------+

د کریش لوپ یو څو دقیقې ونیولې، او بیا د کنټرول پینلونه ثبات شول.

(یادونه: سوپر ګلو یوازې د اوس لپاره د اسټیو 1.0.x ملاتړ کوي. ما د اسټیو 1.1.3 سره تجربه تکرار کړه ، مګر کوم د پام وړ توپیر یې ونه لید.)

د اسټیو اتوماتیک ځای پرځای کول تنظیم کول

د دې لپاره چې اسټیو د سایډ کار انوینټ نصب کړي، موږ د سایډ کار انجیکټر - کاروو MutatingAdmissionWebhook. موږ به پدې مقاله کې د دې په اړه خبرې ونه کړو. اجازه راکړئ یوازې ووایم چې دا یو کنټرولر دی چې د ټولو نوي پوډونو لاسرسی څاري او په متحرک ډول یو سایډ کار او initContainer اضافه کوي ، کوم چې د دندو مسؤلیت لري iptables.

موږ په Shopify کې د سایډکارونو پلي کولو لپاره زموږ د لاسرسي کنټرولر لیکلی ، مګر د دې بنچمارک لپاره ما هغه کنټرولر کارولی چې د اسټیو سره راځي. کنټرولر د ډیفالټ لخوا سایډ کارونه انجیکشن کوي ​​کله چې د نوم ځای کې شارټ کټ شتون ولري 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

د اتوماتیک لینکرډ ګمارل تنظیم کول

د لینکرډ سایډ کار ایمبیډینګ تنظیم کولو لپاره ، موږ تشریحات کاروو (ما دوی په لاسي ډول د دې له لارې اضافه کړل 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

د اسټیو غلطی زغم سمیلیټر

موږ د اشتیو په نوم د غلطۍ زغم سمیلیټر جوړ کړی ترڅو د Shopify لپاره ځانګړي ترافیک تجربه کړي. موږ یوې وسیلې ته اړتیا درلوده ترڅو دودیز ټوپولوژي رامینځته کړو چې زموږ د خدماتو ګراف یوه ځانګړې برخه نمایندګي وکړي ، په متحرک ډول د ځانګړي کاري بارونو ماډل کولو لپاره تنظیم شوي.

د Shopify زیربنا د فلش پلور پرمهال د ډیر بار لاندې ده. په ورته وخت کې، Shopify پلورونکو ته وړاندیز کوي چې دا ډول پلور ډیر ځله ترسره کړي. لوی پیرودونکي ځینې وختونه د پلان شوي فلش پلور په اړه خبرداری ورکوي. نور یې د ورځې یا شپې په هر وخت کې زموږ لپاره په غیر متوقع ډول ترسره کوي.

موږ غوښتل زموږ د انعطاف سمیلیټر د کاري فلو ماډل کړي چې د ټوپولوژیو او کاري بارونو سره سمون خوري چې په تیرو کې یې د Shopify زیربنا له پامه غورځولې. د خدماتو میش کارولو اصلي هدف دا دی چې موږ د شبکې په کچه د اعتبار او غلطۍ زغم ته اړتیا لرو، او دا زموږ لپاره مهمه ده چې د خدماتو میش په مؤثره توګه د هغو بارونو سره مقابله وکړي چې مخکې خدمتونه ګډوډ کړي.

د غلطۍ زغم سمیلیټر په زړه کې د کارګر نوډ دی، کوم چې د خدمت میش نوډ په توګه کار کوي. د کارګر نوډ په پیل کې یا په متحرک ډول د REST API له لارې تنظیم کیدی شي. موږ د کارګر نوډونو متحرک ترتیب کاروو ترڅو د ریګریشن ازموینو په بڼه د کاري جریان رامینځته کړي.

دلته د داسې پروسې یوه بیلګه ده:

• موږ د 10 سرورونه په توګه پیل کوو bar خدمت چې ځواب بیرته راولي 200/OK د 100 ms وروسته
• موږ 10 پیرودونکي پیل کوو - هر یو په هره ثانیه کې 100 غوښتنې لیږي bar.
• په هرو 10 ثانیو کې موږ 1 سرور لرې کوو او غلطۍ څارو 5xx په مشتري باندې.

د کاري جریان په پای کې، موږ لاګونه او میټریک معاینه کوو او وګورو چې ایا ازموینه تیره شوې. پدې توګه موږ د خپل خدمت میش د فعالیت په اړه زده کوو او د غلطۍ زغم په اړه زموږ انګیرنې ازموینې لپاره د راجسټریشن ازموینه ترسره کوو.

(یادونه: موږ د اسټیو غلطی زغم سمیلیټر خلاص سرچینه کولو په اړه فکر کوو ، مګر لاهم دې ته چمتو نه یو.)

د خدمت میش بنچمارک لپاره د اسټیو غلطی زغم سمیلیټر

موږ د سمیلیټر څو کاري نوډونه تنظیم کړل:

• irs-client-loadgen: 3 نقلونه چې په هره ثانیه کې 100 غوښتنې لیږي irs-client.
• irs-client: 3 نقلونه چې غوښتنه ترلاسه کوي، 100ms انتظار وکړئ او غوښتنه یې واستوئ irs-server.
• irs-server: 3 نقلونه چې بیرته راګرځي 200/OK د 100 ms وروسته

د دې ترتیب سره، موږ کولی شو د 9 پای نقطو ترمنځ د باثباته ترافیک جریان اندازه کړو. سایډکارونه دننه irs-client-loadgen и irs-server په هره ثانیه کې 100 غوښتنې ترلاسه کړئ، او irs-client - 200 (راتلونکی او بهر روان).

موږ له لارې د سرچینو کارول تعقیب کوو DataDogځکه چې موږ د پرومیتیوس کلستر نلرو.

پایلې

د کنټرول پینلونه

لومړی، موږ د CPU مصرف معاینه کړ.

د لینکرډ کنټرول پینل ~ 22 ملی کور

د اسټیو کنټرول پینل: ~ 750 ملی کور

د اسټیو کنټرول پینل نږدې کاروي 35 ځله د CPU سرچینېد لینکرډ په پرتله. البته، هرڅه د ډیفالټ لخوا نصب شوي، او istio-telemetry دلته د پروسیسر ډیری سرچینې مصرفوي (دا د ځینو دندو غیر فعالولو سره غیر فعال کیدی شي). که موږ دا برخه لیرې کړو، موږ لاهم له 100 ملیکورونو څخه ډیر ترلاسه کوو، دا دی 4 ځله نورد لینکرډ په پرتله.

Sidecar پراکسي

موږ بیا د پراکسي کارولو ازموینه وکړه. د غوښتنو شمیر سره باید یو خطي اړیکه وي، مګر د هر سایډ کار لپاره یو څه سر شتون لري چې وکر اغیزه کوي.

لینکرډ: ~ 100 ملیکورونه د IRs- مراجعینو لپاره، ~ 50 ملیکورونه د IRs- مراجعینو لپاره

پایلې منطقي ښکاري، ځکه چې د پیرودونکي پراکسي د loadgen پراکسي په پرتله دوه چنده ډیر ټرافیک ترلاسه کوي: د لوډجن څخه د هرې بهر وتلو غوښتنې لپاره، پیرودونکي یو راتلونکی او یو بهر ته ځي.

Istio/Envoy: ~ 155 ملیکورونه د IRs- مراجعینو لپاره، ~ 75 ملیکورونه د IRs- مراجعینو لپاره

موږ د Istio sidecars لپاره ورته پایلې ګورو.

مګر په عموم کې، Istio/Envoy پراکسي مصرفوي نږدې 50٪ نور CPU سرچینېد لینکرډ په پرتله.

موږ د سرور اړخ کې ورته سکیم ګورو:

لینکرډ: د IRS-سرور لپاره ~ 50 ملیکور

Istio/Envoy: ~80 ملیکور د IRS-سرور لپاره

د سرور اړخ کې ، سایډ کار اسټیو / سفیر مصرفوي نږدې 60٪ نور CPU سرچینېد لینکرډ په پرتله.

پایلې

د Istio Envoy پراکسي زموږ په سمول شوي کاري بار کې د Linkerd په پرتله 50+٪ ډیر CPU مصرفوي. د لینکرډ کنټرول پینل د اسټیو په پرتله خورا لږ سرچینې مصرفوي ، په ځانګړي توګه د اصلي برخو لپاره.

موږ لاهم په دې فکر کوو چې دا لګښتونه څنګه کم کړو. که نظر لرئ نو راسره یې شریک کړئ!

سرچینه: www.habr.com