سنقوم بتنفيذ نشر Canary يدويًا عبر GitOps وإنشاء/تعديل موارد Kubernetes الرئيسية. هذه المقالة مخصصة في المقام الأول للمقدمة مع كيفية عمل النشر في Kubernetes Canary، نظرًا لوجود طرق أكثر فعالية للأتمتة، والتي سننظر فيها في المقالات التالية.
باستخدام استراتيجية Canary، يتم تطبيق التحديثات أولاً على مجموعة فرعية فقط من المستخدمين. من خلال المراقبة أو بيانات السجل أو الاختبار اليدوي أو قنوات الملاحظات الأخرى، يتم اختبار الإصدار قبل إصداره لجميع المستخدمين.
نشر Kubernetes (التحديث المستمر)
الإستراتيجية الافتراضية لنشر Kubernetes هي التحديث المتجدد، حيث يتم إطلاق عدد معين من البودات مع إصدارات جديدة من الصور. إذا تم إنشاؤها دون مشاكل، فسيتم إنهاء البودات ذات الإصدارات القديمة من الصور، ويتم إنشاء البودات الجديدة بالتوازي.
جيت أوبس
نستخدم GitOps في هذا المثال لأننا:
باستخدام Git كمصدر واحد للحقيقة
نستخدم عمليات Git للإنشاء والنشر (لا توجد حاجة إلى أوامر أخرى غير علامة git/دمج)
مثال
لنأخذ ممارسة جيدة - أن يكون لدينا مستودع واحد لرمز التطبيق وآخر للبنية التحتية.
مستودع التطبيقات
هذه واجهة برمجة تطبيقات Python+Flask بسيطة جدًا تُرجع استجابة بتنسيق JSON. سنقوم ببناء الحزمة عبر GitlabCI وندفع النتيجة إلى Gitlab Registry. في السجل لدينا إصداران مختلفان:
wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2
والفرق الوحيد بينهما هو التغيير في ملف JSON الذي تم إرجاعه. نحن نستخدم هذا التطبيق لتصور الإصدار الذي نتواصل معه بسهولة قدر الإمكان.
مستودع البنية التحتية
في هذا اللفت سوف نقوم بالنشر عبر GitlabCI إلى Kubernetes، .gitlab-ci.yml على النحو التالي:
ندفع هذه التغييرات إلى المستودع الذي سيبدأ النشر منه (عبر GitlabCI) ونرى النتيجة:
ستشير خدمتنا إلى عمليتي النشر، حيث أن كلاهما يحتوي على محدد التطبيق. نظرًا للتوزيع العشوائي الافتراضي لـ Kubernetes، من المفترض أن نرى استجابات مختلفة لحوالي 10% من الطلبات:
الحالة الحالية لتطبيقنا (GitOps، المأخوذة من Git كمصدر وحيد للحقيقة) هي وجود عمليتي نشر مع نسخ متماثلة نشطة، واحدة لكل إصدار.
أصبح حوالي 10% من المستخدمين على دراية بالإصدار الجديد وقاموا باختباره عن غير قصد. حان الوقت الآن للتحقق من وجود أخطاء في السجلات ومراقبة البيانات للعثور على المشكلات.
الخطوة 2: إطلاق الإصدار الجديد لجميع المستخدمين
قررنا أن كل شيء سار على ما يرام ونحن الآن بحاجة إلى طرح الإصدار الجديد لجميع المستخدمين. للقيام بذلك، نقوم ببساطة بالتحديث deploy.yaml تثبيت نسخة جديدة من الصورة وعدد النسخ يساوي 10. في deploy-canary.yaml قمنا بضبط عدد النسخ المتماثلة على 0. وبعد النشر ستكون النتيجة كما يلي:
إجمال
بالنسبة لي، فإن تشغيل النشر يدويًا بهذه الطريقة يساعد في فهم مدى سهولة تكوينه باستخدام k8s. نظرًا لأن Kubernetes يسمح لك بتحديث كل شيء عبر واجهة برمجة التطبيقات (API)، فيمكن تنفيذ هذه الخطوات تلقائيًا من خلال البرامج النصية.
الشيء الآخر الذي يجب تنفيذه هو نقطة دخول الاختبار (LoadBalancer أو عبر Ingress) والتي يمكن من خلالها الوصول إلى الإصدار الجديد فقط. ويمكن استخدامه للتصفح اليدوي.
وفي المقالات القادمة، سنتعرف على الحلول الآلية الأخرى التي تنفذ معظم ما قمنا به.