چه زمانی از Docker Compose به کوبرنتیز مهاجرت کنیم؟

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

Docker Compose چه چیزی ندارد؟

Compose برای اجرای چند کانتینر روی یک سرور طراحی شده است. محدودیت‌های اصلی‌اش از همین‌جا می‌آید:

• اگر سرور از کار بیفتد، همه‌ی سرویس‌ها از کار می‌افتند. هیچ جابه‌جایی خودکاری به سرور دیگر وجود ندارد.
• مقیاس‌پذیری افقی بین چند سرور ندارد؛ فقط می‌توانید سرور را بزرگ‌تر کنید.
• استقرار بدون قطعی (Rolling Update) به‌صورت داخلی ندارد و باید با Reverse Proxy و اسکریپت آن را بسازید.
• مقیاس‌پذیری خودکار بر اساس بار ندارد.

اگر هیچ‌کدام از این‌ها برای شما مشکل واقعی نیست، Compose احتمالاً هنوز ابزار درستی است؛ به شرط اینکه درست پیکربندی شده باشد (۱۰ اشتباه رایج Docker Compose در Production را ببینید).

نشانه‌هایی که به کوبرنتیز نیاز دارید

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

نشانه‌هایی که هنوز به کوبرنتیز نیاز ندارید

• همه‌ی سرویس‌ها روی یک یا دو سرور به‌راحتی جا می‌شوند و منابع آزاد دارند.
• یک مونولیت (لاراول، جنگو یا Node.js) با دیتابیس و Redis دارید.
• هیچ‌کس در تیم تجربه‌ی کوبرنتیز ندارد و بودجه‌ای هم برای آموزش یا پشتیبانی نیست.
• مشکل فعلی شما در واقع نبود CI/CD، مانیتورینگ یا بکاپ است. کوبرنتیز هیچ‌کدام از این‌ها را خودبه‌خود حل نمی‌کند.
• هدف اصلی «به‌روز بودن» یا رزومه است، نه یک مشکل عملیاتی مشخص.

یک چارچوب تصمیم ساده

گزینه‌های میانه

Docker Swarm

Swarm mode بخشی از خود Docker Engine است و فایل‌های Compose را با تغییرات کم اجرا می‌کند (docker stack deploy). چند سرور، Rolling Update، Secret و جابه‌جایی خودکار کانتینر در صورت خرابی نود را دارد و یادگیری آن چند روز طول می‌کشد، نه چند ماه. نقطه‌ضعفش اکوسیستم کوچک‌تر و توسعه‌ی کندتر در مقایسه با کوبرنتیز است؛ برای پروژه‌های بلندمدت، وضعیت نگه‌داری آن را بررسی کنید.

HashiCorp Nomad

یک زمان‌بند ساده‌تر از کوبرنتیز که علاوه بر کانتینر، برنامه‌های غیرکانتینری را هم اجرا می‌کند. مجوز محصولات HashiCorp در سال ۲۰۲۳ از متن‌باز به BSL تغییر کرد؛ قبل از انتخاب، شرایط فعلی مجوز را برای استفاده‌ی خودتان بررسی کنید.

k3s

یک توزیع سبک و کامل از کوبرنتیز که با یک باینری نصب می‌شود و روی سرورهای کوچک هم اجرا می‌شود. API آن همان کوبرنتیز است، پس هر چه یاد بگیرید و بسازید (Manifest، Helm Chart) بعداً روی کلاستر بزرگ‌تر هم کار می‌کند. برای تیم‌هایی که می‌خواهند به کوبرنتیز برسند اما با مقیاس کوچک شروع کنند، معمولاً بهترین نقطه‌ی شروع است.

کوبرنتیز مدیریت‌شده (Managed)

در این حالت ارائه‌دهنده‌ی ابری Control Plane را نگه می‌دارد و شما فقط Workloadها را مدیریت می‌کنید. این گزینه بخش بزرگی از بار عملیاتی را حذف می‌کند. سرویس‌های مدیریت‌شده‌ی بین‌المللی معمولاً از ایران قابل استفاده نیستند؛ اگر ارائه‌دهنده‌ی داخلی انتخاب می‌کنید، نسخه‌ی کوبرنتیز، سیاست ارتقا، امکان بکاپ و نوع ذخیره‌سازی (Storage Class) را دقیق بررسی کنید.

مسیر مهاجرت

۱. kompose فقط نقطه‌ی شروع است

ابزار kompose فایل Compose را به Manifestهای کوبرنتیز تبدیل می‌کند:

kompose convert -f docker-compose.yml -o k8s/

خروجی آن برای دیدن معادل هر بخش مفید است، اما برای Production آماده نیست: Probeها، محدودیت منابع، تعداد نسخه‌ها، Ingress، تنظیمات ذخیره‌سازی و اسرار را باید خودتان بازنویسی کنید. خروجی kompose را یک پیش‌نویس در نظر بگیرید.

۲. Helm برای بسته‌بندی و چند محیط

وقتی همان اپلیکیشن باید در Staging و Production با تنظیمات متفاوت اجرا شود، Manifestها را در یک Helm Chart بسته‌بندی کنید و تفاوت‌ها را در فایل‌های values نگه دارید. برای سرویس‌های آماده (مثل Redis یا ابزارهای مانیتورینگ) هم معمولاً Chart رسمی یا معتبر وجود دارد.

۳. ترافیک ورودی: Ingress یا Gateway API

جای Nginx یا Traefik جلوی Compose را یک Ingress Controller یا پیاده‌سازی Gateway API می‌گیرد. توجه کنید که پروژه‌ی پرکاربرد ingress-nginx در سال ۲۰۲۶ بازنشسته شده و دیگر به‌روزرسانی امنیتی دریافت نمی‌کند. برای کلاستر جدید، Gateway API یا یک Controller فعال دیگر را انتخاب کنید و اگر کلاستر فعلی شما از ingress-nginx استفاده می‌کند، برنامه‌ی جایگزینی آن را داشته باشید.

۴. داده‌ی پایدار: PersistentVolume

Volumeهای Compose روی دیسک همان سرور بودند. در کلاستر چندنودی، Pod ممکن است روی نود دیگری اجرا شود، پس به ذخیره‌سازی‌ای نیاز دارید که از همه‌ی نودها در دسترس باشد (مثل Ceph RBD، Longhorn یا Storage Class ارائه‌دهنده‌ی ابری). Ceph را در آموزش راه‌اندازی Ceph معرفی کرده‌ایم. فایل‌های آپلودی را هم بهتر است به Object Storage ببرید تا اپلیکیشن Stateless شود.

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

۵. اسرار

Secretهای کوبرنتیز به‌طور پیش‌فرض فقط Base64 هستند، نه رمزنگاری‌شده. رمزنگاری در etcd را فعال کنید، دسترسی به Secretها را با RBAC محدود کنید و برای نگه‌داری اسرار در گیت از ابزارهایی مثل Sealed Secrets یا External Secrets استفاده کنید.

۶. مهاجرت تدریجی

همه‌چیز را یک‌شبه منتقل نکنید. یک سرویس کم‌ریسک را اول منتقل کنید، مانیتورینگ و لاگ را روی کلاستر کامل کنید (مانیتورینگ با Prometheus و Grafana)، روند استقرار را در CI/CD بسازید و بعد سرویس‌های بعدی را جابه‌جا کنید.

هزینه‌ی واقعی نگه‌داری کوبرنتیز

• سخت‌افزار: برای کلاستر با تحمل خرابی، حداقل سه نود Control Plane (یا سرویس مدیریت‌شده) به‌علاوه‌ی نودهای Worker لازم است. سربار سیستمی هر نود هم از Compose بیشتر است.
• ارتقای نسخه: کوبرنتیز چند نسخه‌ی اصلی در سال منتشر می‌کند و هر نسخه فقط مدت محدودی پشتیبانی می‌شود. ارتقای کلاستر و افزونه‌ها کار دوره‌ای و دائمی است.
• اجزای جانبی: Ingress یا Gateway، Storage، مانیتورینگ، لاگ، cert-manager، بکاپ کلاستر. هر کدام نصب، پیکربندی و ارتقا دارد.
• دانش تیم: عیب‌یابی شبکه، DNS، Scheduling و ذخیره‌سازی در کوبرنتیز مهارت مشخصی می‌خواهد. یا باید آن را در تیم بسازید (آموزش تیم) یا از بیرون تأمین کنید.
• Registry و دسترسی: در ایران، دریافت ایمیج‌ها از Docker Hub، quay.io و registry.k8s.io ممکن است محدود باشد و کلاستر به یک Registry یا Proxy Cache داخلی نیاز دارد (دسترسی به Docker Hub از ایران).

جمع‌بندی

به کوبرنتیز مهاجرت کنید وقتی مشکلی دارید که کوبرنتیز حلش می‌کند: نیاز به چند سرور، تحمل خرابی، مقیاس خودکار یا مدیریت ده‌ها سرویس. اگر این مشکلات را ندارید، یک Compose درست پیکربندی‌شده با CI/CD، بکاپ و مانیتورینگ، ساده‌تر، ارزان‌تر و قابل‌اتکاتر است. و اگر در میانه هستید، k3s یا Swarm قدم کوچک‌تری است که راه را برای آینده باز نگه می‌دارد.

نمی‌خواهید این تصمیم و مهاجرت را تنها انجام دهید؟ تیم مروانت وضعیت فعلی زیرساخت شما را بررسی می‌کند، گزینه‌ی مناسب را پیشنهاد می‌دهد و مهاجرت را به‌صورت تدریجی و کم‌ریسک انجام می‌دهد. صفحه‌های کوبرنتیز و مهندسی پلتفرم و مهاجرت زیرساخت را ببینید.