انتشار الكناري في Kubernetes # 3: Istio

استخدام Istio+Kiali لإطلاق عملية نشر Canary وتصورها

المقالات في هذه السلسلة

1. نشر الكناري في Kubernetes #1: Gitlab CI
2. نشر Canary في Kubernetes #2: طرح Argo
3. (هذا المقال)
4. نشر الكناري باستخدام Jenkins-X Istio Flagger

انتشار الكناري

نأمل أن تقرأ الجزء الاول، حيث شرحنا بإيجاز ماهية عمليات نشر Canary وأظهرنا كيفية تنفيذها باستخدام موارد Kubernetes القياسية.

Istio

ونحن نفترض أنه من خلال قراءة هذا المقال فإنك تعرف بالفعل ما هو Istio. إذا لم يكن الأمر كذلك، فيمكنك أن تقرأ عنها هنا.

تطبيق للاختبارات

تحتوي كل حاوية على حاويتين: التطبيق الخاص بنا والوكيل istio.

سوف نستخدم تطبيق اختبار بسيط مع pods python للواجهة الأمامية وnginx للواجهة الخلفية. ستعمل حجرة nginx ببساطة على إعادة توجيه كل طلب إلى حجرة الواجهة الخلفية وتعمل كوكيل. يمكن العثور على التفاصيل في yamls التالية:

• frontend.yaml
• backend.yaml
• istio.yaml

تشغيل تطبيق الاختبار بنفسك

إذا كنت ترغب في اتباع المثال الخاص بي واستخدام تطبيق الاختبار هذا بنفسك، فانظر التمهيدي للمشروع.

النشر الأولي

عندما نطلق أول عملية نشر، نرى أن كبسولات تطبيقنا تحتوي على حاويتين فقط، أي أن Istio Sidecar قيد التنفيذ للتو:

ونرى أيضًا Istio Gateway Loadbalancer في مساحة الاسم istio-system:

توليد حركة المرور

سنستخدم عنوان IP التالي لإنشاء حركة المرور التي سيتم استقبالها بواسطة كبسولات الواجهة الأمامية وإعادة توجيهها إلى كبسولات الواجهة الخلفية:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

وسوف نضيف أيضا frontend.istio-test إلى ملف المضيفين لدينا.

عرض مش عبر كيالي

لقد قمنا بتثبيت تطبيق الاختبار وIstio مع Tracing وGrafana وPrometheus وKiali (انظر أدناه للحصول على التفاصيل). التمهيدي للمشروع). لذلك يمكننا استخدام كيالي عبر:

istioctl dashboard kiali # admin:admin

يتصور Kiali حركة المرور الحالية من خلال Mesh

كما نرى، فإن 100% من حركة المرور تذهب إلى خدمة الواجهة الأمامية، ثم إلى كبسولات الواجهة الأمامية ذات التسمية v1، نظرًا لأننا نستخدم وكيل nginx البسيط الذي يعيد توجيه الطلبات إلى خدمة الواجهة الخلفية، والتي بدورها تعيد توجيهها إلى حاضنات الواجهة الخلفية مع التسمية v1.

يعمل Kiali بشكل رائع مع Istio ويوفر حل عرض شبكي محاصر. رائعا.

انتشار الكناري

تحتوي الواجهة الخلفية لدينا بالفعل على عمليتي نشر لـ k8s، واحدة للإصدار 1 والأخرى للإصدار 2. الآن نحتاج فقط إلى إخبار Istio بإعادة توجيه نسبة معينة من الطلبات إلى الإصدار 2.

الخطوة 1: 10%

وكل ما يتعين علينا القيام به هو ضبط وزن VirtualService istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

نرى أنه تتم إعادة توجيه 10% من الطلبات إلى الإصدار 2.

الخطوة 2: 50%

والآن يكفي زيادتها إلى 50٪:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

الخطوة 3: 100%

الآن يمكن اعتبار نشر Canary مكتملًا ويتم إعادة توجيه كل حركة المرور إلى الإصدار 2:

اختبار الكناري يدويا

لنفترض أننا نرسل الآن 2% من جميع الطلبات إلى الواجهة الخلفية v10. ماذا لو أردنا اختبار الإصدار الثاني يدويًا للتأكد من أن كل شيء يعمل كما نتوقع؟

يمكننا إضافة قاعدة مطابقة خاصة بناءً على رؤوس HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

الآن باستخدام حليقة يمكننا فرض طلب v2 عن طريق إرسال الرأس:

ستظل الطلبات التي لا تحتوي على رأس مدفوعة بنسبة 1/10:

كناري لنسختين تابعتين

سننظر الآن في الخيار الذي لدينا فيه الإصدار v2 لكل من الواجهة الأمامية والخلفية. بالنسبة لكليهما، حددنا أن 10% من حركة المرور يجب أن تذهب إلى الإصدار 2:

نرى أن كلا من الواجهة الأمامية v1 وv2 عبارة عن حركة مرور أمامية بنسبة 1/10 إلى الواجهة الخلفية v1 وv2.

ماذا لو كنا بحاجة إلى إعادة توجيه حركة المرور من الواجهة الأمامية v2 فقط إلى الواجهة الخلفية v2 لأنها غير متوافقة مع الإصدار 1؟ للقيام بذلك، سنقوم بتعيين نسبة 1/10 للواجهة الأمامية، والتي تتحكم في حركة المرور التي تصل إلى الواجهة الخلفية v2 باستخدام التفاوض sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

ونتيجة لذلك، نحصل على ما نحتاجه:

الاختلافات عن نهج الكناري اليدوي

В الجزء الأول لقد أجرينا نشر Canary يدويًا، باستخدام عمليتي نشر k8s أيضًا. هناك قمنا بالتحكم في نسبة الطلبات عن طريق تغيير عدد النسخ المتماثلة. هذا النهج ناجح، ولكن له عيوب خطيرة.

يجعل Istio من الممكن تحديد نسبة الطلبات بغض النظر عن عدد النسخ المتماثلة. هذا يعني، على سبيل المثال، أنه يمكننا استخدام HPAs (Horizontal Pod Autoscalers) ولا نحتاج إلى تكوينها وفقًا للحالة الحالية لنشر Canary.

مجموع

يعمل Istio بشكل رائع واستخدامه مع Kiali يشكل مزيجًا قويًا للغاية. التالي في قائمة اهتماماتي هو الجمع بين Spinnaker وIstio للأتمتة وتحليلات Canary.

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