مقدمة
نحن في Shopify نقوم بنشر Istio كشبكة خدمة. من حيث المبدأ ، يناسب كل شيء ، باستثناء شيء واحد: أنها مكلفة .
المعايير المنشورة لـ Istio تقول:
مع الإصدار 1.1 من Istio ، يستهلك الوكيل ما يقرب من 0.6 وحدات معالجة فردية (النوى الافتراضية) لكل 1000 طلب في الثانية.
بالنسبة للمنطقة الأولى في شبكة الخدمة (وكيلان على كل جانب من جوانب الاتصال) ، سيكون لدينا 1200 قلب للوكلاء فقط ، بمعدل مليون طلب في الثانية. وفقًا لآلة حاسبة التكلفة من Google ، تحصل على حوالي 40 دولارًا شهريًا / لب التهيئة n1-standard-64 ، أي أن هذه المنطقة وحدها ستكلفنا أكثر من 50000 دولار شهريًا مقابل مليون طلب في الثانية الواحدة.
قارن إيفان سيم ( إيفان سيم ) بوضوح تأخيرات شبكة الخدمة العام الماضي ووعد بنفس الشيء بالنسبة للذاكرة والمعالج ، لكنه فشل:
على ما يبدو ، ستعمل القيم istio-test.yaml على زيادة طلبات المعالج بشكل خطير. إذا قمت بحساب كل شيء بشكل صحيح ، فستحتاج إلى حوالي 24 مركزًا للمعالج في لوحة التحكم و 0.5 وحدة المعالجة المركزية لكل وكيل. ليس لدي الكثير. سأكرر الاختبارات عندما يتم تخصيص المزيد من الموارد لي.
أردت أن أرى بنفسي كيف يتشابه أداء Istio مع شبكة خدمة مفتوحة المصدر أخرى: Linkerd .
تركيب شبكة الخدمة
أول شيء قمت بتثبيته في نظام SuperGloo هو :
$ 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. استخدمت Kubernetes 1.12.7-gke.7 وتجمع العقدة n1-standard-4 مع تحجيم العقدة التلقائي (الحد الأدنى 4 ، 16 كحد أقصى).
ثم قمت بتثبيت كل شبكة الخدمة من سطر الأوامر.
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 | +---------+--------------+---------+---------------------------+
ثم استيو:
$ 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 | +---------+------------+---------+---------------------------+
استغرق Crash-loop عدة دقائق ، ثم استقرت لوحات التحكم.
(ملاحظة: لا يدعم SuperGloo حاليًا الإصدار Istio 1.0.x فقط. كررت التجربة مع الإصدار 1.1.3 من Istio ، لكن لم ألاحظ أي اختلاف ملحوظ.)
إعداد النشر التلقائي لـ Istio
لتثبيت Istio المبعوث الجانبي ، نستخدم حاقن السيارة MutatingAdmissionWebhook - MutatingAdmissionWebhook . لن نتحدث عنه في هذا المقال. لا يمكنني إلا أن أقول إن هذه وحدة تحكم تراقب الوصول إلى جميع الأجهزة الجديدة وتضيف بشكل ديناميكي جهاز جانبي و initContainer ، وهو المسؤول عن مهام iptables .
لقد كتبنا في Shopify جهاز التحكم في الوصول الخاص بنا لتنفيذ السيارة الجانبية ، لكن في هذا الاختبار ، أخذت وحدة التحكم التي تأتي مع Istio. تحقن وحدة التحكم istio-injection: enabled افتراضيا عندما يكون هناك istio-injection: enabled اختصار 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 s ، نستخدم التعليقات التوضيحية (أضفتها يدويًا من خلال 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. نحن نستخدم التوليف الديناميكي لعقد العمل لإنشاء سير عمل في شكل اختبارات الانحدار.
فيما يلي مثال على هذه العملية:
- نبدأ 10 خوادم كخدمة
bar ، والتي تُرجع استجابة 200/OK بعد 100 مللي ثانية. - نبدأ 10 عملاء - يرسل كل منهم 100 طلب في الثانية إلى
bar . - كل 10 ثوانٍ نقوم بإزالة خادم واحد ، نراقب أخطاء
5xx على العميل.
في نهاية سير العمل ، ندرس السجلات والمقاييس ونتحقق من اجتياز الاختبار. هذه هي الطريقة التي نتعلم بها عن أداء شبكة الخدمة الخاصة بنا وإجراء اختبار الانحدار لاختبار افتراضاتنا حول التسامح مع الخطأ.
(ملاحظة: نحن نفكر في فتح الكود المصدري لمحاكي Istio لتحمل الأخطاء ، لكننا لسنا مستعدين له بعد.)
Istio خطأ التسامح محاكاة لمعيار شبكة الخدمة
نقوم بتكوين العديد من عقد عمل جهاز المحاكاة:
irs-client-loadgen : 3 نسخ متماثلة ترسل 100 طلب في الثانية إلى irs-client .irs-client : 3 النسخ المتماثلة التي تتلقى الطلب الانتظار 100 مللي ثانية وإعادة توجيه الطلب إلى irs-server .irs-server : 3 نسخ متماثلة ترجع 200/OK بعد 100 مللي ثانية.
باستخدام هذا التكوين ، يمكننا قياس تدفق حركة مرور ثابت بين 9 نقاط نهاية. تتلقى irs-client-loadgen في irs-client-loadgen و irs-client-loadgen irs-server 100 طلب في الثانية ، و irs-client - 200 (الواردة والصادرة).
نحن نتتبع استخدام الموارد من خلال DataDog لأنه ليس لدينا كتلة بروميثيوس.
النتائج
لوحات التحكم
أولاً ، درسنا استهلاك وحدة المعالجة المركزية.
لوحة التحكم Linkerd ~ 22M
لوحة التحكم Istio: ~ 750 مليون النوى
تستخدم لوحة التحكم Istio ما يقرب من 35 مرة من موارد المعالج أكثر من Linkerd. بالطبع ، يتم ضبط كل شيء افتراضيًا ، ويستهلك القياس عن بُعد الكثير من موارد المعالج (يمكنك تعطيله عن طريق التخلي عن بعض الوظائف). إذا قمت بإزالة هذا المكون ، فلا يزال أكثر من 100 متعدد النواة ، أي 4 مرات أكثر من Linkerd.
وكيل سيديكار
ثم فحصنا استخدام الوكلاء. يجب أن يكون هناك اعتماد خطي على عدد الطلبات ، ولكن لكل جانب جانبي هناك بعض النفقات العامة التي تؤثر على المنحنى.
Linkerd: ~ 100Mnuclear for irs-client، ~ 50Mnuclear for irs-client-loadgen
تبدو النتائج منطقية ، نظرًا لأن وكيل العميل يتلقى ضعف حركة المرور مثل وكيل loadgen: لكل طلب صادر من loadgen ، لدى العميل واحد وارد وواحد.
Istio / Envoy: حوالي 155 مليون من أصحاب الـ IRs ، و حوالي 75 مليون من أصحاب الـ IRs-client-loadgen
نرى نتائج مماثلة لالستديو الجانبي.
لكن بشكل عام ، يستهلك الوكلاء Istio / Envoy موارد المعالج بحوالي 50٪ أكثر من Linkerd.
نرى نفس المخطط على جانب الخادم:
Linkerd: ~ 50 multicore لخادم مصلحة الضرائب
Istio / المبعوث: ~ 80 multicore لخادم مصلحة الضرائب
على جانب الخادم ، يستهلك Istio / Envoy sidecar موارد المعالج بحوالي 60٪ أكثر من Linkerd.
استنتاج
يستهلك وكيل Istio Envoy وحدة المعالجة المركزية بنسبة تزيد عن 50٪ مقارنة بـ Linkerd في عبء العمل المحاكاة. تستهلك لوحة التحكم Linkerd موارد أقل بكثير من Istio ، خاصة بالنسبة للمكونات الرئيسية.
ما زلنا نفكر في كيفية خفض هذه التكاليف. إذا كان لديك أي أفكار ، شارك!