کلاستر کوبرنتیز کاملاً اختصاصی

اگر یکی از این شرایط را دارید، کلاستر اختصاصی ارزش بررسی دارد. در غیر این صورت، قالب‌های آمادهٔ سرویس مدیریت‌شده سریع‌تر و ساده‌ترند:

قبل از درخواست کلاستر اختصاصی، بهتر است بدانید سرویس آماده دقیقاً چیست. کوبرنتیز مدیریت‌شده بر پایهٔ k3s ساخته می‌شود؛ توزیع سبک و استاندارد کوبرنتیز که با kubectl و Helm کار می‌کند. یک نود نقش کنترل‌پلِین دارد و بقیه نود کاری‌اند. پس از ساخت، فایل kubeconfig را از پنل دریافت می‌کنید.

هزینه برابر قیمت سرورهای نود به‌علاوهٔ ۲۰٪ کارمزد مدیریت است و هر ساعت از کیف پول کسر می‌شود. قیمت‌های زیر از قیمت لحظه‌ای پلن‌ها محاسبه شده‌اند:

هر دو گزینه خوشهٔ کوبرنتیز داخل ایران می‌دهند؛ انتخاب به اندازهٔ بار و میزان سفارشی‌سازی بستگی دارد. جدول زیر تفاوت‌های عملی را کنار هم گذاشته است.

قاعدهٔ سرانگشتی: اگر تیم شما هنوز در حال یادگیری کوبرنتیز است یا کمتر از ده سرویس دارد، از سرویس مدیریت‌شده شروع کنید. انتقال به کلاستر اختصاصی بعداً با همان manifest‌ها ممکن است.

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

موضوعات اصلی طراحی:

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

برای یک برآورد اولیه می‌توانید از قیمت سرورهای اختصاصی کمک بگیرید: پلن ۴ هسته و ۱۶ گیگابایت ساعتی ۱۲٬۰۰۰ تومان و پلن ۸ هسته و ۳۲ گیگابایت ساعتی ۲۵٬۰۰۰ تومان است. مثلاً خوشه‌ای با سه نود از هر کدام، دست‌کم سه برابر همان مبلغ هزینهٔ سرور دارد. قیمت همهٔ پلن‌ها در صفحهٔ سرور اختصاصی و قیمت‌گذاری آمده است.

تا پیش از پذیرش پیشنهاد مکتوب، هیچ هزینه یا تعهدی ندارید:

نودهای کلاستر اختصاصی فقط به شما تعلق دارند و بار کاری مشتری دیگری روی آن‌ها اجرا نمی‌شود. اما امنیت خوشه فقط به جداسازی نودها محدود نیست: دسترسی‌ها را با RBAC و حساب‌های جداگانه برای هر تیم محدود کنید، secret‌ها را در مخزن کد نگذارید و image‌ها را از منبع قابل اعتماد بگیرید.

برای ترافیک بین سرویس‌ها از NetworkPolicy استفاده کنید تا هر سرویس فقط با سرویس‌هایی حرف بزند که لازم است. سرویس‌های عمومی وب را می‌توانید پشت محافظت DDoS قرار دهید. جزئیات تقسیم مسئولیت امنیتی بین ما و تیم شما در پیشنهاد مکتوب نوشته می‌شود.

در کوبرنتیز، دو چیز باید پشتیبان داشته باشد: تعریف منابع خوشه و دادهٔ پایدار برنامه‌ها. تعریف منابع را در Git نگه دارید تا هر زمان بتوانید خوشه را از نو بسازید؛ این ساده‌ترین و مطمئن‌ترین روش است.

دادهٔ پایدار، مثل دیتابیس‌ها و فایل‌های آپلودی، جداگانه پشتیبان می‌خواهد. خروجی دوره‌ای دیتابیس‌ها را در فضای ذخیره‌سازی ابری نگه دارید یا برای دیتابیس اصلی از PostgreSQL مدیریت‌شده بیرون از خوشه استفاده کنید که بکاپ روزانه دارد. یک بار هم بازگردانی را آزمایش کنید.

اگر الان روی کوبرنتیز مدیریت‌شدهٔ ایران‌کلاد، یک خوشهٔ خودساخته یا سرویس دیگری هستید، مهاجرت با ابزارهای استاندارد کوبرنتیز انجام می‌شود. manifest‌ها یا chart‌های Helm را روی خوشهٔ جدید اعمال کنید، دادهٔ پایدار را منتقل کنید، سرویس‌ها را آزمایش کنید و در پایان رکوردهای DNS را تغییر دهید.

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

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

برای پایش، دست‌کم مصرف پردازنده و حافظهٔ نودها، وضعیت pod‌ها و فضای دیسک را زیر نظر بگیرید. ابزارهای متن‌باز مثل Prometheus و Grafana داخل خود خوشه به‌خوبی کار می‌کنند. وقتی مصرف حافظهٔ نودها مدام بالای هفتاد درصد است، وقت افزودن نود یا بزرگ‌کردن نودهاست؛ این تصمیم را بر اساس داده بگیرید، نه حدس.

برای اینکه تغییرات قابل ردیابی بمانند، هیچ تغییری را مستقیم با kubectl روی خوشهٔ تولید اعمال نکنید؛ همه‌چیز را از مسیر Git و خط CI/CD عبور دهید. این عادت هم خطای انسانی را کم می‌کند و هم بازسازی خوشه در صورت حادثه را ممکن می‌سازد.

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

سرویس مدیریت‌شدهٔ فعلی هم محدودیت‌های خودش را دارد: فقط یک نود و دو قالب ثابت. اگر این‌ها برای شما کافی است، از کوبرنتیز مدیریت‌شده یا نسخهٔ سبک K3s شروع کنید؛ هر وقت محدودیت واقعی دیدید، درخواست کلاستر اختصاصی را ثبت کنید.