چرا همیشه به Kubernetes نیاز ندارید؟

Kubernetes در رزومه و گفتگوهای فنی درخشان است؛ در سرور نیمه‌شب برای تیمی که هنوز Rollback تمرین‌نشده دارد، اغلب منبع پیچیدگی است. مستندات رسمی خودش مرز می‌کشد: K8s PaaS همه‌چیزتمام نیست، CI را نمی‌سازد، لاگ و مانیتورینگ را تحمیل نمی‌کند، و اپ را build نمی‌کند. یعنی بخش بزرگی از مسیر تحویل نرم‌افزار هنوز روی دوش شماست — فقط لایهٔ خوشه اضافه شده است.

این مقاله برای کسانی است که فشار «همه رفته‌اند روی K8s» را حس می‌کنند. هدف ضدیت با Kubernetes نیست؛ هدف هم‌ترازی ابزار با درد و ظرفیت تیم است.

اگر مقالهٔ ۱۰۹ را خوانده‌اید، قابلیت‌ها را می‌شناسید. اینجا معیار تعویق، جایگزین‌ها، و نشانه‌های رسیدن وقت مهاجرت را می‌گوییم.

پاسخ کوتاه

اگر یک یا چند Container روی یک میزبان (یا دو میزبان ساده) با Deploy تکرارپذیر، healthcheck و پشتیبان نیازتان را پوشش می‌دهد، Kubernetes ضروری نیست. Compose، سرویس ابری سطح اپ (PaaS)، یا حتی یک VM با Docker Engine می‌تواند ماه‌ها یا سال‌ها کافی باشد. وقتی تعداد نود، نیاز به خودترمیمی گسترده، انتشار چندنودی، و تیم عملیات واقعاً از مدیریت خوشه پشتیبانی کرد، K8s (ترجیحاً managed) معنا پیدا می‌کند.

نشانهٔ غلط برای شروع: کپی کردن معماری شرکت‌های hyperscale، یا استخدام بر اساس «باید K8s بلد باشد» قبل از داشتن ترافیک یا پیچیدگی متناسب.

ابزار مقیاس را قبل از درد مقیاس نخرید؛ هزینهٔ یادگیری را از جیب پایداری محصول می‌پردازید.

چه چیزی را K8s حل نمی‌کند (و شما هنوز باید حل کنید)

بر اساس بخش «What Kubernetes is not»:

• کیفیت کد، تست، و طراحی دامنه را درست نمی‌کند.
• pipelineی CI/CD را جایگزین فرهنگ انتشار نمی‌کند.
• انتخاب و ادارهٔ دیتابیس، صف، و cache را حذف نمی‌کند.
• مشاهده‌پذیری را کامل سوار نمی‌کند؛ باید متریک، لاگ و هشدار را خودتان یکپارچه کنید.
• پچ و سخت‌سازی نودها را یک‌کلیکه نمی‌کند.

اگر این پایه‌ها ضعیف‌اند، خوشه فقط سطح شکست را رسمی‌تر و دیباگ را سخت‌تر می‌کند.

هزینه‌های واقعی پذیرش زودهنگام

• منحنی یادگیری مفاهیم و اشیاء API برای کل تیم.
• زمان ارتقا، سازگاری add-onها، و مدیریت گواهی/شبکه.
• نیاز به سیاست امنیتی، RBAC، و محدودیت منابع از روزهای اول.
• هزینهٔ مالی کنترل‌پلین و نودهای اضافی نسبت به یک VPS.
• افزایش زمان تشخیص حادثه وقتی دانش خوشه نازک است.

تیم دو تا پنج نفره که محصول را هم می‌سازند، بودجهٔ توجه محدودی دارند. هر ساعت روی etcd و CNI از ساعت روی ارزش کاربر کم می‌کند — مگر اینکه بدون خوشه واقعاً گیر کرده باشید.

جایگزین‌های منطقی به ترتیب سادگی

1. یک VM/VPS + Docker: Image نسخه‌دار، Deploy اسکریپتی، healthcheck.
2. Docker Compose روی یک میزبان: چند سرویس، شبکه و Volume اعلانی.
3. دو محیط جدا (Staging/Production) با همان artifact — بدون خوشه.
4. PaaS یا سرویس کانتینری مدیریت‌شدهٔ سطح اپ: اگر می‌خواهید زیرساخت را کمتر ببینید.
5. Managed Kubernetes: وقتی به API و مدل K8s نیاز دارید ولی نمی‌خواهید کنترل‌پلین بسازید.
6. Self-managed Kubernetes: فقط با تیم عملیات مشخص و دلیل روشن.

بیشتر محصولات B2B و محتوایی در پله‌های ۱–۴ سال‌ها زنده می‌مانند. پرش به ۶ از روی مد، ضدپایداری است.

جدول نشانه: هنوز نه / وقتش رسیده

اشتباه «میکروسرویس پس حتماً K8s»

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

Kubernetes برای microservice اجباری نیست؛ برای مدیریت Container در مقیاس طراحی شده است. می‌توانید microservice را بدون K8s و مونولیت را روی K8s اجرا کنید — مستندات می‌گوید نوع workload را محدود نمی‌کند.

چه چیزهایی را قبل از K8s درست کنید

• Artifact یکسان بین Staging و Production (Image digest).
• مسیر Rollback تمرین‌شده.
• Secret جدا از کد و Image.
• حداقل مانیتورینگ و لاگ قابل جستجو.
• CI که تست و build را پایدار کند.

این‌ها روی Compose هم لازم‌اند؛ بدون آن‌ها K8s فقط سرعت انتشار مشکل را بالا می‌برد.

اگر مدیر یا سرمایه‌گذار پرسید «چرا K8s نداریم؟»

پاسخ حرفه‌ای: «چون ظرفیت و ترافیک فعلی با Docker/Compose و محیط‌های جدا پوشش داده می‌شود؛ هزینهٔ عملیات خوشه الان از فایده‌اش بیشتر است. معیار مهاجرت را تعریف کرده‌ایم: [تعداد نود / نیاز خودترمیمی / الگوی انتشار]. وقتی به آستانه رسیدیم، managed Kubernetes را ارزیابی می‌کنیم.» این زبان تصمیم است نه دفاع از تنبلی.

جمع‌بندی برای تصمیم

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

این هفته به‌جای نصب خوشه: Deploy و Rollback و مشاهده‌پذیری مینیمال را روی مسیر فعلی محکم کنید. وقتی آن‌ها پایدار شد، ارزیابی K8s مبتنی بر داده است نه ترس از عقب ماندن.

منابع و مراجع

• Kubernetes Docs — What Kubernetes is not — https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
• Kubernetes Docs — Overview — https://kubernetes.io/docs/concepts/overview/
• Docker Docs — Compose application model — https://docs.docker.com/compose/intro/compose-application-model/

برای تعریف K8s مقالهٔ ۱۰۹ و برای مقایسه با Docker مقالهٔ ۱۱۱ را ببینید.