کوبرنتیز چیست و چه زمانی به آن نیاز دارید؟

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

در این مقاله به زبان ساده توضیح می‌دهیم کوبرنتیز چیست، چه مشکلی را حل می‌کند، مفاهیم اصلی‌اش کدام‌اند و مهم‌تر از همه، از چه نشانه‌هایی می‌توانید بفهمید تیم شما واقعاً به آن نیاز دارد یا هنوز با چند سرور ابری بهتر پیش می‌رود.

کوبرنتیز به زبان ساده

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

اگر بخواهیم تشبیهی ساده بزنیم، کوبرنتیز مثل مدیر یک بندر است. کانتینرها بسته‌های نرم‌افزار شما هستند و سرورها کشتی‌ها. مدیر بندر نمی‌پرسد داخل هر کانتینر چیست؛ فقط مطمئن می‌شود هر کانتینر به جای درست برسد، کشتی‌ها بیش از ظرفیت بار نگیرند و اگر کانتینری آسیب دید، جایگزینش برسد.

کانتینر چیست و چرا به ارکستراسیون نیاز دارد؟

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

در این مقیاس، پرسش‌هایی پیش می‌آید که مدیریت دستی پاسخ‌گویشان نیست: اگر سروری از کار افتاد، کانتینرهایش کجا اجرا شوند؟ نسخه جدید چطور بدون قطعی منتشر شود؟ سرویس‌ها چطور یکدیگر را پیدا کنند؟ به مجموعه راه‌حل‌های خودکار برای این پرسش‌ها «ارکستراسیون کانتینر» می‌گویند و کوبرنتیز رایج‌ترین ابزار آن است.

مفاهیم اصلی کوبرنتیز

خوشه و نود

به مجموعه سرورهایی که کوبرنتیز مدیریت می‌کند خوشه (Cluster) می‌گویند و به هر سرور، نود (Node). بخشی از خوشه، که لایه کنترل نامیده می‌شود، تصمیم‌ها را می‌گیرد و نودهای کاری کانتینرها را اجرا می‌کنند.

پاد

کوچک‌ترین واحد اجرایی در کوبرنتیز پاد (Pod) است؛ یک یا چند کانتینر که با هم اجرا می‌شوند و شبکه و فضای ذخیره‌سازی مشترک دارند. پادها موقتی‌اند و ممکن است هر لحظه جایگزین شوند، برای همین نباید داده ماندگار را داخلشان نگه داشت.

دیپلویمنت و سرویس

دیپلویمنت (Deployment) تعیین می‌کند از یک نرم‌افزار چند نسخه اجرا شود و انتشار نسخه جدید چطور مرحله‌به‌مرحله انجام شود. سرویس (Service) یک نشانی پایدار برای مجموعه‌ای از پادها می‌سازد تا بقیه بخش‌ها بدون دانستن جای دقیق هر پاد با آن ارتباط بگیرند.

حالت مطلوب

مهم‌ترین ایده کوبرنتیز «حالت مطلوب» است. شما در فایل‌های پیکربندی می‌نویسید سیستم باید چه شکلی باشد و کوبرنتیز مدام وضعیت واقعی را با آن مقایسه و اختلاف‌ها را برطرف می‌کند. همین ایده پایه روش GitOps است که در ادامه به آن می‌پردازیم.

کوبرنتیز چه مزایایی دارد؟

• بازیابی خودکار: اگر کانتینر یا نودی از کار بیفتد، کوبرنتیز پادها را جای دیگری اجرا می‌کند.
• انتشار تدریجی: نسخه جدید مرحله‌به‌مرحله جایگزین نسخه قبلی می‌شود و در صورت مشکل امکان بازگشت هست.
• مقیاس‌پذیری: تعداد نسخه‌های هر سرویس با یک تغییر ساده یا به‌صورت خودکار بر اساس بار تغییر می‌کند.
• استفاده بهتر از منابع: کانتینرهای مختلف روی نودها چیده می‌شوند تا ظرفیت کمتری هدر برود.
• یکسانی محیط‌ها: محیط آزمایش و محیط اصلی با پیکربندی مشابه تعریف می‌شوند.

چه زمانی به کوبرنتیز نیاز ندارید؟

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

نشانه‌هایی که می‌گوید وقت کوبرنتیز رسیده است

• تعداد سرویس‌ها زیاد شده و هر انتشار به هماهنگی دستی میان چند نفر نیاز دارد.
• بار کاری نوسان زیادی دارد و افزودن و کم کردن سرور به‌صورت دستی وقت‌گیر شده است.
• تیم چند محیط آزمایش و پیش‌انتشار می‌خواهد که یکسان با محیط اصلی باشند.
• قطعی در زمان انتشار نسخه جدید دیگر قابل قبول نیست.
• نرم‌افزار از قبل کانتینری شده و تیم با مفاهیم کانتینر آشناست.

انتشار خودکار نرم‌افزار روی کوبرنتیز

استفاده از کوبرنتیز روی زیرساخت ابری این مزیت را دارد که نودها، دیسک‌ها و شبکه را بدون خرید سخت‌افزار و بر اساس نیاز در اختیار دارید. اما حتی با زیرساخت آماده، انتشار نرم‌افزار روی کوبرنتیز نیاز به نظم دارد. روش GitOps پاسخی به همین نیاز است: پیکربندی و نسخه موردنظر نرم‌افزار در مخزن Git نگه داشته می‌شود و سیستم استقرار، خوشه را با آن هماهنگ می‌کند.

سرویس انتشار خودکار نرم‌افزار ابر درسا بر همین اساس کار می‌کند: کد را از مخزن Git برمی‌دارد و روی کوبرنتیز منتشر می‌کند، نسخه‌های ساخته‌شده را نشان می‌دهد، برای هر نسخه (Artifact) می‌توانید اسکن امنیتی اجرا کنید و گزارشش را در پنل ببینید، و امکان به‌روزرسانی، بازگشت به نسخه قبل و انتقال میان محیط‌ها را از پنل فراهم می‌کند. برای انتشارهای حساس هم می‌توانید تأیید مسئول مربوط را الزامی کنید. به این ترتیب همیشه معلوم است کدام نسخه در حال اجراست.

چک‌لیست آمادگی برای مهاجرت به کوبرنتیز

• نرم‌افزار کانتینری شده و ایمیج‌ها در یک مخزن مشخص نگه داشته می‌شوند.
• تنظیمات و رمزها از کد جدا شده‌اند و از طریق متغیرها یا فایل‌های پیکربندی داده می‌شوند.
• سرویس‌ها بدون حالت طراحی شده‌اند و داده ماندگار در پایگاه‌داده یا فضای ذخیره‌سازی بیرونی است.
• مسیرهای بررسی سلامت برای هر سرویس تعریف شده است.
• برای پایش، جمع‌آوری لاگ و هشدار برنامه دارید.
• حداقل یک نفر در تیم مسئول یادگیری و نگهداری خوشه است.
• مسیر انتشار و بازگشت نسخه پیش از مهاجرت روی محیط آزمایشی تمرین شده است.

پرسش‌های متداول

کوبرنتیز با داکر چه فرقی دارد؟

این دو رقیب هم نیستند. Docker ابزاری برای ساخت و اجرای کانتینر است و کوبرنتیز ابزاری برای مدیریت تعداد زیادی کانتینر روی چند سرور. معمولاً ایمیج‌ها با Docker یا ابزار مشابه ساخته می‌شوند و کوبرنتیز آن‌ها را اجرا و مدیریت می‌کند.

پایگاه‌داده را هم داخل کوبرنتیز اجرا کنم؟

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

یادگیری کوبرنتیز برای یک تیم کوچک چقدر سخت است؟

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

جمع‌بندی

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