Istio ۽ Linkerd لاءِ 🥇CPU استعمال جو معيار

تعارف

اسان اندر آهيون Shopify Istio کي سروس ميش طور مقرر ڪرڻ شروع ڪيو. اصول ۾، سڀ ڪجھ ٺيڪ آهي، سواء هڪ شيء جي: اهو مهانگو آهي.

В شايع ٿيل معيار Istio لاء چوي ٿو:

Istio 1.1 سان، پراکسي لڳ ڀڳ 0,6 vCPUs (ورچوئل ڪور) استعمال ڪري ٿو في 1000 درخواستون في سيڪنڊ.

سروس ميش ۾ پهرين علائقي لاءِ (ڪنيڪشن جي هر پاسي تي 2 پراڪس)، اسان وٽ 1200 ڪور هوندا صرف پراڪسي لاءِ، في سيڪنڊ هڪ ملين درخواستن جي شرح تي. گوگل جي قيمت ڳڻپيندڙ جي مطابق، اهو ڪم ڪري ٿو تقريبن $40/مهينو/ڪور ترتيب ڏيڻ لاءِ n1-standard-64، اهو آهي، اهو علائقو اڪيلو اسان کي 50 هزار ڊالر في مهيني کان وڌيڪ خرچ ڪندو 1 ملين درخواستن في سيڪنڊ لاءِ.

ايوان سم (ايوان سم) بصري مقابلي ۾ سروس ميش گذريل سال دير ڪئي ۽ ميموري ۽ پروسيسر لاءِ ساڳيو واعدو ڪيو ، پر اهو ڪم نه ڪيو:

بظاهر، values-istio-test.yaml سي پي يو جي درخواستن کي سنجيدگي سان وڌائيندو. جيڪڏھن مون پنھنجي رياضي صحيح ڪئي آھي، توھان کي ضرورت آھي اٽڪل 24 CPU ڪور لاءِ ڪنٽرول پينل ۽ 0,5 CPU هر پراکسي لاءِ. مون وٽ ايترو نه آهي. مان ٽيسٽ ورجائيندس جڏهن مون لاءِ وڌيڪ وسيلا مختص ڪيا ويندا.

مان پنهنجي لاءِ ڏسڻ چاهيان ٿو ته Istio جي ڪارڪردگي ٻي اوپن سورس سروس ميش سان ڪيئن آهي: لنڪرڊ.

سروس ميش جي انسٽاليشن

سڀ کان پهريان، مون ان کي ڪلستر ۾ نصب ڪيو سپرگلو:

$ 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 ڇاڪاڻ ته اهو بوٽ اسٽريپنگ سروس ميش کي تمام آسان بڻائي ٿو. مون کي گهڻو ڪجهه نه ڪرڻو پيو. اسان پيداوار ۾ SuperGloo استعمال نه ڪندا آهيون، پر اهو اهڙي ڪم لاء مثالي آهي. مون کي لفظي طور تي استعمال ڪرڻو پيو هر خدمت ميش لاءِ ڪجهه حڪم. مون اڪيلائي لاءِ ٻه ڪلسٽر استعمال ڪيا - هڪ هڪ Istio ۽ Linkerd لاءِ.

تجربو Google Kubernetes Engine تي ڪيو ويو. مون ڪبرنيٽس استعمال ڪيو 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      |
+---------+------------+---------+---------------------------+

حادثو-لوپ ڪجھ منٽ ورتو، ۽ پوءِ ڪنٽرول پينل مستحڪم ٿي ويا.

(نوٽ: SuperGloo صرف هن وقت Istio 1.0.x کي سپورٽ ڪري ٿو. مون Istio 1.1.3 سان تجربو ورجايو، پر ڪو به قابل ذڪر فرق محسوس نه ڪيو.)

Istio خودڪار لڳائڻ جي سيٽنگ

Istio کي انسٽال ڪرڻ لاءِ سائڊ ڪار اينوائي، اسان استعمال ڪريون ٿا سائڊ ڪار انجيڪٽر - MutatingAdmissionWebhook. اسان هن مضمون ۾ ان بابت نه ڳالهائينداسين. مون کي صرف اهو چوڻ ڏيو ته هي هڪ ڪنٽرولر آهي جيڪو سڀني نون پوڊس جي رسائي جي نگراني ڪري ٿو ۽ متحرڪ طور تي هڪ سائڊ ڪار ۽ initContainer شامل ڪري ٿو، جيڪو ڪمن لاء ذميوار آهي. iptables.

اسان Shopify تي لکيو اسان جو پنهنجو رسائي ڪنٽرولر سائڊ ڪارز کي لاڳو ڪرڻ لاءِ ، پر هن معيار لاءِ مون ڪنٽرولر استعمال ڪيو جيڪو Istio سان اچي ٿو. ڪنٽرولر ڊفالٽ طور تي سائڊ ڪارز کي انجيڪشن ڪري ٿو جڏهن نالي جي جڳهه ۾ شارٽ کٽ آهي 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

خودڪار Linkerd جي ترتيب کي ترتيب ڏيڻ

Linkerd sidecar ايمبيڊنگ قائم ڪرڻ لاءِ، اسان تشريحون استعمال ڪريون ٿا (مون انھن کي دستي طور تي شامل ڪيو 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 غلطي رواداري سمائيٽر

اسان هڪ غلطي رواداري سموليٽر ٺاهيو جنهن کي Istio سڏيو ويندو آهي ٽريفڪ سان تجربو ڪرڻ لاءِ Shopify لاءِ منفرد. اسان کي هڪ اوزار جي ضرورت هئي هڪ ڪسٽم ٽوپولوجي ٺاهڻ لاءِ جيڪو اسان جي سروس گراف جي هڪ مخصوص حصي جي نمائندگي ڪندو، متحرڪ طور تي ترتيب ڏنل مخصوص ڪم لوڊ ڪرڻ لاءِ.

Shopify جو انفراسٽرڪچر فليش سيلز دوران وڏي لوڊ هيٺ آهي. ساڳئي وقت، Shopify وڪڻندڙن کي سفارش ڪري ٿو ته اهي وڪرو گهڻو ڪري رکو. وڏا گراهڪ ڪڏهن ڪڏهن هڪ رٿيل فليش سيل جي باري ۾ ڊيڄاريندا آهن. ٻيا اهي غير متوقع طور تي اسان لاءِ ڏينهن يا رات جي ڪنهن به وقت ڪندا آهن.

اسان چاهيون ٿا ته اسان جو لچڪدار سمائيليٽر ماڊل ورڪ فلوز کي ملن جيڪي ٽوپولاجيز ۽ ڪم لوڊ سان ملن ٿا جيڪي ماضي ۾ Shopify جي انفراسٽرڪچر کي ختم ڪري چڪا آهن. سروس ميش استعمال ڪرڻ جو بنيادي مقصد اهو آهي ته اسان کي نيٽ ورڪ جي سطح تي قابل اعتماد ۽ غلطي رواداري جي ضرورت آهي، ۽ اهو اسان لاء اهم آهي ته سروس ميش مؤثر طريقي سان انهن لوڊن کي منهن ڏئي ٿو جيڪي اڳ ۾ خدمتون سرانجام ڏنيون آهن.

غلطي رواداري سمائيٽر جي دل تي هڪ ڪم ڪندڙ نوڊ آهي، جيڪو خدمت ميش نوڊ طور ڪم ڪري ٿو. ڪم ڪندڙ نوڊ مستحڪم طور تي ترتيب ڏئي سگھجي ٿو شروعاتي طور تي يا متحرڪ طور تي REST API ذريعي. اسان ڪم ڪندڙ نوڊس جي متحرڪ ترتيبن کي استعمال ڪندا آهيون ڪم فلوز ٺاهڻ لاءِ ريگريشن ٽيسٽ جي صورت ۾.

هتي اهڙي عمل جو هڪ مثال آهي:

اسان لانچ ڪيو 10 سرور جيئن bar خدمت جيڪو جواب ڏئي ٿو 200/OK 100 ms کان پوء.
اسان 10 ڪلائنٽ لانچ ڪندا آهيون - هر هڪ موڪليندو آهي 100 درخواستون في سيڪنڊ ڏانهن bar.
هر 10 سيڪنڊن ۾ اسان 1 سرور کي هٽايو ۽ غلطي جي نگراني ڪندا آهيون 5xx ڪلائنٽ تي.

ڪم فلو جي آخر ۾، اسان لاگز ۽ ميٽرڪس کي جانچيندا آهيون ۽ چيڪ ڪندا آهيون ته امتحان پاس ٿيو. هي ڪيئن اسان پنهنجي سروس ميش جي ڪارڪردگي جي باري ۾ سکندا آهيون ۽ غلطي رواداري بابت اسان جي مفروضن کي جانچڻ لاءِ ريگريشن ٽيسٽ هلائيندا آهيون.

(نوٽ: اسان Istio غلطي رواداري سمائيٽر کي اوپن سورسنگ بابت سوچي رهيا آهيون، پر اڃا تائين ائين ڪرڻ لاءِ تيار ناهيون.)

Istio غلطي رواداري سمائيٽر سروس ميش بينچ مارڪ لاءِ

اسان سمائيٽر جي ڪيترن ئي ڪم ڪندڙ نوڊس کي سيٽ ڪيو:

irs-client-loadgen: 3 نقلون جيڪي موڪلين ٿيون 100 درخواستون في سيڪنڊ في سيڪنڊ irs-client.
irs-client: 3 replicas جيڪي درخواست وصول ڪن ٿا، 100ms انتظار ڪريو ۽ درخواست کي اڳتي وڌايو irs-server.
irs-server: 3 replicas جيڪي واپسي 200/OK 100 ms کان پوء.

هن ترتيب سان، اسان 9 آخري پوائنٽن جي وچ ۾ مستحڪم ٽرئفڪ جي وهڪري کي ماپ ڪري سگھون ٿا. سائڊ ڪارز ۾ irs-client-loadgen и irs-server 100 درخواستون في سيڪنڊ وصول ڪريو، ۽ irs-client - 200 (ايندڙ ۽ ٻاهر نڪرڻ).

اسان وسيلن جي استعمال ذريعي ٽريڪ ڪندا آهيون DataDogڇاڪاڻ ته اسان وٽ پروميٿيس ڪلستر نه آهي.

نتيجا

ڪنٽرول پينل

پهرين، اسان سي پي يو جي استعمال کي جانچيو.

لنڪرڊ ڪنٽرول پينل ~ 22 مليڪور

Istio ڪنٽرول پينل: ~ 750 مليڪور

Istio ڪنٽرول پينل تقريبا استعمال ڪري ٿو 35 ڀيرا وڌيڪ CPU وسيلنLinkerd کان. يقينن، هر شي ڊفالٽ طور تي نصب ڪئي وئي آهي، ۽ istio-telemetry هتي پروسيسر وسيلن جو تمام گهڻو استعمال ڪري ٿو (اهو ڪجهه افعال کي غير فعال ڪرڻ سان بند ڪري سگهجي ٿو). جيڪڏهن اسان هن جزو کي هٽايو، اسان اڃا تائين 100 مليڪورس کان وڌيڪ حاصل ڪندا آهيون، اهو آهي 4 دفعا وڌيڪLinkerd کان.

سائڊ ڪار پراکسي

اسان وري پراکسي جي استعمال کي آزمايو. درخواستن جي تعداد سان ھڪڙو لڪير تعلق ھئڻ گھرجي، پر ھر سائڊ ڪار لاءِ ڪجھ مٿي آھي جيڪو وکر کي متاثر ڪري ٿو.

لنڪرڊ: ~ 100 مليڪورس irs-ڪلائنٽ لاءِ، ~50 مليڪورس لاءِ IRs-client-loadgen

نتيجا منطقي نظر اچن ٿا، ڇاڪاڻ ته ڪلائنٽ پراکسي لوڊجن پراکسي جي ڀيٽ ۾ ٻه ڀيرا وڌيڪ ٽرئفڪ وصول ڪري ٿي: لوڊجن مان هر نڪرڻ واري درخواست لاءِ، ڪلائنٽ وٽ هڪ ايندڙ ۽ هڪ ٻاهر وڃڻ وارو آهي.

Istio/Envoy: ~ 155 millicores irs-client لاءِ، ~ 75 millicores for irs-client-loadgen

Istio sidecars لاءِ ساڳيا نتيجا ڏسون ٿا.

پر عام طور تي، Istio/Envoy proxies استعمال ڪن ٿا تقريبن 50٪ وڌيڪ سي پي يو وسيلنLinkerd کان.

اسان سرور جي پاسي تي ساڳيو منصوبو ڏسون ٿا:

لنڪرڊ: ~ 50 مليڪور irs-server لاءِ

Istio/Envoy: ~ 80 millicores irs-server لاءِ

سرور جي پاسي، سائڊ ڪار اسٽيو / ايلچي استعمال ڪري ٿو تقريبن 60٪ وڌيڪ سي پي يو وسيلنLinkerd کان.

ٿڪل

Istio Envoy proxy 50+% وڌيڪ CPU استعمال ڪري ٿو Linkerd کان اسان جي ٺهيل ڪم لوڊ تي. Linkerd ڪنٽرول پينل Istio جي ڀيٽ ۾ تمام گهٽ وسيلن کي استعمال ڪري ٿو، خاص طور تي بنيادي اجزاء لاء.

اسان اڃا تائين سوچي رهيا آهيون ته انهن خرچن کي ڪيئن گھٽايو وڃي. جيڪڏهن توهان وٽ خيال آهي، مهرباني ڪري حصيداري ڪريو!

جو ذريعو: www.habr.com

Istio ۽ Linkerd لاءِ سي پي يو جي استعمال جو معيار