استراتيجيات نشر 🥇Kubernetes: التدحرج ، وإعادة الإنشاء ، والأزرق / الأخضر ، والكناري ، والظلام (اختبار A / B)

ملحوظة. ترجمة: تقدم هذه الإرشادات التفصيلية من Weaveworks أكثر استراتيجيات طرح التطبيقات شيوعًا وكيف يمكنك تنفيذ أكثرها تقدمًا باستخدام مشغل Flagger Kubernetes. إنه مكتوب بلغة بسيطة ويحتوي على مخططات مرئية تسمح حتى للمهندسين المبتدئين بفهم المشكلة.

رسم تخطيطي مأخوذ من مراجعة أخرى إستراتيجيات الإطلاق التي تم إجراؤها في "حلول الحاويات"

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

تتمتع عمليات النشر الأقصر والأكثر تكرارًا بالمزايا التالية:

تقليل وقت الوصول إلى السوق.
الميزات الجديدة تصل إلى المستخدمين بشكل أسرع.
تصل ملاحظات المستخدم إلى فريق التطوير بشكل أسرع. هذا يعني أن الفريق يمكنه إضافة ميزات وإصلاح المشكلات بسرعة أكبر.
يحسن معنويات المطورين: المزيد من الميزات قيد التطوير هي أكثر متعة في العمل معها.

ولكن مع زيادة تكرار الإصدار ، تزداد أيضًا فرص التأثير سلبًا على موثوقية التطبيق أو تجربة المستخدم. هذا هو السبب في أنه من المهم لفرق العمليات و DevOps بناء العمليات وإدارة استراتيجيات النشر بطريقة تقلل من المخاطر التي يتعرض لها المنتج والمستخدمون. (لمعرفة المزيد حول أتمتة خط أنابيب CI / CD ، راجع هنا.)

في هذا المنشور ، سنناقش العديد من استراتيجيات نشر Kubernetes ، بما في ذلك عمليات النشر المتجددة والأساليب الأكثر تقدمًا مثل إصدارات الكناري وتنوعاتها.

استراتيجيات النشر

هناك عدة أنواع مختلفة من استراتيجيات النشر التي يمكن استخدامها حسب الغرض. على سبيل المثال ، قد تحتاج إلى إجراء تغييرات على بعض البيئات لإجراء مزيد من الاختبارات ، أو على مجموعة فرعية من المستخدمين / العملاء ، أو قد تحتاج إلى إجراء اختبار محدود على المستخدمين قبل إنشاء ميزة عام.

المتداول (النشر التدريجي والمتداول)

هذه هي إستراتيجية النشر القياسية لـ Kubernetes. تدريجيًا ، واحدًا تلو الآخر ، يستبدل البودات بالإصدار القديم من التطبيق بالنسخة الجديدة - دون توقف الكتلة.

تنتظر Kubernetes أن تكون البودات الجديدة جاهزة للانطلاق (تفحصها باستخدام اختبارات الاستعداد) قبل الشروع في نشمر القديمة. في حالة حدوث مشكلة ، يمكن إحباط مثل هذا التحديث المتداول دون إيقاف المجموعة بأكملها. في ملف YAML من نوع النشر ، تحل الصورة الجديدة محل الصورة القديمة:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

يمكن تحديد معلمات التحديث المتداول في ملف البيان:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

إعادة (إعادة الخلق)

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

يبدو البيان المطابق مشابهًا لما يلي:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

أزرق / أخضر (عمليات النشر باللون الأزرق والأخضر)

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

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

بعد اختبار الإصدار الأزرق (الجديد) والموافقة عليه للإصدار ، يتم تحويل الخدمة إليه ، ويتم تصغير اللون الأخضر (القديم):

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

الكناري (عمليات نشر الكناري)

تتشابه عمليات إطلاق Canary مع اللون الأزرق والأخضر ، ولكن يتم التحكم فيها واستخدامها بشكل أفضل تدريجي نهج خطوة بخطوة. تندرج العديد من الاستراتيجيات المختلفة في هذه الفئة ، بما في ذلك عمليات الإطلاق السرية واختبار A / B.

تُستخدم هذه الإستراتيجية عند الحاجة إلى اختبار بعض الوظائف الجديدة ، عادةً في الواجهة الخلفية للتطبيق. يتمثل جوهر النهج في إنشاء خادمين متطابقين تقريبًا: أحدهما يخدم جميع المستخدمين تقريبًا ، والآخر ، بميزات جديدة ، يخدم فقط مجموعة فرعية صغيرة من المستخدمين ، وبعد ذلك تتم مقارنة نتائج عملهم. إذا سارت الأمور دون أخطاء ، فسيتم تعميم الإصدار الجديد تدريجيًا على البنية التحتية بأكملها.

على الرغم من أنه يمكن تنفيذ هذه الإستراتيجية حصريًا باستخدام Kubernetes ، واستبدال القرون القديمة بأخرى جديدة ، إلا أنه من الأسهل استخدام شبكة خدمة مثل Istio.

على سبيل المثال ، قد يكون لديك مانيفستان مختلفان لـ Git: أحدهما عادي بعلامة 0.1.0 وآخر كناري بعلامة 0.2.0. من خلال تغيير الأوزان في بيان Istio Virtual Gateway ، يمكنك التحكم في توزيع حركة المرور بين عمليتي النشر هاتين:

يمكن العثور على دليل خطوة بخطوة لتنفيذ عمليات نشر الكناري باستخدام Istio في مهام سير عمل GitOps مع Istio. (ملحوظة. ترجمة.: قمنا أيضًا بترجمة مادة حول إطلاق الكناري في Istio هنا.)

عمليات نشر Canary باستخدام Weaveworks Flagger

Weaveworks فلاغر يسمح بالتحكم السهل والفعال في لفائف الكناري.

يقوم Flagger بأتمتة العمل معهم. يستخدم Istio أو AWS App Mesh لتوجيه حركة المرور وتبديلها ، ومقاييس Prometheus لتحليل النتائج. بالإضافة إلى ذلك ، يمكن استكمال تحليل عمليات نشر الكناري بخطافات الويب لإجراء اختبارات القبول واختبارات التحميل وأي أنواع أخرى من الفحوصات.

استنادًا إلى نشر Kubernetes ، وإذا لزم الأمر ، وحدات التخزين (HPA) ، يُنشئ Flagger مجموعات من الكائنات (عمليات نشر Kubernetes وخدمات ClusterIP وخدمات Istio أو App Mesh الافتراضية) لتحليل عمليات النشر الكناري وتنفيذها:

تنفيذ حلقة التحكم (حلقة السيطرة)يقوم Flagger بتحويل حركة المرور تدريجيًا إلى خادم كناري أثناء قياس مقاييس الأداء الرئيسية مثل معدل نجاح طلب HTTP ومتوسط مدة الطلب وصحة المجموعة. استنادًا إلى تحليل مؤشرات الأداء الرئيسية (مؤشرات الأداء الرئيسية) ، ينمو جزء الكناري أو يتقلص ، ويتم نشر نتائج التحليل على موقع Slack. يمكن العثور على وصف وشرح لهذه العملية في المادة التسليم التدريجي لـ App Mesh.

عمليات النشر الداكنة (المخفية) أو A / B

النشر الخفي هو نوع آخر من إستراتيجية الكناري (والتي ، بالمناسبة ، يمكن لـ Flagger العمل معها أيضًا). الفرق بين عمليات النشر الخفية والكناري هو أن عمليات النشر الخفية تتعامل مع الواجهة الأمامية وليس الواجهة الخلفية كما تفعل عمليات نشر الكناري.

اسم آخر لعمليات النشر هذه هو اختبار A / B. بدلاً من فتح الوصول إلى ميزة جديدة لجميع المستخدمين ، يتم تقديمها فقط لجزء محدود منهم. عادة ، لا يدرك هؤلاء المستخدمون أنهم رواد في الاختبار (ومن هنا جاء مصطلح "النشر الصامت").

مع مفاتيح وظيفية (ميزة تبديل) والأدوات الأخرى ، يمكنك مراقبة كيفية تفاعل المستخدمين مع ميزة جديدة ، سواء كانوا مدمنين عليها أو يجدون واجهة المستخدم الجديدة محيرة وأنواع المقاييس الأخرى.

عمليات نشر المُخبر و A / B

بالإضافة إلى التوجيه الموزون ، يستطيع المُخبر أيضًا توجيه حركة المرور إلى خادم الكناري بناءً على معلمات HTTP. يمكن أن يستخدم اختبار A / B رؤوس HTTP أو ملفات تعريف الارتباط لإعادة توجيه شريحة معينة من المستخدمين. هذا فعال بشكل خاص في حالة تطبيقات الواجهة الأمامية التي تتطلب ربط الجلسة بالخادم. (تقارب الجلسة). يمكن العثور على مزيد من المعلومات في وثائق المُخبر.

المؤلف ممتن ستيفان برودان، مهندس Weaveworks (ومنشئ برنامج Flagger) ، لجميع مخططات النشر المذهلة هذه.

PS من المترجم

اقرأ أيضًا على مدونتنا:

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

استراتيجيات نشر Kubernetes: التدحرج ، وإعادة الإنشاء ، والأزرق / الأخضر ، والكناري ، والظلام (اختبار A / B)