استراتژی‌های استقرار در کوبرنتیز
چندتا از رایج‌ترین استراتژی‌های برای استقرار اپلیکیشن‌ها در کوبرنتیز
یکی از مزایای اصلی کوبرنتیز وجود Deploymentهاست. Deploymentها معمولاً توی یک فایل YAML پیکربندی می‌شن که توی این فایل، چرخه عمر اپلیکیشن‌ها و نحوه آپدیت شدن اون‌ها به صورت Declarative تعریف شده. Deployment Strategy یا استراتژی استقرار در Kubernetes روشی هست که ما نحوه آپدیت اپلیکیشن‌ها به نسخه جدیدتر رو تعریف می‌کنیم. بعضی از این استراتژی‌ها موجب به وجود اومدن Downtime و بعضی برای تست کردن اپلیکیشن استفاده می‌شن. توی این پست چندتا از این استراتژی‌ها رو معرفی می‌کنم.
۱- Recreating Deployment
توی این استراتژی، تمام پادها Terminate می‌شن و نسخه‌ی جدید جایگزین اون‌ها میشه. این یعنی سرویس‌دهی اپلیکیشن تا زمانی که پادهای جدید با موفقیت شروع به کار کنن، قطع میشه و امکان پاسخ‌دهی به درخواست کاربران رو نداره. این استراتژی برای محیط‌هایی مناسبه که قطعی کوتاه مدت نسبت به کندی بلند مدت (که ممکنه توی سایر استراتژی‌ها به وجود بیاد) ترجیح داده میشه. همینطور در بعضی مواقع که امکان اجرای همزمان ۲ نسخه از یک اپلیکیشن وجود نداره از این استراتژی برای آپدیت اپلیکیشن استفاده می‌کنن.
۲- Rolling Deployment
این استراتژی به صورت پیش‌فرض برای کاهش زمان Downtime، در کوبرنتیز استفاده میشه. برخلاف روش قبل، توی این روش تمام پادها Terminate نمی‌شن بلکه پادهای جدید طبق گزینه‌هایی که در Deployment تنظیم شده، یکی یکی جایگزین می‌شن. اگر مشکلی توی نسخه جدید اپلیکیشن وجود داشته باشه، می‌تونیم فرآیند آپدیت رو متوقف کرد یا به نسخه قبلی اپلیکیشن برگشت. توی این روش چون پادها یکی یکی جایگزین می‌شن، فرآیند ممکنه برای Clusterهای بزرگ زمان‌بر باشه.
توی این استراتژی ۲ گزینه مهم وجود دارن که با استفاده از اونا میشه فرآیند آپدیت رو به خوبی تنظیم کرد:
maxSurge: حداکثر پادهایی که Deployment مجاز هست در حین عملیات ایجاد کنه مشخص می‌کنه. می‌تونیم مقدار این متغیر رو یک عدد صحیح مثل ۲ قرار بدیم یا اینکه به صورت درصدی از کل تعداد پادها وارد کنیم. (مثلاً اگر ۶ پاد داشته باشیم و این مقدار رو ۱۰% قرار بدیم، تعداد پادهایی که مجاز به ایجادشون هست به بالا رُند میشه، یعنی ۱ پاد). اگر مقدار MaxSurge تنظیم نشه، مقدار پیش‌فرض ۲۵% هست.
maxUnavailable: حداکثر تعداد پادهایی که از دسترس خارج شدنشون در طول مدت آپدیت مجاز هست، مشخص می‌کنه. مقدار این متغیر رو هم میشه به عنوان یک عدد صحیح یا درصد تعریف کرد.
برای مثال اگر مقادیر پیش‌فرض یعنی ۲۵% برای maxSurge و maxUnavailable استفاده کنیم و در Deployment که قصد آپدیت کردنش به نسخه جدید داریم، ۸ پاد یا Replica داشته باشیم، maxSurge شامل ۲ پاد و maxUnavailable هم شامل ۲ پاد خواهد بود. یعنی اینکه در فرآیند آپدیت شرایط زیر برقرار خواهند شد:
حداکثر ۱۰ پاد (۸ پاد که نیاز داریم به اضافه ۲ پاد که در maxSurge تعریف شده) در طول آپدیت در حالت Ready خواهند بود.
حداقل ۶ پاد (۸ پاد که نیاز داریم منهای ۲ پاد که در maxUnavailable تعریف شده) همیشه در طول آپدیت Ready هستند.
اگر بخوام ساده‌تر توضیح بدم، maxSurge حداکثر پادهای جدیدی هستن که ایجاد می‌شن و maxUnavailable حداکثر پادهای قدیمی هستن که حذف می‌شن.
۳- Blue/Green Deployment
استراتژی آبی و سبز (در بعضی جاها بهش می‌گن قرمز و مشکی) به ما این امکان رو میده که نسخه جدیدی از اپلیکیشن رو بدون Downtime و بدون اینکه نسخه قبلی حذف بشه اجرا کنیم.
توی این استراتژی تنها یک نسخه از اپلیکیشن سرویس‌دهی انجام میده. بعد از انجام عملیات استقرار و تست نسخه جدید، ترافیک کاربران به نسخه جدید (سبز) هدایت میشه. می‌تونیم نسخه قدیمی (آبی) رو نگه داریم تا اگر مشکلی پیش اومد دوباره ترافیک رو به سمت نسخه قدیمی هدایت کنیم.
این استراتژی Downtime رو از بین می‌بره و ریسک‌های موجود در عملیات آپدیت رو کاهش میده چرا که همونطور که قبلاً گفتم در صورت بروز مشکل میشه بلافاصله به نسخه قبل برگشت. با این حال، به دلیل اینکه نسخه جدید در کنار نسخه قدیمی راه‌اندازی میشه، برای به کار گرفتن این استراتژی به منابع بیشتری نیاز داریم که این موضوع نیازمند هزینه بیشتری خواهد بود.
۴- Canary Deployment
توی این استراتژی نسخه‌ی جدید اپلیکیشن رو برای گروه کوچکی از کاربران منتشر می‌کنیم تا صحت عملکرد نسخه‌ی جدید تست بشه. در حقیقت، نسخه جدید اپلیکیشن رو در کنار نسخه قدیمی مستقر می‌کنیم به طوری که نسخه قدیمی‌تر به اکثر کاربران سرویس‌دهی انجام بده و نسخه‌ی جدید به تعداد کمی از کاربران تستی سرویس‌دهی کنه. نسخه‌ی جدید اپلیکیشن بعد از انجام تست و اطمینان از صحت عملکرد برای کاربران بیشتری ارائه میشه.
برای مثال اگر توی کلاستر کوبرنتیز خودمون ۱۰۰ پاد داشته باشیم، ۹۵ تا پاد می‌تونن نسخه ۱ اپلیکیشن رو اجرا کنن و ۵ تای دیگه نسخه ۲ اپلیکیشن رو اجرا کنن. توی این حالت ۹۵ درصد کاربران از نسخه قدیمی سرویس می‌گیرن و ۵ درصد از کاربران از نسخه جدید. البته راه حل منطقی اینه که این تنظیمات توی لود بالانسر به طوری انجام بشه که فارغ از تعداد پادها، تنها ترافیک ۵% از کاربران به نسخه جدید هدایت بشه.
حرف آخر
توی این پست من ۴ تا از رایج‌ترین استراتژی‌ها رو توضیح دادم ولی استراتژی‌های پیشرفته‌تر و پیچیده‌تری هم وجود داره که می‌تونه در شرایط مختلف مورد استفاده قرار بگیره. درک درست از نحوه استفاده و به کارگیری این استراتژی‌ها، ابزارهایی که برای به کارگیری اون‌ها لازم هست و البته مزایا و معایب هرکدوم از اون‌ها موضوع خیلی مهمیه. انتخاب استراتژی متناسب با محیط عملیاتی، رابطه مستقیمی با کاهش زمان Downtime و بهبود بازخورد کاربران داره و موجب ارتقای محصول یا اپلیکیشن شما میشه.