🥇استقرار Canary در Kubernetes #1: Gitlab CI

ما از Gitlab CI و GitOps دستی برای پیاده سازی و استفاده از استقرار Canary در Kubernetes استفاده خواهیم کرد.

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

(این مقاله)
استقرار قناری با استفاده از ArgoCI
استقرار قناری با استفاده از ایستیو
استقرار قناری با استفاده از Jenkins-X Istio Flagger

ما استقرار Canary را به صورت دستی از طریق GitOps و ایجاد/تغییر منابع اصلی Kubernetes انجام خواهیم داد. این مقاله در درجه اول برای معرفی در نظر گرفته شده است با نحوه استقرار در Kubernetes Canary، زیرا روش‌های مؤثرتری برای اتوماسیون وجود دارد که در مقالات بعدی به بررسی آن‌ها خواهیم پرداخت.

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

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

با استراتژی قناری، به‌روزرسانی‌ها ابتدا فقط برای زیرمجموعه‌ای از کاربران اعمال می‌شوند. از طریق نظارت، داده‌های گزارش، آزمایش دستی یا سایر کانال‌های بازخورد، نسخه قبل از انتشار برای همه کاربران آزمایش می‌شود.

استقرار Kubernetes (به روز رسانی در حال چرخش)

استراتژی پیش‌فرض برای Kubernetes Deployment، به‌روزرسانی رولینگ است، که در آن تعداد مشخصی از پادها با نسخه‌های جدید تصاویر راه‌اندازی می‌شوند. اگر آنها بدون مشکل ایجاد شده باشند، غلاف هایی با نسخه های قدیمی تصاویر خاتمه می یابند و غلاف های جدید به صورت موازی ایجاد می شوند.

GitOps

ما در این مثال از GitOps استفاده می کنیم زیرا:

استفاده از Git به عنوان منبعی واحد از حقیقت
ما از Git Operations برای ساخت و استقرار استفاده می کنیم (هیچ دستوری به جز git tag/merge مورد نیاز نیست)

مثال

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

مخزن برنامه

این یک 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-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 replica و app-canary با 0. همچنین یک LoadBalancer وجود دارد که می توانیم از طریق آن دسترسی داشته باشیم. curl از طریق IP خارجی:

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

می بینیم که برنامه آزمایشی ما فقط "v1" را برمی گرداند.

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

مرحله 1: نسخه جدیدی را برای برخی از کاربران منتشر کنید

تعداد کپی ها را در فایل deploy-canary.yaml و تصویر نسخه جدید 1 قرار دادیم:

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 ما تعداد Replica ها را به 0 برمی گردیم. پس از استقرار، نتیجه به شرح زیر خواهد بود:

مجموع

برای من، اجرای دستی Deployment به این روش کمک می کند تا بفهمم چگونه می توان آن را با استفاده از k8s پیکربندی کرد. از آنجایی که Kubernetes به شما امکان می دهد همه چیز را از طریق یک API به روز کنید، این مراحل را می توان از طریق اسکریپت ها خودکار کرد.

مورد دیگری که باید پیاده سازی شود یک نقطه ورود تستر (LoadBalancer یا از طریق Ingress) است که از طریق آن فقط می توان به نسخه جدید دسترسی داشت. می توان از آن برای مرور دستی استفاده کرد.

در مقاله‌های آینده، راه‌حل‌های خودکار دیگری را بررسی خواهیم کرد که بیشتر کارهایی که انجام داده‌ایم را اجرا می‌کنند.

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

منبع: www.habr.com

استقرار Canary در Kubernetes #1: Gitlab CI