🥇نشر Canary في Kubernetes #1: Gitlab CI

سنستخدم Gitlab CI وGitOps اليدوي لتنفيذ واستخدام نشر Canary في Kubernetes

مقالات من هذه السلسلة:

(هذا المقال)
نشر الكناري باستخدام ArgoCI
نشر الكناري باستخدام Istio
نشر الكناري باستخدام Jenkins-X Istio Flagger

سنقوم بتنفيذ نشر Canary يدويًا عبر GitOps وإنشاء/تعديل موارد Kubernetes الرئيسية. هذه المقالة مخصصة في المقام الأول للمقدمة مع كيفية عمل النشر في Kubernetes Canary، نظرًا لوجود طرق أكثر فعالية للأتمتة، والتي سننظر فيها في المقالات التالية.

https://www.norberteder.com/canary-deployment/

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

باستخدام استراتيجية 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 على النحو التالي:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

لتشغيله بنفسك، ستحتاج إلى مجموعة، يمكنك استخدام Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

تحتاج إلى شوكة https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure وإنشاء متغير KUBECONFIG في GitlabCI، والذي سيحتوي على تكوين للوصول kubectl إلى مجموعتك.

يمكنك القراءة عن كيفية الحصول على بيانات الاعتماد لمجموعة (Gcloud) هنا.

البنية التحتية يامل

في مستودع البنية التحتية لدينا خدمة:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

والنشر في deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ونشر آخر في deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

لاحظ أن تطبيق app-deploy لا يحتوي على أي نسخ متماثلة محددة حتى الآن.

تنفيذ النشر الأولي

لبدء النشر الأولي، يمكنك بدء مسار GitlabCI يدويًا على الفرع الرئيسي. بعد ذلك kubectl ينبغي إخراج ما يلي:

نحن نرى app النشر باستخدام 10 نسخ متماثلة وapp-canary بـ 0. يوجد أيضًا LoadBalancer الذي يمكننا الوصول إليه من خلاله curl عبر IP الخارجي:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

نرى أن تطبيق الاختبار الخاص بنا يُرجع "v1" فقط.

تنفيذ نشر كناري

الخطوة 1: إصدار إصدار جديد لبعض المستخدمين

قمنا بتعيين عدد النسخ المتماثلة على 1 في ملف Publish-canary.yaml وصورة الإصدار الجديد:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

في ملف deploy.yaml قمنا بتغيير عدد النسخ المتماثلة إلى 9:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

ندفع هذه التغييرات إلى المستودع الذي سيبدأ النشر منه (عبر GitlabCI) ونرى النتيجة:

ستشير خدمتنا إلى عمليتي النشر، حيث أن كلاهما يحتوي على محدد التطبيق. نظرًا للتوزيع العشوائي الافتراضي لـ Kubernetes، من المفترض أن نرى استجابات مختلفة لحوالي 10% من الطلبات:

الحالة الحالية لتطبيقنا (GitOps، المأخوذة من Git كمصدر وحيد للحقيقة) هي وجود عمليتي نشر مع نسخ متماثلة نشطة، واحدة لكل إصدار.

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

الخطوة 2: إطلاق الإصدار الجديد لجميع المستخدمين

قررنا أن كل شيء سار على ما يرام ونحن الآن بحاجة إلى طرح الإصدار الجديد لجميع المستخدمين. للقيام بذلك، نقوم ببساطة بالتحديث deploy.yaml تثبيت نسخة جديدة من الصورة وعدد النسخ يساوي 10. في deploy-canary.yaml قمنا بضبط عدد النسخ المتماثلة على 0. وبعد النشر ستكون النتيجة كما يلي:

إجمال

بالنسبة لي، فإن تشغيل النشر يدويًا بهذه الطريقة يساعد في فهم مدى سهولة تكوينه باستخدام k8s. نظرًا لأن Kubernetes يسمح لك بتحديث كل شيء عبر واجهة برمجة التطبيقات (API)، فيمكن تنفيذ هذه الخطوات تلقائيًا من خلال البرامج النصية.

الشيء الآخر الذي يجب تنفيذه هو نقطة دخول الاختبار (LoadBalancer أو عبر Ingress) والتي يمكن من خلالها الوصول إلى الإصدار الجديد فقط. ويمكن استخدامه للتصفح اليدوي.

وفي المقالات القادمة، سنتعرف على الحلول الآلية الأخرى التي تنفذ معظم ما قمنا به.

نشر الكناري في Kubernetes #1: Gitlab CI