معيار استهلاك وحدة المعالجة المركزية لـ Istio و Linkerd

مقدمة

نحن مشتركون شوبيفاي بدأت في نشر Istio كشبكة خدمة. من حيث المبدأ، كل شيء على ما يرام، باستثناء شيء واحد: إنه باهظ الثمن.

В المعايير المنشورة ل Istio يقول:

مع Istio 1.1، يستهلك الوكيل حوالي 0,6 وحدات المعالجة المركزية الافتراضية (النوى الافتراضية) لكل 1000 طلب في الثانية.

بالنسبة للمنطقة الأولى في شبكة الخدمة (2 وكيل على كل جانب من الاتصال)، سيكون لدينا 1200 مركز للوكيل فقط، بمعدل مليون طلب في الثانية. وفقًا لحاسبة التكلفة من Google، تبلغ تكلفة التكوين حوالي 40 دولارًا شهريًا/أساسيًا n1-standard-64أي أن هذه المنطقة وحدها ستكلفنا أكثر من 50 ألف دولار شهريًا لمليون طلب في الثانية.

إيفان سيم (إيفان سيم) مقارنة بصريا تأخرت شبكة الخدمة في العام الماضي ووعدت بنفس الشيء بالنسبة للذاكرة والمعالج، لكنها لم تنجح:

على ما يبدو، فإن value-istio-test.yaml ستؤدي إلى زيادة طلبات وحدة المعالجة المركزية بشكل خطير. إذا قمت بإجراء العمليات الحسابية بشكل صحيح، فستحتاج إلى ما يقرب من 24 مركزًا لوحدة المعالجة المركزية للوحة التحكم و0,5 وحدة معالجة مركزية لكل وكيل. ليس لدي الكثير. سأكرر الاختبارات عندما يتم تخصيص المزيد من الموارد لي.

أردت أن أرى بنفسي مدى تشابه أداء 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. لقد استخدمت 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 |
+---------+--------------+---------+---------------------------+

ثم إستيو:

$ 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

إعداد نشر Linker التلقائي

لإعداد التضمين الجانبي لـ Linkerd، نستخدم التعليقات التوضيحية (لقد أضفتها يدويًا عبر 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 مللي ثانية.
• أطلقنا 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-server تلقي 100 طلب في الثانية، و irs-client - 200 (وارد وصادر).

نحن نتتبع استخدام الموارد من خلال DataDogلأنه ليس لدينا مجموعة بروميثيوس.

النتائج

لوحات التحكم

أولاً، قمنا بفحص استهلاك وحدة المعالجة المركزية.

لوحة تحكم Linkerd ~ 22 ملي كور

لوحة التحكم Istio: ~ 750 ملي كور

تستخدم لوحة التحكم Istio تقريبًا 35 مرة أكثر من موارد وحدة المعالجة المركزيةمن لينكيرد. بالطبع، يتم تثبيت كل شيء بشكل افتراضي، ويستهلك القياس عن بعد الكثير من موارد المعالج هنا (يمكن تعطيله عن طريق تعطيل بعض الوظائف). إذا قمنا بإزالة هذا المكون، فإننا لا نزال نحصل على أكثر من 100 مليكور، أي 4 مرة أكثرمن لينكيرد.

وكيل السيارة الجانبية

ثم قمنا باختبار استخدام الوكيل. يجب أن تكون هناك علاقة خطية مع عدد الطلبات، ولكن لكل عربة جانبية هناك بعض الحمل الذي يؤثر على المنحنى.

Linkerd: ~100 مللي كور لعميل IRS، ~50 مللي كور لعميل IRS-loadgen

تبدو النتائج منطقية، لأن وكيل العميل يتلقى ضعف حركة المرور التي يتلقاها وكيل Loadgen: مقابل كل طلب صادر من Loadgen، يكون لدى العميل واحد وارد وواحد صادر.

Istio/Envoy: ~155 مللي كور لعميل IRS، ~75 مللي كور لعميل IRS-loadgen

نرى نتائج مماثلة لسيارات Istio الجانبية.

ولكن بشكل عام، يستهلك وكلاء Istio/Envoy ما يقرب من 50% المزيد من موارد وحدة المعالجة المركزيةمن لينكيرد.

نرى نفس المخطط على جانب الخادم:

Linkerd: ~50 مللي كور لخادم IRS

Istio/Envoy: ~ 80 مللي كور لخادم IRS

على جانب الخادم، يستهلك الجانبي Istio/Envoy ما يقرب من 60% المزيد من موارد وحدة المعالجة المركزيةمن لينكيرد.

اختتام

يستهلك وكيل Istio Envoy وحدة معالجة مركزية أكثر بنسبة 50+% من Linkerd في عبء العمل الذي تمت محاكاته. تستهلك لوحة التحكم Linkerd موارد أقل بكثير من Istio، خاصة بالنسبة للمكونات الأساسية.

وما زلنا نفكر في كيفية تقليل هذه التكاليف. إذا كان لديك أفكار، يرجى مشاركتها!

المصدر: www.habr.com