استراتژی های استقرار در Kubernetes: نورد، بازآفرینی، آبی/سبز، قناری، تیره (تست A/B)

توجه داشته باشید ترجمه: این نمای کلی از Weaveworks محبوب‌ترین استراتژی‌های عرضه اپلیکیشن را معرفی می‌کند و نشان می‌دهد که چگونه می‌توان پیشرفته‌ترین آن‌ها را با استفاده از عملگر Kubernetes Flagger پیاده‌سازی کرد. این به زبان ساده نوشته شده است و شامل نمودارهای بصری است که به مهندسان تازه کار نیز اجازه می دهد تا موضوع را درک کنند.

نمودار از یک بررسی دیگر استراتژی‌های عرضه ساخته شده در Container Solutions

امروزه یکی از بزرگترین چالش‌ها در توسعه برنامه‌های بومی ابری، افزایش سرعت استقرار است. در رویکرد میکروسرویس، توسعه‌دهندگان در حال حاضر با برنامه‌های کاملاً ماژولار کار می‌کنند و طراحی می‌کنند و به تیم‌های مختلف اجازه می‌دهند همزمان کد بنویسند و تغییراتی در برنامه ایجاد کنند.

استقرار کوتاهتر و مکررتر دارای مزایای زیر است:

• زمان ورود به بازار کاهش می یابد.
• ویژگی های جدید سریعتر به دست کاربران می رسد.
• بازخورد کاربر سریعتر به تیم توسعه می رسد. این بدان معنی است که تیم می تواند ویژگی ها را اضافه کند و مشکلات را سریعتر برطرف کند.
• روحیه توسعه‌دهنده افزایش می‌یابد: کار کردن با ویژگی‌های بیشتر در توسعه سرگرم‌کننده‌تر است.

اما با افزایش دفعات انتشار، احتمال تأثیر منفی بر قابلیت اطمینان برنامه یا تجربه کاربری نیز افزایش می‌یابد. به همین دلیل است که برای عملیات و تیم‌های DevOps مهم است که فرآیندها را بسازند و استراتژی‌های استقرار را به گونه‌ای مدیریت کنند که خطر را برای محصول و کاربران به حداقل برساند. (می توانید درباره اتوماسیون خط لوله CI/CD اطلاعات بیشتری کسب کنید اینجا.)

در این پست، استراتژی‌های مختلف استقرار در Kubernetes، از جمله استقرار رول و روش‌های پیشرفته‌تر مانند پخش قناری و تغییرات آنها را مورد بحث قرار خواهیم داد.

استراتژی های استقرار

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

نورد (تدریج، استقرار "غلتان")

این استراتژی استقرار استاندارد در Kubernetes است. به تدریج، یک به یک، پادها را با نسخه قدیمی برنامه با پادهای با نسخه جدید جایگزین می کند - بدون خرابی کلاستر.

Kubernetes منتظر می ماند تا غلاف های جدید آماده کار شوند (با استفاده از آن ها را بررسی کنید تست های آمادگی)، قبل از اینکه موارد قدیمی را شروع کنید. اگر مشکلی رخ دهد، می‌توان این به‌روزرسانی را بدون توقف کل خوشه لغو کرد. در فایل YAML که نوع استقرار را توصیف می کند، تصویر جدید جایگزین تصویر قدیمی می شود:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

پارامترهای به‌روزرسانی rollover را می‌توان در فایل مانیفست مشخص کرد:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

بازآفرینی کنید

در این ساده ترین نوع استقرار، غلاف های قدیمی به یکباره کشته می شوند و با غلاف های جدید جایگزین می شوند:

مانیفست مربوطه چیزی شبیه به این است:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

آبی/سبز (استقرارهای آبی-سبز)

استراتژی استقرار آبی-سبز (که گاهی اوقات قرمز/سیاه نیز نامیده می شود) شامل استقرار همزمان نسخه های قدیمی (سبز) و جدید (آبی) برنامه است. پس از ارسال هر دو نسخه، کاربران معمولی به نسخه سبز دسترسی دارند، در حالی که نسخه آبی برای تیم QA برای خودکارسازی تست ها از طریق یک سرویس جداگانه یا ارسال مستقیم پورت در دسترس است:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

پس از آزمایش نسخه آبی (جدید) و تایید انتشار آن، سرویس به آن سوئیچ می‌کند و نسخه سبز (قدیمی) تا می‌شود:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

قناری (استقرار قناری)

رول اوت های قناری شبیه رول اوت های سبز آبی هستند، اما کنترل و استفاده بهتری دارند ترقی خواه رویکرد گام به گام این نوع شامل چندین استراتژی مختلف است، از جمله پرتاب های مخفی کاری و تست A/B.

این استراتژی زمانی استفاده می شود که نیاز به آزمایش برخی از عملکردهای جدید، معمولاً در پشتیبان برنامه وجود دارد. ماهیت رویکرد ایجاد دو سرور تقریباً یکسان است: یکی تقریباً به همه کاربران خدمت می کند و دیگری با عملکردهای جدید فقط به زیر گروه کوچکی از کاربران خدمت می کند و پس از آن نتایج کار آنها مقایسه می شود. اگر همه چیز بدون خطا پیش رود، نسخه جدید به تدریج در کل زیرساخت عرضه می شود.

اگرچه این استراتژی را می توان به طور انحصاری با استفاده از Kubernetes پیاده سازی کرد و غلاف های قدیمی را با موارد جدید جایگزین کرد، اما استفاده از مش سرویس مانند Istio بسیار راحت تر و ساده تر است.

برای مثال، ممکن است دو مانیفست مختلف در Git داشته باشید: یک مانیفست معمولی با تگ 0.1.0 و یک مانیفست قناری با تگ 0.2.0. با تغییر وزن ها در مانیفست دروازه مجازی Istio، می توانید توزیع ترافیک بین این دو استقرار را کنترل کنید:

برای راهنمای گام به گام اجرای استقرار قناری با استفاده از ایستیو، نگاه کنید GitOps Workflow با Istio. (توجه داشته باشید. ترجمه: ما همچنین مطالبی در مورد انتشار قناری به ایستیو ترجمه کردیم اینجا.)

استقرار قناری با Weaveworks Flagger

Weaveworks Flagger به شما این امکان را می دهد تا به راحتی و به طور موثری قناری ها را مدیریت کنید.

Flagger کار با آنها را خودکار می کند. از Istio یا AWS App Mesh برای مسیریابی و تغییر ترافیک و معیارهای Prometheus برای تجزیه و تحلیل نتایج استفاده می کند. علاوه بر این، تجزیه و تحلیل استقرار قناری ها را می توان با webhook ها برای انجام تست های پذیرش، تست های بارگذاری و هر نوع بررسی دیگری تکمیل کرد.

بر اساس استقرار Kubernetes و در صورت لزوم، مقیاس‌بندی افقی pods (HPA)، Flagger مجموعه‌هایی از اشیاء (استقرار Kubernetes، سرویس‌های ClusterIP و سرویس‌های مجازی Istio یا App Mesh) را برای تجزیه و تحلیل و پیاده‌سازی استقرار قناری ایجاد می‌کند:

پیاده سازی حلقه کنترل (حلقه کنترل)Flagger به تدریج ترافیک را به سرور قناری تغییر می دهد، در حالی که به طور همزمان معیارهای عملکرد کلیدی مانند درصد درخواست های HTTP موفق، میانگین مدت زمان درخواست و سلامت غلاف را اندازه گیری می کند. بر اساس تجزیه و تحلیل KPI (شاخص های کلیدی عملکرد)، قناری یا رشد می کند یا سقوط می کند و نتایج تجزیه و تحلیل در Slack منتشر می شود. شرح و نمایش این فرآیند را می توان در مطالب یافت تحویل پیشرو برای App Mesh.

استقرار تاریک (پنهان) یا A/B

استقرار Stealth یکی دیگر از انواع استراتژی قناری است (که اتفاقاً Flagger نیز می تواند با آن کار کند). تفاوت بین استقرار مخفی کاری و قناری در این است که استقرار مخفی کاری به جای استقرار قناری، با قسمت جلویی سروکار دارد.

نام دیگر این استقرارها تست A/B است. به جای در دسترس قرار دادن ویژگی جدید برای همه کاربران، تنها به بخش محدودی از آنها ارائه می شود. به طور معمول، این کاربران از اینکه آزمایش کننده های پیشگام هستند، بی اطلاع هستند (از این رو اصطلاح "استقرار مخفی کاری").

استفاده از سوئیچ های عملکردی (تغییر ویژگی) و سایر ابزارها، می‌توانید نحوه تعامل کاربران با ویژگی جدید را نظارت کنید، آیا آنها با آن درگیر هستند یا اینکه رابط کاربری جدید را گیج‌کننده می‌دانند، و انواع دیگر معیارها.

استقرار Flagger و A/B

علاوه بر مسیریابی مبتنی بر وزن، Flagger همچنین می تواند ترافیک را بر اساس پارامترهای HTTP به سرور قناری هدایت کند. در تست A/B، می‌توانید از هدرها یا کوکی‌های HTTP برای هدف قرار دادن بخش خاصی از کاربران استفاده کنید. این امر به ویژه در مورد برنامه‌های فرانت‌اند که نیاز به اتصال جلسه به سرور دارند مؤثر است (قرابت جلسه). اطلاعات بیشتر را می توان در اسناد Flagger یافت.

نویسنده متشکرم استفان پرودان، مهندس Weaveworks (و خالق Flagger)، برای همه این الگوهای استقرار شگفت انگیز.

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «بررسی اجمالی و مقایسه کنترلرهای Ingress برای Kubernetes"؛
• «werf - ابزار ما برای CI / CD در Kubernetes (نمایش کلی و گزارش تصویری)"؛
• «میکروسرویس هایی از همان نوع را با werf و GitLab CI بسازید و استقرار دهید"؛
• «GitOps چیست؟'.

منبع: www.habr.com