ملاحظة perev. : تم تخصيص الجزء الأول من هذه السلسلة لإدخال Istio وإظهاره في العمل. الآن سنتحدث عن جوانب أكثر تعقيدًا من تكوين واستخدام شبكة الخدمة هذه ، وعلى وجه الخصوص ، حول التوجيه الدقيق وإدارة حركة مرور الشبكة.
نذكرك أيضًا أن المقالة تستخدم تكوينات (تظهر ل Kubernetes و Istio) من مستودع إتقان إتقان . إدارة المرور
مع Istio ، تظهر ميزات جديدة في الكتلة لتوفير:
- توجيه الاستعلام الديناميكي : نشرات الكناري ، اختبار A / B ؛
- تحميل موازنة : بسيطة ومتسقة ، على أساس التجزئة.
- سقوط الانتعاش : المهلات ، إعادة المحاولات ، قواطع الدوائر الكهربائية ؛
- خطأ الإدخال : التأخير ، انقطاع الطلبات ، الخ
في متابعة المقال ، سيتم عرض هذه الميزات كمثال للتطبيق المحدد وسيتم تقديم مفاهيم جديدة على طول الطريق. سيكون أول مفهوم من هذا القبيل هو
DestinationRules (بمعنى القواعد المتعلقة بمستلم حركة المرور / الطلبات - الترجمة تقريبًا) ، والتي
ننشط بها اختبار A / B.
اختبار A / B: DestinationRules في الممارسة
يستخدم اختبار A / B في الحالات التي يوجد فيها نسختان من التطبيق (عادة ما يختلفان بصريًا) ونحن لسنا متأكدين بنسبة 100٪ من الذي سيحسن تفاعل المستخدم. لذلك ، نطلق في وقت واحد كلا الإصدارين ونجمع المقاييس.
لنشر الإصدار الثاني من الواجهة الأمامية اللازمة لإظهار اختبار A / B ، قم بتشغيل الأمر التالي:
$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml deployment.extensions/sa-frontend-green created
يختلف بيان النشر لـ "الإصدار الأخضر" في مكانين:
- تستند الصورة إلى علامة أخرى -
istio-green ، - القرون لديها
version: green التسمية version: green .
نظرًا لأن التطبيقين النشرين لهما
app: sa-frontend تسمية
app: sa-frontend ، سيتم إعادة توجيه الطلبات التي يتم توجيهها بواسطة الخدمة الظاهرية
sa-external-services sa-frontend خدمة
sa-frontend إلى جميع مثيلاتها وسيتم توزيع التحميل باستخدام
خوارزمية round-robin ، والتي ستؤدي إلى الموقف التالي:
الملفات المطلوبة غير موجودةلم يتم العثور على هذه الملفات بسبب حقيقة أنها تسمى بشكل مختلف في إصدارات مختلفة من التطبيق. دعونا نتأكد من هذا:
$ curl --silent http://$EXTERNAL_IP/ | tr '"' '\n' | grep main /static/css/main.c7071b22.css /static/js/main.059f8e9c.js $ curl --silent http://$EXTERNAL_IP/ | tr '"' '\n' | grep main /static/css/main.f87cd8c9.css /static/js/main.f7659dbb.js
هذا يعني أن
index.html ، يطلب إصدارًا واحدًا من الملفات الثابتة ، يمكن إرساله بواسطة موازن التحميل إلى البرامج التي لها إصدار مختلف ، حيث لا توجد مثل هذه الملفات لأسباب واضحة. لذلك ، لكي يعمل التطبيق ، نحتاج إلى وضع قيود: "
يجب أن يخدم نفس الإصدار من التطبيق الذي أعطى index.html أيضًا الطلبات اللاحقة ."
سنحقق الهدف من خلال موازنة تحميل مستندة إلى التجزئة متناسقة
(Consival Hash Loadbalancing) . في هذه الحالة ،
يتم إرسال الطلبات من عميل واحد إلى نفس مثيل الواجهة الخلفية ، والتي تستخدم خاصية محددة مسبقًا - على سبيل المثال ، رأس HTTP. نفذت باستخدام DestinationRules.
DestinationRules
بعد قيام
VirtualService بإرسال طلب إلى الخدمة المطلوبة ، باستخدام DestinationRules ، يمكننا تحديد السياسات التي سيتم تطبيقها على حركة المرور الموجهة لمثيلات هذه الخدمة:
Istio إدارة حركة مرور المواردملاحظة : يتم عرض تأثير موارد Istio على حركة مرور الشبكة هنا بطريقة مبسطة. لكي نكون دقيقين ، يتم اتخاذ القرار بشأن أي مثيل لإرسال الطلب إليه بواسطة Envoy في Ingress Gateway التي تم تكوينها في CRD.
باستخدام قواعد الوجهة ، يمكننا تكوين موازنة التحميل بحيث يتم استخدام تجزئة متناسقة وضمان استجابات نفس مثيل الخدمة للمستخدم نفسه. يسمح التكوين التالي لهذا (
destinationrule-sa-frontend.yaml ) بتحقيق هذا:
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: sa-frontend spec: host: sa-frontend trafficPolicy: loadBalancer: consistentHash: httpHeaderName: version # 1
1 - سيتم إنشاء التجزئة بناءً على محتويات رأس
version HTTP.
قم بتطبيق التكوين باستخدام الأمر التالي:
$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml destinationrule.networking.istio.io/sa-frontend created
الآن قم بتشغيل الأمر أدناه وتأكد من حصولك على الملفات التي تحتاجها عند تحديد رأس
version :
$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' '\n' | grep main
ملاحظة : لإضافة قيم مختلفة في العنوان واختبار النتائج مباشرة في المتصفح ، يمكنك استخدام
هذا الامتداد إلى Chrome
(أو هذا في Firefox - تقريبا - ترجمة.) .
بشكل عام ، تحتوي DestinationRules على المزيد من الخيارات في مجال موازنة التحميل - راجع
الوثائق الرسمية للحصول على التفاصيل.
قبل استكشاف VirtualService أكثر ، سنقوم بإزالة "النسخة الخضراء" من التطبيق والقاعدة المقابلة في اتجاه حركة المرور من خلال تنفيذ الأوامر التالية:
$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml deployment.extensions “sa-frontend-green” deleted $ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml destinationrule.networking.istio.io “sa-frontend” deleted
النسخ المتطابق: الخدمات الافتراضية في الممارسة
يستخدم التظليل
("التدريع") أو النسخ المتطابق
("النسخ المتطابق") في تلك الحالات عندما نرغب في اختبار تغيير في الإنتاج دون التأثير على المستخدمين النهائيين: ولهذا نقوم بتكرار ("النسخ المتطابق") طلبات المثيل الثاني ، حيث يتم إجراء التغييرات اللازمة ، وانظر إلى العواقب.
ببساطة ، هذا هو عندما يختار زميلك (أ) القضية الأكثر أهمية ويقدم طلب سحب في شكل كتلة ضخمة من الأوساخ بحيث لا يستطيع أي شخص أن يجعله في الواقع مراجعة.لاختبار هذا السيناريو أثناء العمل ، قم بإنشاء مثيل آخر لـ SA-Logic مع الأخطاء (
buggy ) عن طريق تشغيل الأمر التالي:
$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml deployment.extensions/sa-logic-buggy created
والآن ننفذ الأمر للتأكد من أن جميع مثيلات
app=sa-logic لها
app=sa-logic تسميات بالإصدارات المقابلة:
$ kubectl get pods -l app=sa-logic --show-labels NAME READY LABELS sa-logic-568498cb4d-2sjwj 2/2 app=sa-logic,version=v1 sa-logic-568498cb4d-p4f8c 2/2 app=sa-logic,version=v1 sa-logic-buggy-76dff55847-2fl66 2/2 app=sa-logic,version=v2 sa-logic-buggy-76dff55847-kx8zz 2/2 app=sa-logic,version=v2
تستهدف
sa-logic السنفات مع
app=sa-logic label ، لذلك سيتم توزيع جميع الطلبات بين جميع الحالات:
... لكننا نريد توجيه الطلبات إلى مثيلات مع الإصدار v1 وعكسها إلى مثيلات مع الإصدار v2:
سوف نحقق ذلك من خلال VirtualService بالاشتراك مع DestinationRule ، حيث ستحدد القواعد المجموعات الفرعية وطرق VirtualService إلى مجموعة فرعية معينة.
تحديد مجموعات فرعية في قواعد الوجهة
يتم تعريف
المجموعات الفرعية بالتكوين التالي (
sa-logic-subsets-destinationrule.yaml ):
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: sa-logic spec: host: sa-logic # 1 subsets: - name: v1 # 2 labels: version: v1 # 3 - name: v2 labels: version: v2
- يحدد
host أن هذه القاعدة تنطبق فقط على الحالات التي يتجه فيها المسار نحو sa-logic ؛ - يتم استخدام أسماء المجموعات الفرعية عند التوجيه إلى مثيلات المجموعة الفرعية ؛
- تحدد التسمية أزواج القيمة الرئيسية التي يجب أن تتطابق معها المثيلات حتى تصبح جزءًا من مجموعة فرعية.
قم بتطبيق التكوين باستخدام الأمر التالي:
$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml destinationrule.networking.istio.io/sa-logic created
الآن وقد تم تعريف المجموعات الفرعية ، يمكنك الانتقال إلى VirtualService وتكوينها لتطبيق القواعد على طلبات المنطق المنطقي بحيث:
- موجه إلى مجموعة فرعية من
v1 ، - معكوسة لمجموعة فرعية من
v2 .
يسمح لك البيان التالي بتحقيق خطتك (
sa-logic-subets-shadowing-vs. yaml ):
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 mirror: host: sa-logic subset: v2
لا يوجد تفسير مطلوب هنا ، لذلك ألقِ نظرة على الإجراء:
$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml virtualservice.networking.istio.io/sa-logic created
أضف الحمل عن طريق استدعاء هذا الأمر:
$ while true; do curl -v http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}'; \ sleep .8; done
دعونا نلقي نظرة على النتائج في Grafana ، حيث يمكننا أن نرى أن نسخة
buggy تعطل حوالي 60 ٪ من الطلبات ، ولكن أيا من هذه الأعطال يؤثر على المستخدمين النهائيين لأن لديهم خدمة عمل.
نجاح استجابات الإصدارات المختلفة من الخدمة المنطقيةلقد رأينا لأول مرة كيف يتم تطبيق VirtualService على مبعوثي خدماتنا: عندما يقدم تطبيق
sa-web-app طلبًا
sa-logic ، فإنه يمر عبر sidecar Envoy ، الذي - من خلال VirtualService - تم تكوينه لتوجيه الطلب إلى المجموعة الفرعية v1 ونسخة طلب إلى مجموعة فرعية من v2 من خدمة
sa-logic .
أعرف: لقد كان لديك بالفعل وقت للتفكير في أن الخدمات الافتراضية بسيطة. في القسم التالي ، قمنا بتوسيع هذا الرأي من خلال حقيقة أنها رائعة حقًا.
لفات الكناري
Canary Deployment هي عملية طرح إصدار جديد من التطبيق لعدد صغير من المستخدمين. يتم استخدامه للتأكد من عدم وجود مشاكل في الإصدار وفقط بعد ذلك ، كونك واثقًا بالفعل من جودته (الإصدار) الكافية ، ليتم توزيعه على جمهور أكبر.
لإظهار نشرات الكناري ، سنواصل العمل مع مجموعة فرعية من
buggy في
sa-logic .
دعونا لا نضيع الوقت في ذلك وأرسل على الفور 20٪ من المستخدمين إلى الإصدار مع الأخطاء (سيمثل هذا الإصدار التجريبي من الكناري) ، ونسبة 80٪ المتبقية إلى الخدمة العادية. للقيام بذلك ، قم بتطبيق VirtualService التالي (
sa-logic-subsets-canary-vs.yaml ):
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 weight: 80 # 1 - destination: host: sa-logic subset: v2 weight: 20 # 1
1 هو الوزن ، الذي يحدد النسبة المئوية للطلبات التي سيتم إرسالها إلى المستلم أو مجموعة فرعية من المستلم.
قم بتحديث تكوين VirtualService السابق لـ
sa-logic الأمر التالي:
$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml virtualservice.networking.istio.io/sa-logic configured
... وشاهد على الفور ذلك الجزء من الطلبات:
$ while true; do \ curl -i http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}' \ --silent -w "Time: %{time_total}s \t Status: %{http_code}\n" \ -o /dev/null; sleep .1; done Time: 0.153075s Status: 200 Time: 0.137581s Status: 200 Time: 0.139345s Status: 200 Time: 30.291806s Status: 500
تقوم VirtualServices بتنشيط نشرات الكناري: في هذه الحالة ، قمنا بتضييق العواقب المحتملة من المشاكل إلى 20٪ من قاعدة المستخدمين. عظيم! الآن ، في كل حالة ، عندما لا نكون متأكدين من الكود لدينا (وبعبارة أخرى ، دائمًا ...) ، يمكننا استخدام النسخ المتطابقة والكناري.
مهلات وإعادة المحاولة
ولكن ليس دائما الخلل في القانون. في قائمة "
8 أخطاء في الحوسبة الموزعة " في المقام الأول يظهر الرأي الخاطئ بأن "الشبكة موثوق بها". في الواقع ، الشبكة غير موثوقة ، ولهذا السبب نحن بحاجة إلى مهل وإعادة
المحاولة .
من أجل العرض التوضيحي ، سنستمر في استخدام نفس الإصدار من
sa-logic (
buggy ) ، وسنقوم بمحاكاة عدم موثوقية الشبكة مع الإخفاقات العشوائية.
اسمح لخدمتنا التي تحتوي على أخطاء الحصول على فرصة 1/3 لاستجابة طويلة جدًا ، و 1/3 لإكمالها باستخدام خطأ خادم داخلي ، و 1/3 لإرجاع صفحة ناجحة.
لتخفيف عواقب هذه المشاكل وجعل الحياة أفضل للمستخدمين ، يمكننا:
- إضافة مهلة إذا كانت الخدمة تستجيب لأكثر من 8 ثوانٍ ،
- أعد المحاولة إذا فشل الطلب.
للتنفيذ ، سوف نستخدم تعريف المورد التالي (
sa-logic-retries-timeouts-vs.yaml ):
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 weight: 50 - destination: host: sa-logic subset: v2 weight: 50 timeout: 8s # 1 retries: attempts: 3 # 2 perTryTimeout: 3s # 3
- تم تعيين مهلة الطلب إلى 8 ثوانٍ ؛
- تتم محاولات الطلب المتكرر 3 مرات ؛
- وتعتبر كل محاولة فاشلة إذا تجاوز زمن الاستجابة 3 ثوانٍ.
لقد حققنا التحسين ، لأن المستخدم لا يضطر إلى الانتظار أكثر من 8 ثوان وسنبذل ثلاث محاولات جديدة للحصول على إجابة في حالة الإخفاقات ، مما يزيد من فرصة استجابة ناجحة.
قم بتطبيق التكوين المحدث باستخدام الأمر التالي:
$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml virtualservice.networking.istio.io/sa-logic configured
وتحقق من الرسوم البيانية لجرافانا أن عدد الإجابات الناجحة قد انتهى:
تحسينات في إحصائيات الاستجابات الناجحة بعد إضافة مهل وإعادة المحاولةقبل الانتقال إلى القسم التالي
(أو بالأحرى ، إلى الجزء التالي من المقالة ، لأنه لن يكون هناك المزيد من التجارب في هذه العملية - الترجمة تقريبًا.) ، احذف
sa-logic-buggy و VirtualService عن طريق تشغيل الأوامر التالية:
$ kubectl delete deployment sa-logic-buggy deployment.extensions “sa-logic-buggy” deleted $ kubectl delete virtualservice sa-logic virtualservice.networking.istio.io “sa-logic” deleted
قواطع الدائرة وأنماط الحاجز
نحن نتحدث عن نموذجين مهمين في هندسة الخدمات المصغرة التي تتيح لك تحقيق خدمات
الشفاء الذاتي .
تُستخدم قواطع الدائرة ("قاطع الدائرة") لإيقاف الطلبات التي تصل إلى مثيل خدمة تعتبر غير صحية واستعادتها بينما تتم إعادة توجيه طلبات العميل إلى حالات صحية لهذه الخدمة (مما يزيد من نسبة الاستجابات الناجحة).
(ملاحظة: يمكن العثور على وصف أكثر تفصيلاً للنمط ، على سبيل المثال ، هنا .)الحاجز ("التقسيم") يعزل فشل الخدمة عن هزيمة النظام بأكمله. على سبيل المثال ، الخدمة B مقطوعة ، وتقدم خدمة أخرى (عميل الخدمة B) طلبًا للخدمة B ، ونتيجة لذلك ، ستستخدم تجمع مؤشرات الترابط الخاص بها ولن تتمكن من تقديم طلبات أخرى (حتى إذا لم تكن مرتبطة بالخدمة B).
(ملاحظة: يمكن العثور على وصف أكثر تفصيلاً للنمط ، على سبيل المثال ، هنا .)سأحذف التفاصيل المتعلقة بتنفيذ هذه الأنماط ، لأنه يسهل العثور عليها في
الوثائق الرسمية ، وأريد حقًا إظهار المصادقة والترخيص ، والتي سيتم مناقشتها في الجزء التالي من المقالة.
PS من المترجم
اقرأ أيضًا في مدونتنا: