🥇استقرار Canary در Kubernetes #2: Argo Rollouts

ما از کنترل‌کننده استقرار Argo Rollouts بومی k8s و GitlabCI برای اجرای استقرار Canary در Kubernetes استفاده خواهیم کرد.

https://unsplash.com/photos/V41PulGL1z0

مقالات این مجموعه

استقرار Canary در Kubernetes #1: Gitlab CI
(این مقاله)
استقرار قناری با استفاده از ایستیو
استقرار قناری با استفاده از Jenkins-X Istio Flagger

استقرار قناری

امیدواریم مطالعه کرده باشید قسمت اول، جایی که به طور خلاصه توضیح دادیم که استقرار قناری چیست. ما همچنین نحوه پیاده سازی آن را با استفاده از منابع استاندارد Kubernetes نشان دادیم.

Argo Rollouts

Argo Rollouts یک کنترل کننده استقرار بومی Kubernetes است. یک CRD (تعریف منابع سفارشی) برای Kubernetes فراهم می کند. به لطف آن، می توانیم از یک موجودیت جدید استفاده کنیم: Rollout، که استقرار آبی-سبز و قناری را با گزینه های پیکربندی مختلف مدیریت می کند.

کنترلر Argo Rollouts که توسط یک منبع سفارشی استفاده می شود Rollout, امکان استقرار استراتژی های اضافی مانند سبز آبی و قناری را برای Kubernetes فراهم می کند. منبع Rollout عملکردی معادل ارائه می دهد Deployment، فقط با استراتژی های استقرار اضافی.
منابع Deployments دو استراتژی برای استقرار دارد: RollingUpdate и Recreate. اگرچه این استراتژی ها برای اکثر موارد مناسب هستند، اما برای استقرار در سرورها در مقیاس بسیار بزرگ، از استراتژی های اضافی مانند سبز آبی یا قناری استفاده می شود که در کنترلر Deployment موجود نیستند. برای استفاده از این استراتژی ها در Kubernetes، کاربران باید اسکریپت هایی را در بالای Deployments خود می نوشتند. Argo Rollouts Controller این استراتژی ها را به عنوان پارامترهای ساده، اعلامی و قابل تنظیم نشان می دهد.
https://argoproj.github.io/argo-rollouts

همچنین Argo CI وجود دارد که یک رابط وب مناسب برای استفاده با Rollouts فراهم می کند، در مقاله بعدی به آن نگاهی خواهیم انداخت.

نصب Argo Rollouts

سمت سرور

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

نمونه برنامه

داشتن مخازن جداگانه برای کد برنامه و زیرساخت، تمرین خوبی است.

مخزن برای برنامه

Kim Wuestkamp/k8s-deployment-example-app

این یک API بسیار ساده Python+Flask است که پاسخی را به صورت JSON برمی‌گرداند. ما بسته را با استفاده از GitlabCI می سازیم و نتیجه را به رجیستری Gitlab منتقل می کنیم. در رجیستری ما دو نسخه انتشار متفاوت داریم:

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 همانند Deployment عمل می کند. اگر یک استراتژی به‌روزرسانی تنظیم نکنیم (مانند قناری در اینجا) مانند پیش‌فرض استقرار به‌روزرسانی پیش‌فرض عمل می‌کند.

ما دو مرحله را در یامل برای استقرار قناری تعریف می کنیم:

10% ترافیک به قناری (منتظر تأیید دستی باشید)
50% ترافیک به قناری (2 دقیقه صبر کنید سپس تا 100%)

انجام استقرار اولیه

پس از استقرار اولیه، منابع ما به صورت زیر خواهد بود:

و ما فقط از نسخه اول برنامه پاسخ می گیریم:

انجام استقرار قناری

مرحله 1: 10٪ ترافیک

برای شروع استقرار قناری، فقط باید نسخه تصویر را همانطور که معمولاً با استقرارها انجام می دهیم تغییر دهیم:

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% ترافیک:

حالا بیایید به مرحله بعدی برویم: تغییر مسیر 50٪ از ترافیک. ما این مرحله را طوری پیکربندی کردیم که به صورت دستی اجرا شود:

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

و برنامه ما 50٪ از پاسخ ها را از نسخه های جدید برگرداند:

و بررسی عرضه:

پرسنا.

مرحله 3: 100% ترافیک:

ما آن را طوری تنظیم می کنیم که بعد از 2 دقیقه مرحله 50% به طور خودکار تمام شود و مرحله 100% شروع شود:

و خروجی برنامه:

و بررسی عرضه:

استقرار قناری به پایان رسید.

نمونه‌های بیشتر با Argo Rollouts

مثال‌های بیشتری در اینجا وجود دارد، مانند نحوه تنظیم پیش‌نمایش محیط و مقایسه بر اساس قناری:

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

ویدیویی درباره Argo Rollouts و Argo CI

من واقعاً این ویدیو را توصیه می کنم، نشان می دهد که Argo Rollouts و Argo CI چگونه با هم کار می کنند:

مجموع

من ایده استفاده از CRDهایی را که ایجاد انواع دیگری از استقرار یا مجموعه‌های تکراری، هدایت ترافیک و غیره را مدیریت می‌کنند بسیار دوست دارم. کار با آنها به آرامی پیش می رود. در مرحله بعد می خواهم ادغام با Argo CI را آزمایش کنم.

با این حال، به نظر می رسد ادغام بزرگی از Argo CI و Flux CI وجود دارد، بنابراین ممکن است تا زمان انتشار نسخه جدید صبر کنم: آرگو فلاکس.

آیا تجربه ای با Argo Rollouts یا Argo CI داشته اید؟

همچنین سایر مقالات وبلاگ ما را بخوانید:

منبع: www.habr.com

استقرار Canary در Kubernetes #2: Argo Rollouts