أداء الوظيفة الإضافية ل Istio service mesh والتحجيم
يتم تقسيم الوظيفة الإضافية الشبكات الخدمة المستندة إلى Istio منطقيا إلى مستوى تحكم (istiod
) ولوحة بيانات. تتكون وحدة البيانات من وكلاء Envoy sidecar داخل جرابات حمل العمل. تدير Istiod وكلاء Envoy هذه وتكونها. تعرض هذه المقالة أداء كل من وحدة التحكم والبيانات لمراجعة asm-1-19، بما في ذلك استهلاك الموارد وسعة sidecar ونفقات زمن الانتقال. بالإضافة إلى ذلك، فإنه يوفر اقتراحات لمعالجة الضغط المحتمل على الموارد خلال فترات الحمل الثقيل. تتناول هذه المقالة أيضا كيفية تخصيص التحجيم لمستوى التحكم والبوابات.
أداء وحدة التحكم
ترتبط متطلبات وحدة المعالجة المركزية والذاكرة الخاصة ب Istiod بمعدل تغييرات التوزيع والتكوين وعدد الوكلاء المتصلين. كانت السيناريوهات التي تم اختبارها هي:
- Pod churn: يفحص تأثير churning على
istiod
. لتقليل المتغيرات، يتم استخدام خدمة واحدة فقط لجميع العلامات الجانبية. - خدمات متعددة: يفحص تأثير الخدمات المتعددة على الحد الأقصى للسلع الجانبية التي يمكن أن تديرها Istiod (سعة sidecar)، حيث تحتوي كل خدمة على
N
سيارة جانبية، ما يصل إلى الحد الأقصى الإجمالي.
اختبار المواصفات
- مثيل واحد
istiod
مع إعدادات افتراضية - تعطيل التحجيم التلقائي للجراب الأفقي
- تم اختباره باستخدام مكونين إضافيين للشبكة: تراكب واجهة شبكة حاويات Azure (CNI) وتراكب Azure CNI مع Cilium (مكونات الشبكة الإضافية الموصى بها للمجموعات واسعة النطاق)
- Node SKU: Standard D16 v3 (16 vCPU، ذاكرة 64 غيغابايت)
- إصدار Kubernetes: 1.28.5
- مراجعة Istio: asm-1-19
جرة جراب
تم استخدام إطار عمل ClusterLoader2 لتحديد الحد الأقصى لعدد السيارات الجانبية التي يمكن أن تديرها Istiod عندما يكون هناك خسارة جانبية. يتم تعريف النسبة المئوية للخسارة على أنها النسبة المئوية للسوافل الجانبية المتراجعة/الأعلى أثناء الاختبار. على سبيل المثال، 50٪ من الهزال ل 10,000 سيارة جانبية يعني أن 5,000 سيارة جانبية تم تصغيرها، ثم 5,000 سيارة جانبية تم تصغيرها. تم تحديد نسب الهزال التي تم اختبارها من النسبة المئوية للخسارة النموذجية أثناء إطلاق النشر (maxUnavailable
). تم حساب معدل الخفض عن طريق تحديد العدد الإجمالي للسواكر الجانبية المهتزة (لأعلى ولأسفل) على مدى الوقت الفعلي المستغرق لإكمال عملية الخفض.
سعة Sidecar ووحدة المعالجة المركزية Istiod والذاكرة
تراكب Azure CNI
خسارة (٪) | معدل الخفض (سيارة جانبية/ثانية) | سعة Sidecar | ذاكرة Istiod (GB) | وحدة المعالجة المركزية Istiod |
---|---|---|---|---|
0 | -- | 25000 | 32.1 | 15 |
25 | 31.2 | 15000 | 22.2 | 15 |
50 | 31.2 | 15000 | 25.4 | 15 |
تراكب Azure CNI مع Cilium
خسارة (٪) | معدل الخفض (سيارة جانبية/ثانية) | سعة Sidecar | ذاكرة Istiod (GB) | وحدة المعالجة المركزية Istiod |
---|---|---|---|---|
0 | -- | 30000 | 41.2 | 15 |
25 | 41.7 | 25000 | 36.1 | 16 |
50 | 37.9 | 25000 | 42.7 | 16 |
خدمات متعددة
تم استخدام إطار عمل ClusterLoader2 لتحديد الحد الأقصى لعدد السيارات الجانبية التي istiod
يمكن إدارتها مع 1000 خدمة. يمكن مقارنة النتائج باختبار خسارة 0٪ (خدمة واحدة) في سيناريو خسارة الجراب. تحتوي N
كل خدمة على سيارة جانبية تساهم في الحد الأقصى الإجمالي لعدد السيارات الجانبية. تمت ملاحظة استخدام موارد خادم API لتحديد ما إذا كان هناك أي ضغط كبير من الوظيفة الإضافية.
سعة Sidecar
تراكب Azure CNI | تراكب Azure CNI مع Cilium |
---|---|
20000 | 20000 |
وحدة المعالجة المركزية والذاكرة
Resource | تراكب Azure CNI | تراكب Azure CNI مع Cilium |
---|---|---|
ذاكرة خادم API (GB) | 38.9 | 9.7 |
وحدة المعالجة المركزية لخادم API | 6.1 | 4.7 |
ذاكرة Istiod (GB) | 40.4 | 42.6 |
وحدة المعالجة المركزية Istiod | 15 | 16 |
أداء مستوى البيانات
تؤثر عوامل مختلفة على أداء sidecar مثل حجم الطلب وعدد مؤشرات ترابط العامل الوكيل وعدد اتصالات العميل. بالإضافة إلى ذلك، أي طلب يتدفق عبر الشبكة يجتاز الوكيل من جانب العميل ثم الوكيل من جانب الخادم. لذلك، يتم قياس زمن الانتقال واستهلاك الموارد لتحديد أداء مستوى البيانات.
Fortio
تم استخدام لإنشاء التحميل. أجري الاختبار مع مستودع معيار Istio الذي تم تعديله للاستخدام مع الوظيفة الإضافية.
اختبار المواصفات
- اختبار مع اثنين من المكونات الإضافية للشبكة: تراكب Azure CNI وتراكب Azure CNI مع Cilium (مكونات الشبكة الموصى بها للمجموعات واسعة النطاق)
- Node SKU: Standard D16 v5 (16 vCPU، ذاكرة 64 غيغابايت)
- إصدار Kubernetes: 1.28.5
- عاملان وكيلان
- حمولة 1 كيلوبايت
- 1000 استعلامات في الثانية (QPS) في اتصالات عميل مختلفة
http/1.1
البروتوكول وأمان طبقة النقل المتبادل (TLS) ممكن- 26 نقطة بيانات تم جمعها
وحدة المعالجة المركزية والذاكرة
الذاكرة واستخدام وحدة المعالجة المركزية لكل من وكيل العميل والخادم ل 16 اتصال عميل و1000 QPS عبر جميع سيناريوهات المكون الإضافي للشبكة هو ما يقرب من 0.4 vCPU و72 ميغابايت.
زمن الانتقال
يجمع وكيل sidecar Envoy بيانات القياس عن بعد الأولية بعد الاستجابة للعميل، والتي لا تؤثر مباشرة على إجمالي وقت المعالجة للطلب. ومع ذلك، تؤخر هذه العملية بدء معالجة الطلب التالي، مما يساهم في أوقات انتظار الانتظار والتأثير على متوسط زمن الانتقال ووقت الاستجابة. اعتمادا على نمط حركة المرور، يختلف زمن انتقال الذيل الفعلي.
تقيم النتائج التالية تأثير إضافة وكلاء sidecar إلى مسار البيانات، مع عرض زمن انتقال P90 وP99.
تراكب Azure CNI | تراكب Azure CNI مع Cilium |
---|---|
تغير الحجم
التحجيم التلقائي للجراب الأفقي
يتم تمكين التحجيم التلقائي للجراب الأفقي (HPA) لقرون istiod
بوابة الدخول و. التكوينات الافتراضية ل istiod
والبوابات هي:
- الحد الأدنى للنسخ المتماثلة: 2
- الحد الأقصى للنسخ المتماثلة: 5
- استخدام وحدة المعالجة المركزية: 80٪
إشعار
لمنع التعارضات مع PodDisruptionBudget
، لا تسمح الوظيفة الإضافية بتعيين minReplicas
الإعداد الافتراضي الأولي أدناه ل 2
.
فيما يلي istiod
موارد HPA لبوابة الدخول و:
NAMESPACE NAME REFERENCE
aks-istio-ingress aks-istio-ingressgateway-external-asm-1-19 Deployment/aks-istio-ingressgateway-external-asm-1-19
aks-istio-ingress aks-istio-ingressgateway-internal-asm-1-19 Deployment/aks-istio-ingressgateway-internal-asm-1-19
aks-istio-system istiod-asm-1-19 Deployment/istiod-asm-1-19
يمكن تعديل تكوين HPA من خلال التصحيحات والتحرير المباشر. مثال:
kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'
إدخال الخدمة
يتيح تعريف المورد المخصص ServiceEntry الخاص ب Istio إضافة خدمات أخرى إلى سجل الخدمة الداخلية ل Istio. تسمح ServiceEntry للخدمات الموجودة بالفعل في الشبكة بتوجيه الخدمات المحددة أو الوصول إليها. ومع ذلك، يمكن أن يؤدي تكوين ServiceEntries المتعددة مع resolution
تعيين الحقل إلى DNS إلى تحميل ثقيل على خوادم نظام أسماء المجالات (DNS). يمكن أن تساعد الاقتراحات التالية في تقليل الحمل:
- قم بالتبديل إلى
resolution: NONE
لتجنب عمليات بحث DNS الوكيلة بالكامل. مناسب لمعظم حالات الاستخدام. - زيادة TTL (مدة البقاء) إذا كنت تتحكم في المجالات التي يتم حلها.
- حدد نطاق ServiceEntry باستخدام
exportTo
.
Azure Kubernetes Service