توی این پست میریم سراغ بررسی استراتژی‌های مختلف دیپلویمنت توی کوبرنتیز و بعدشم ورک‌لودهای مربوط به Auto Scaling رو بررسی می‌کنیم.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
اگه یادتون باشه توی بلاگ پست قبلی گفتیم که ورک‌لودی توی کوبرنتیز داریم به اسم deployment که همون replicaset هست با این تفاوت که بهمون versioning و deployment strategy میده.
حالا بریم استراتژی‌های مختلف دیپلویمنت رو با هم بررسی کنیم.
استراتژی اول به این شکل هست که اگه ما بخواهیم بریم به سراغ ورژن بعدی، ابتدا تمام پادهایی که از ورژن حاضر داریم رو از بین ببریم و بعدش شروع کنیم از اول نسخه جدید اونها رو بیاریم بالا، اولین نکته منفی این روش که احتمالا متوجه‌ش شدید اینه که داون تایم میدیم، یعنی سرویس‌مون در فاصله بین از بین رفتن پادهای قدیم تا ایجاد پادهای جدید، از دسترس خارج میشه و نکته دیگه اینکه اگه به هردلیلی نیاز پیدا کنیم که برگردیم به نسخه قدیم و roll back کنیم، این فرآیند زمانبر خواهد شد. اما از طرف دیگه این روش کم‌هزینه هست برامون و با همون منابع قبلی قابل انجام هست و به نسبت بقیه استراتژی‌ها پیچیدگی کمتری رو داره. این استراتژی بیشتر برای statefulها کاربرد داره که می‌خواهیم کسی که با دیتا کار میکنه کامل بیاد پایین و بعد بعدی شروع کنه. یعنی کاربرد خودش رو داره.
استراتژی بعدی که یکی از متداول‌ترین استراتژی‌ها هم هست، rolling update یا ramped هست. توی این روش میتونیم مشخص کنیم که با چه طول گامی، قدم‌های این آپدیت برداشته بشه. مثلا بگیم اول چند درصد پادهارو با نسخه جدید جایگزین کن بعد برو سراغ بقیه. یا مثلا بگیم سه تا سه تا اینارو جدید کن. یه مقدار کمی به نسبت روش recreate پیچیدگی بیشتری داره اما در عوض داون تایم نمیدیم و مشتری رو تحت تاثیر نمیذاره و هزینه کمی هم به نسبت داره اما بازهم در صورت مشکل و نیاز به rollback به نسخه قبلی، این روش زمانبر هست. متداول‌ترین استراتژی هست که برای statelessها استفاده می‌شود. خیلی کاربردی و خوبه و کمک میکنه که بدون اینکه مشتری چیزی متوجه بشه تمام سرویس جدید رو با قدیمی عوض کنیم.
این روش که پیچیدگی زیادی رو هم به نسبت دوتای قبلی داره به این صورت هست که ما درکنار نسخه حاضرمون که داره کار میکنه، پادهای نسخه جدید رو هم میاریم بالا که تا همینجاش میشه هزینه‌بر بودن این روش رو متوجه شد چون به دو برابر منابع نیاز داره. بعدش که با ترافیک واقعی یوزرهامون نسخه جدید رو تست کردیم، در لحظه مثلا لیبل‌های سرویس رو عوض می‌کنیم و کل ترافیک رو به سمت پادهای جدید میفرستیم. زمان rollback توی این روش بسیار پایینه و مشتری رو تحت تاثیر قرار نمیدیم و داون تایم نداریم. تو shadow ما داریم با لود ترافیک واقعی سیستم جدید رو تست می‌کنیم ولی پاسخ مشتری رو از طریق سیستم قبلی میدیم.
روش قناری از همون ایده تست قناری که توی بلاگ پست‌های قبلی توضیح دادیم استفاده میکنه و به لحاظ پیچیدگی بین روش‌های ساده recreate , rolling update و روش‌های پیچیده shadow , A/B testing قرار میگیره. توی این روش یه درصد کمی از ترافیک رو مثلا ۱۰ درصد سمت ورژن جدید میفرستیم و بعد از اینکه از عملکردش اطمینان حاصل کردیم به صورت کامل با ورژن قبلی جایگزینش می‌کنیم. هزینه این روش به نسبت shadow کمتره چون در لحظه دو برابر منابع رو مصرف نمی‌کنیم و زمان rollback پایینی داره چون تنها درصد کمی از ترافیک اصلی رو سمت نسخه جدید بردیم. کلا هم از نظر هزینه و هم از نظر پیچیدیگی بین تمام استراتژی‌ها هست. میتونیم قسمتی از مشتری‌ها رو با سرویس جدید تست و بررسی کنیم و بعدش اگر همه چیز خوب بود سرویس جدید رو با قبلی عوض کنیم. برای این استراتژی نیاز به پیاده‌سازی داریم ولی بدون اون هم میشه با لیبل‌ها و سلکتور یه کارهای کرد.
بلوگرین یکی از مرسوم‌ترین استراتژی‌هایی است که استفاده میشه. این طوری هست که یه نسخه مثل نسخه‌ی اصلی میاریم بالا و در یه لحظه تمام درخواست‌ها رو میفرستیم سمت نسخه‌ی جدید. اینجا هم هزینه‌مون بالاتر هست چون دو برابر منابع مصرف می‌کنیم، زمان rollback بسیار پایینه و در حد عوض کردن لیبل‌های سرویسه، یه جورایی با درخواست‌های واقعی نسخه جدید رو تست می‌کنیم. برای این استراتژی هم نیاز داریم که پیاده‌سازی داشته باشیم ولی خودمون میتونیم با چند تا لیبل و اینا ردیفش کنیم. استراتژی خوبی هست زمانی که مشکل منابع نداریم و تغییرات سریع مد نظرمون هست.
فرض کنید ما یه فیچر جدید به سرویس‌مون اضافه کردیم که مربوط به کاربران موبایل هست، یا مثلا مربوط به مشتری‌هایی هست که از مرورگر خاصی استفاده می‌کنند. برای اینکه این نوع تغییرات رو ببریم به نسخه جدید نیاز هست که اصطلاحا targeted user رو تست کنیم و بعد چنج بزنیم. توی این روش ابتدا درصدی از ترافیک واقعی یوزرهای مشخص شده‌ای رو سمت نسخه جدید میفرستیم و بعد از تست نسخه جدید رو دیپلوی می‌کنیم. این روش مانند روش‌های shadow و blue-green هزینه‌بر نیست و زمان rollback پایین داره اما پیچیدگی این روش به نسبت زیاد هست چونکه باید از مفاهیم service mesh و ابزارهایی مثل istio برای تارگت کردن یوزرهای خاص استفاده کنیم. یکی از استراتژی‌هایی هست که برای پیاده‌سازی آن نیاز به ابزار با پیچیدگی زیادی داریم.
یه جدول مقایسه روش‌های مختلف رو در ادامه براتون میذارم. تو این جدول خیلی خوب این استراتژی‌ها رو باهم مقایسه کرده. مقایسه‌ی خوبی که از هزینه‌ی پیاده‌سازی تا تاثیرگذاری روی کاربر یا زمان رول‌بک رو مقایسه کرده. جدول خوبی هست با دقت بررسیش کنید.
توی کوبرنتیز سه مدل AutoScaler داریم، HPA که تعداد رپلیکا رو scale میکنه، VPA که ریسورس و منابع کانتینرها رو scale میکنه و CA که تعداد نودهای کلاستر رو scale میکنه.
از 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 یا Vertical Pod Autoscaler برای scale up کردن سرویس‌مون استفاده می‌کنیم. VPA به صورت دیفالت روی کلاستر نیست و باید اون رو جداگانه اضافه کنیم و بعد از اینکه VPA روی کلاسترمون نصب شد بهمون این امکان رو میده تا برای ورک‌لودهامون CRD بسازیم که تعریف کنه چه زمانی و چه میزان ریسورس‌های اون پادهارو scale بشه. برای اینکه به صورت in-place منابع پاد scale بشن نیاز داریم که روی کوبر v1.27 به بالا باشیم و InPlaceVerticalScaling هم فعال شده باشه توی کلاستر.
چهارتا update mode داره VPA که در ادامه به اختصار اونها رو توضیح میدم:
توی این حالت VPA فقط پیشنهادش برای منابع مصرفی رو بهمون میده و اون رو اعمال نمیکنه. این ریکامندیشن یکی از فانکشن‌های خیلی کاربردی VPA هست که خیلی می‌تونه کمک کنه و در زمان‌هایی که نمی‌دونیم چقدر باید منابع برای سرویس‌مون در نظر بگیریم بهمون کمک میکنه.
توی این مود VPA تنها زمان ساخته شدن پاد ریسورسی که محاسبه کرده رو به پاد assign میکنه و دیگه تغییرش نمیده.
توی این مود VPA ریسورس رو به پادهای جدیدی که ساخته میشن اعمال میکنه و پادهایی که از قبل بالا بودن رو از بین میبره و با ریسورس جدید بالا میاره
در حال حاضر این مود مثل recreate کار میکنه اما در ورژن‌های بعدی قراره به این شکل بشه که بدون recreate کردن پادها درجا ریسورس اونها رو تغییر بده. یعنی الان قسمت auto داره کار نمیکنه و قراره تو نسخه‌‌های بعدی این موضوع درست بشه.
کلا سه تا بخش داره VPA برای اینکه عملکرد scale up کردن رو بهمون بده، اول admission controller هست که هر پادی که میاد توی کلاستر از این رد میده تا چک کنه که آیا این پاد برای خودش یا ورک‌لودی که بالای سرش هست VPA تعریف شده یا نه. بخش دوم VPA Recommender هست که متصل میشه به متریک‌سرور و دیتای مربوط به تاریخچه مصرف و مصرف الان پاد رو میگیره و بر اساس اون یه خروجی پیشنهادی برای میزان ریسورس درخواستی پاد و لیمیت اون بهمون میده و نهایتا بخش سوم که VPA Updater هست که هر یک دقیقه ران میشه و اگه پادی که داره ران میشه توی اون رنج مشخص شده توسط VPA Recommender نباشه اون رو میکشه تا دوباره در فرآیند بالا اومدن با ریسورس آپدیت شده بالا بیاد. البته قراره قستم Auto هم درست بشه که دیگه این VPA به صورت خودکار انجام بشه.
این نوع از Autoscaler ها رو زمانیکه کوبرنتیز رو از کلاد پروایدر سرویس بگیریم و اون کلاد پروایدر قابلیتش رو بهمون بده میتونیم استفاده کنیم، به این شکل که مثلا تعریف می‌کنیم که در زمان لازم تعداد نودهای کلاسترمون رو بیشتر کنه، مثلا به AWS بگی که زمان جشنواره یا پیک فروش یا موارد مشابه ... اگه نیاز شد نودهای ورکر کلاستر من رو تا سقف ده تا زیاد کن. اونوقت میگن خدا نیست :)
با استفاده از CA ما میتونیم کلاستر کوبرنتیز خودمون رو Scale کنیم که خیلی قابلیت خوبی هست و این امکان باعث میشه که در زمان مورد نیاز وقتی منابع داخل کلاستر رو به انتها هست اون رو بزرگ کنیم و وقتی لود از کل کلاستر برداشته میشه اون رو کوچیک کنیم. دنیای جالبی هم اینجا وجود داره که چطور یه نود رو اضافه کنه و چطور اون رو خالی نگه داره یا رزرو کنه و کلی داستان دیگه که این جا داریم.
تو ادامه‌ی مسیرمون میریم سراغ نتورک کوبرنتیز 🔥
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
