إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يتم تقسيم الوظيفة الإضافية الشبكات الخدمة المستندة إلى 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 |
|---|---|---|---|---|
| 1 | -- | 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 |
|---|---|---|---|---|
| 1 | -- | 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 |
وحدة المعالجة المركزية والذاكرة
| مورد | تراكب 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.
- مسار نسبة استخدام الشبكة الجانبية: العميل --> client-sidecar --> server-sidecar --> server
- مسار نسبة استخدام الشبكة الأساسي: العميل -> الخادم
يمكن العثور على مقارنة بين أداء زمن انتقال مستوى البيانات عبر الوظيفة الإضافية Istio وإصدارات AKS هنا.
| تراكب Azure CNI | تراكب Azure CNI مع Cilium |
|---|---|
|
|
|
|
تغير الحجم
تخصيص التدرج التلقائي للأفقي (HPA) في الوحدة
يتم تمكين التحجيم التلقائي للجراب الأفقي (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}}'
إشعار
راجع وثائق ترقية الوظيفة الإضافية Istio للحصول على تفاصيل حول كيفية تطبيق إعدادات HPA عبر كلا المراجعتين أثناء ترقية الكناري.
إدخال الخدمة
يتيح تعريف المورد المخصص ServiceEntry الخاص ب Istio إضافة خدمات أخرى إلى سجل الخدمة الداخلية ل Istio.
تسمح ServiceEntry للخدمات الموجودة بالفعل في الشبكة بتوجيه الخدمات المحددة أو الوصول إليها. ومع ذلك، يمكن أن يؤدي تكوين ServiceEntries المتعددة مع resolution تعيين الحقل إلى DNS إلى تحميل ثقيل على خوادم نظام أسماء المجالات (DNS). يمكن أن تساعد الاقتراحات التالية في تقليل الحمل:
- قم بالتبديل إلى
resolution: NONEلتجنب عمليات بحث DNS الوكيلة بالكامل. مناسب لمعظم حالات الاستخدام. ومع ذلك، عند استخدام بوابة خروج الوظيفة الإضافية Istio، يجب تعيين دقة ServiceEntry إلىDNS. - زيادة TTL (مدة البقاء) إذا كنت تتحكم في المجالات التي يتم حلها.
- حدد نطاق ServiceEntry باستخدام
exportTo.