توی این پست میریم سراغ بررسی استراتژیهای مختلف دیپلویمنت توی کوبرنتیز و بعدشم ورکلودهای مربوط به Auto Scaling رو بررسی میکنیم.
توی این پست میریم سراغ بررسی استراتژیهای مختلف دیپلویمنت توی کوبرنتیز و بعدشم ورکلودهای مربوط به Auto Scaling رو بررسی میکنیم.
خب یه مروری کنیم پستهای قبلی رو:
- دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
- مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
- چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
- چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
- خودکارش کن، مشکلاتت حل میشه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
- در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
- در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
- در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
- در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
- در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
- در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویسهامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
- در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
- در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
- در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیسها و تجربیات خودم رو گفتم.
- تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
- در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
- در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
- در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
- در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
- مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپنتلهمتری دادیم.
- در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
- در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
- در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
- در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
- در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسهاش کنیم.
- در مسیر Observability، میمیر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
- در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
- در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
- در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
- آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
- کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمهدستی واسه تستهامون داشته باشیم.
- کامپوننتهای کوبر ( قسمت سوم ) توی این پست کامپوننتهای مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.
- پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.
- ورکلودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورکلود کوبر رو بررسی کردیم.
توصیه میکنم که حتما این پستها رو هم مطالعه کنید. بریم که ادامه بدیم.
اگه یادتون باشه توی بلاگ پست قبلی گفتیم که ورکلودی توی کوبرنتیز داریم به اسم deployment که همون replicaset هست با این تفاوت که بهمون versioning و deployment strategy میده.
حالا بریم استراتژیهای مختلف دیپلویمنت رو با هم بررسی کنیم.
۱ – Recreate:
استراتژی اول به این شکل هست که اگه ما بخواهیم بریم به سراغ ورژن بعدی، ابتدا تمام پادهایی که از ورژن حاضر داریم رو از بین ببریم و بعدش شروع کنیم از اول نسخه جدید اونها رو بیاریم بالا، اولین نکته منفی این روش که احتمالا متوجهش شدید اینه که داون تایم میدیم، یعنی سرویسمون در فاصله بین از بین رفتن پادهای قدیم تا ایجاد پادهای جدید، از دسترس خارج میشه و نکته دیگه اینکه اگه به هردلیلی نیاز پیدا کنیم که برگردیم به نسخه قدیم و roll back کنیم، این فرآیند زمانبر خواهد شد. اما از طرف دیگه این روش کمهزینه هست برامون و با همون منابع قبلی قابل انجام هست و به نسبت بقیه استراتژیها پیچیدگی کمتری رو داره. این استراتژی بیشتر برای statefulها کاربرد داره که میخواهیم کسی که با دیتا کار میکنه کامل بیاد پایین و بعد بعدی شروع کنه. یعنی کاربرد خودش رو داره.
۲ – Rolling Update:
استراتژی بعدی که یکی از متداولترین استراتژیها هم هست، rolling update یا ramped هست. توی این روش میتونیم مشخص کنیم که با چه طول گامی، قدمهای این آپدیت برداشته بشه. مثلا بگیم اول چند درصد پادهارو با نسخه جدید جایگزین کن بعد برو سراغ بقیه. یا مثلا بگیم سه تا سه تا اینارو جدید کن. یه مقدار کمی به نسبت روش recreate پیچیدگی بیشتری داره اما در عوض داون تایم نمیدیم و مشتری رو تحت تاثیر نمیذاره و هزینه کمی هم به نسبت داره اما بازهم در صورت مشکل و نیاز به rollback به نسخه قبلی، این روش زمانبر هست. متداولترین استراتژی هست که برای statelessها استفاده میشود. خیلی کاربردی و خوبه و کمک میکنه که بدون اینکه مشتری چیزی متوجه بشه تمام سرویس جدید رو با قدیمی عوض کنیم.
۳ – Shadow:
این روش که پیچیدگی زیادی رو هم به نسبت دوتای قبلی داره به این صورت هست که ما درکنار نسخه حاضرمون که داره کار میکنه، پادهای نسخه جدید رو هم میاریم بالا که تا همینجاش میشه هزینهبر بودن این روش رو متوجه شد چون به دو برابر منابع نیاز داره. بعدش که با ترافیک واقعی یوزرهامون نسخه جدید رو تست کردیم، در لحظه مثلا لیبلهای سرویس رو عوض میکنیم و کل ترافیک رو به سمت پادهای جدید میفرستیم. زمان rollback توی این روش بسیار پایینه و مشتری رو تحت تاثیر قرار نمیدیم و داون تایم نداریم. تو shadow ما داریم با لود ترافیک واقعی سیستم جدید رو تست میکنیم ولی پاسخ مشتری رو از طریق سیستم قبلی میدیم.
۴ – Canary:
روش قناری از همون ایده تست قناری که توی بلاگ پستهای قبلی توضیح دادیم استفاده میکنه و به لحاظ پیچیدگی بین روشهای ساده recreate , rolling update و روشهای پیچیده shadow , A/B testing قرار میگیره. توی این روش یه درصد کمی از ترافیک رو مثلا ۱۰ درصد سمت ورژن جدید میفرستیم و بعد از اینکه از عملکردش اطمینان حاصل کردیم به صورت کامل با ورژن قبلی جایگزینش میکنیم. هزینه این روش به نسبت shadow کمتره چون در لحظه دو برابر منابع رو مصرف نمیکنیم و زمان rollback پایینی داره چون تنها درصد کمی از ترافیک اصلی رو سمت نسخه جدید بردیم. کلا هم از نظر هزینه و هم از نظر پیچیدیگی بین تمام استراتژیها هست. میتونیم قسمتی از مشتریها رو با سرویس جدید تست و بررسی کنیم و بعدش اگر همه چیز خوب بود سرویس جدید رو با قبلی عوض کنیم. برای این استراتژی نیاز به پیادهسازی داریم ولی بدون اون هم میشه با لیبلها و سلکتور یه کارهای کرد.
۵ – Blue – Green:
بلوگرین یکی از مرسومترین استراتژیهایی است که استفاده میشه. این طوری هست که یه نسخه مثل نسخهی اصلی میاریم بالا و در یه لحظه تمام درخواستها رو میفرستیم سمت نسخهی جدید. اینجا هم هزینهمون بالاتر هست چون دو برابر منابع مصرف میکنیم، زمان rollback بسیار پایینه و در حد عوض کردن لیبلهای سرویسه، یه جورایی با درخواستهای واقعی نسخه جدید رو تست میکنیم. برای این استراتژی هم نیاز داریم که پیادهسازی داشته باشیم ولی خودمون میتونیم با چند تا لیبل و اینا ردیفش کنیم. استراتژی خوبی هست زمانی که مشکل منابع نداریم و تغییرات سریع مد نظرمون هست.
۶ – A/B Testing:
فرض کنید ما یه فیچر جدید به سرویسمون اضافه کردیم که مربوط به کاربران موبایل هست، یا مثلا مربوط به مشتریهایی هست که از مرورگر خاصی استفاده میکنند. برای اینکه این نوع تغییرات رو ببریم به نسخه جدید نیاز هست که اصطلاحا targeted user رو تست کنیم و بعد چنج بزنیم. توی این روش ابتدا درصدی از ترافیک واقعی یوزرهای مشخص شدهای رو سمت نسخه جدید میفرستیم و بعد از تست نسخه جدید رو دیپلوی میکنیم. این روش مانند روشهای shadow و blue-green هزینهبر نیست و زمان rollback پایین داره اما پیچیدگی این روش به نسبت زیاد هست چونکه باید از مفاهیم service mesh و ابزارهایی مثل istio برای تارگت کردن یوزرهای خاص استفاده کنیم. یکی از استراتژیهایی هست که برای پیادهسازی آن نیاز به ابزار با پیچیدگی زیادی داریم.
یه جدول مقایسه روشهای مختلف رو در ادامه براتون میذارم. تو این جدول خیلی خوب این استراتژیها رو باهم مقایسه کرده. مقایسهی خوبی که از هزینهی پیادهسازی تا تاثیرگذاری روی کاربر یا زمان رولبک رو مقایسه کرده. جدول خوبی هست با دقت بررسیش کنید.
AutoScaling
توی کوبرنتیز سه مدل AutoScaler داریم، HPA که تعداد رپلیکا رو scale میکنه، VPA که ریسورس و منابع کانتینرها رو scale میکنه و CA که تعداد نودهای کلاستر رو scale میکنه.
HPA
از HPA یا Horizontal Pod Autoscaler برای scale out کردن سرویسمون استفاده میکنیم، زمانیکه ورکلود HPA رو برای دیپلویمنتمون تعریف میکنیم، مشخص میکنیم که مثلا اگه مصرف منابع پادهای این سرویس به ۸۰ درصد رسید اون رو تا سقف مثلا ۳۰ عدد میتونی scale out کنی و تعدادش رو بیشتر کنی و برعکس زمانیکه اون تعداد نیاز نبود تعداد پادهای این سرویس رو کم کن ولی حداقل پنج تا ازش بالا باشه.
کنترلر HPA با کمک متریکسرور توی کلاستر محاسبات لازم رو انجام میده و تغییرات مورد نیاز رو روی deployment میزنه تا به حالت مطلوبمون برسیم. کلا برای Auto Scaling حضور و وجود متریکسرور الزامی هست.
نکته دیگه در مورد HPA این هست که به صورت دیفالت همراه کوبرنتیز هست و برای استفاده ازش توی کلاسترمون نیاز به کار اضافهای نداریم.
برای مثال به تصویر زیر توجه کنید تا نحوه محاسبه HPA رو بررسی کنیم.
در مثال بالا ما تارگت ۵۰ درصد رو برای مصرف CPU و تارگت ۲۰ رو برای تعداد درخواستهای یک پاد در ثانیه مشخص کردیم، حالا متریک سرور اطلاعاتی رو از سه تا پاد اون سرویس به HPA داده، برای محاسبه تعداد لازم hpa میاد مصرف CPU هارو جمع میشه و به میزان مطلوب تقسیم میکنه. که در این مثال برای CPU میشه چهار، در واقع الان ما به ۲۰۰ واحد مصرف CPU مثلا با واحد (میلی کور) نیاز داریم و میدونیم که میخوایم نهایتا با واحدهای مصرف ۵۰ تایی این نیاز رو پوشش بدیم، پس تعداد پادی که نیاز داریم چهار هست، به همین ترتیب برای تعداد درخواستها در ثانیه به عدد سه میرسیم و نهایتا برای اینکه هر دو شرط برقرار بشه از حاصل محاسبات ماکسیمم میگیریم.
معمولا برای HPA باید چهار تا پارامتر رو مشخص کنیم. اول اون ریسورسی که میخوایم scale ش کنه، مثلا دیپلویمنت سرویسمون. دوم حداقل و حداکثر تعداد رپلیکا که باید در اون محدوده حرکت کنیم مثلا حداقل سه تا و حداکثر ۳۰ تا. سوم متریکی که بر اساس اون scale کنیم مثلا میزان مصرف ram و نهایتا چهارم تارگتی که برای اون متریک داریم مثلا ۸۰ درصد ram پاد مصرف بشه.
VPA
از VPA یا Vertical Pod Autoscaler برای scale up کردن سرویسمون استفاده میکنیم. VPA به صورت دیفالت روی کلاستر نیست و باید اون رو جداگانه اضافه کنیم و بعد از اینکه VPA روی کلاسترمون نصب شد بهمون این امکان رو میده تا برای ورکلودهامون CRD بسازیم که تعریف کنه چه زمانی و چه میزان ریسورسهای اون پادهارو scale بشه. برای اینکه به صورت in-place منابع پاد scale بشن نیاز داریم که روی کوبر v1.27 به بالا باشیم و InPlaceVerticalScaling هم فعال شده باشه توی کلاستر.
چهارتا update mode داره VPA که در ادامه به اختصار اونها رو توضیح میدم:
- off
توی این حالت VPA فقط پیشنهادش برای منابع مصرفی رو بهمون میده و اون رو اعمال نمیکنه. این ریکامندیشن یکی از فانکشنهای خیلی کاربردی VPA هست که خیلی میتونه کمک کنه و در زمانهایی که نمیدونیم چقدر باید منابع برای سرویسمون در نظر بگیریم بهمون کمک میکنه.
- initial
توی این مود VPA تنها زمان ساخته شدن پاد ریسورسی که محاسبه کرده رو به پاد assign میکنه و دیگه تغییرش نمیده.
- recreate
توی این مود VPA ریسورس رو به پادهای جدیدی که ساخته میشن اعمال میکنه و پادهایی که از قبل بالا بودن رو از بین میبره و با ریسورس جدید بالا میاره
- auto mode
در حال حاضر این مود مثل recreate کار میکنه اما در ورژنهای بعدی قراره به این شکل بشه که بدون recreate کردن پادها درجا ریسورس اونها رو تغییر بده. یعنی الان قسمت auto داره کار نمیکنه و قراره تو نسخههای بعدی این موضوع درست بشه.
کلا سه تا بخش داره VPA برای اینکه عملکرد scale up کردن رو بهمون بده، اول admission controller هست که هر پادی که میاد توی کلاستر از این رد میده تا چک کنه که آیا این پاد برای خودش یا ورکلودی که بالای سرش هست VPA تعریف شده یا نه. بخش دوم VPA Recommender هست که متصل میشه به متریکسرور و دیتای مربوط به تاریخچه مصرف و مصرف الان پاد رو میگیره و بر اساس اون یه خروجی پیشنهادی برای میزان ریسورس درخواستی پاد و لیمیت اون بهمون میده و نهایتا بخش سوم که VPA Updater هست که هر یک دقیقه ران میشه و اگه پادی که داره ران میشه توی اون رنج مشخص شده توسط VPA Recommender نباشه اون رو میکشه تا دوباره در فرآیند بالا اومدن با ریسورس آپدیت شده بالا بیاد. البته قراره قستم Auto هم درست بشه که دیگه این VPA به صورت خودکار انجام بشه.
CA
این نوع از Autoscaler ها رو زمانیکه کوبرنتیز رو از کلاد پروایدر سرویس بگیریم و اون کلاد پروایدر قابلیتش رو بهمون بده میتونیم استفاده کنیم، به این شکل که مثلا تعریف میکنیم که در زمان لازم تعداد نودهای کلاسترمون رو بیشتر کنه، مثلا به AWS بگی که زمان جشنواره یا پیک فروش یا موارد مشابه … اگه نیاز شد نودهای ورکر کلاستر من رو تا سقف ده تا زیاد کن. اونوقت میگن خدا نیست 🙂
با استفاده از CA ما میتونیم کلاستر کوبرنتیز خودمون رو Scale کنیم که خیلی قابلیت خوبی هست و این امکان باعث میشه که در زمان مورد نیاز وقتی منابع داخل کلاستر رو به انتها هست اون رو بزرگ کنیم و وقتی لود از کل کلاستر برداشته میشه اون رو کوچیک کنیم. دنیای جالبی هم اینجا وجود داره که چطور یه نود رو اضافه کنه و چطور اون رو خالی نگه داره یا رزرو کنه و کلی داستان دیگه که این جا داریم.
تو ادامهی مسیرمون میریم سراغ نتورک کوبرنتیز 🔥
مراقب خودتون باشید. 🌹🐳🌹