🥇نشر Canary في Kubernetes #2: طرح Argo

سوف نستخدم وحدة تحكم نشر Argo Rollouts الأصلية لـ k8s وGitlabCI لتشغيل عمليات نشر Canary إلى Kubernetes

https://unsplash.com/photos/V41PulGL1z0

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

نشر الكناري في Kubernetes #1: Gitlab CI
(هذا المقال)
نشر الكناري باستخدام Istio
نشر الكناري باستخدام Jenkins-X Istio Flagger

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

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

طرح آرجو

Argo Rollouts عبارة عن وحدة تحكم نشر أصلية لـ Kubernetes. يوفر CRD (تعريف الموارد المخصص) لـ Kubernetes. وبفضل ذلك، يمكننا استخدام كيان جديد: Rollout، الذي يدير عمليات النشر باللونين الأزرق والأخضر والكناري مع خيارات التكوين المتنوعة.

وحدة تحكم Argo Rollouts المستخدمة بواسطة مورد مخصص Rollout, يسمح باستراتيجيات نشر إضافية مثل الأزرق والأخضر والكناري لـ Kubernetes. الموارد Rollout يوفر وظيفة مكافئة Deployment، فقط مع استراتيجيات النشر الإضافية.
مورد Deployments لديه استراتيجيتين للنشر: RollingUpdate и Recreate. على الرغم من أن هذه الاستراتيجيات مناسبة لمعظم الحالات، للنشر على الخوادم على نطاق واسع جدًا، يتم استخدام استراتيجيات إضافية، مثل الأزرق والأخضر أو الكناري، والتي لا تتوفر في وحدة تحكم النشر. لاستخدام هذه الاستراتيجيات في Kubernetes، كان على المستخدمين كتابة نصوص برمجية فوق عمليات النشر الخاصة بهم. تعرض وحدة التحكم Argo Rollouts هذه الاستراتيجيات كمعلمات بسيطة وتعريفية وقابلة للتكوين.
https://argoproj.github.io/argo-rollouts

هناك أيضًا Argo CI، الذي يوفر واجهة ويب ملائمة للاستخدام مع Rollouts، وسنلقي نظرة على ذلك في المقالة التالية.

تثبيت طرح Argo

جانب الخادم

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

في البنية التحتية الخاصة بنا (انظر أدناه)، أضفنا بالفعل install.yaml كـ i/k8s/argo-rollouts/install.yaml. بهذه الطريقة سيقوم GitlabCI بتثبيته في المجموعة.

جانب العميل (البرنامج المساعد kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

تطبيق المثال

من الممارسات الجيدة أن يكون لديك مستودعات منفصلة لرمز التطبيق والبنية التحتية.

مستودع للتطبيق

كيم ويستكامب/k8s-deployment-example-app

هذه واجهة برمجة تطبيقات 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-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

و rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout يعمل نفس النشر. إذا لم نقم بتعيين إستراتيجية تحديث (مثل الكناري هنا) فسوف يتصرف مثل نشر التحديث المتداول الافتراضي.

نحدد خطوتين في yaml لنشر الكناري:

10% من حركة المرور إلى الكناري (انتظر موافقًا يدويًا)
50% من حركة المرور إلى الكناري (انتظر دقيقتين ثم تابع إلى 2%)

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

بعد النشر الأولي، ستبدو مواردنا كما يلي:

ولا نحصل على الرد إلا من الإصدار الأول للتطبيق:

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

الخطوة 1: 10% من حركة المرور

لبدء نشر إصدار Canary، نحتاج فقط إلى تغيير إصدار الصورة كما نفعل عادةً مع عمليات النشر:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

ونحن ندفع التغييرات، لذلك يتم نشر Gitlab CI ونرى التغييرات:

الآن إذا وصلنا إلى الخدمة:

عظيم! نحن في منتصف انتشار الكناري لدينا. يمكننا أن نرى التقدم من خلال تشغيل:

kubectl argo rollouts get rollout rollout-canary

الخطوة الثانية: 2% من حركة المرور:

لننتقل الآن إلى الخطوة التالية: إعادة توجيه 50% من حركة المرور. لقد قمنا بتكوين هذه الخطوة ليتم تشغيلها يدويًا:

kubectl argo rollouts promote rollout-canary # continue to step 2

وقد أعاد تطبيقنا 50% من الردود من الإصدارات الجديدة:

ومراجعة الإطلاق:

رائع.

الخطوة الثانية: 3% من حركة المرور:

قمنا بإعدادها بحيث تنتهي خطوة 2% تلقائيًا بعد دقيقتين وتبدأ خطوة 50%:

ومخرجات التطبيق:

ومراجعة الإطلاق:

اكتمل نشر Canary.

مزيد من الأمثلة مع Argo Rollouts

هناك المزيد من الأمثلة هنا، مثل كيفية إعداد معاينات ومقارنات البيئة بناءً على الكناري:

https://github.com/argoproj/argo-rollouts/tree/master/examples

فيديو حول Argo Rollouts وArgo CI

أوصي حقًا بهذا الفيديو، فهو يوضح كيفية عمل Argo Rollouts وArgo CI معًا:

مجموع

تعجبني حقًا فكرة استخدام CRDs التي تدير إنشاء أنواع إضافية من عمليات النشر أو مجموعات النسخ المتماثلة، وإعادة توجيه حركة المرور، وما إلى ذلك. العمل معهم يسير بسلاسة. بعد ذلك أود اختبار التكامل مع Argo CI.

ومع ذلك، يبدو أن هناك اندماجًا كبيرًا بين Argo CI وFlux CI، لذا قد أنتظر حتى صدور الإصدار الجديد: أرجو الجريان.

هل لديك أي خبرة مع Argo Rollouts أو Argo CI؟

نشر Canary في Kubernetes #2: طرح Argo