تعداد کاربر یا جذب سرمایه به‌تنهایی زمان مهاجرت به Kubernetes را تعیین نمی‌کند. استارتاپی با ترافیک بالا و معماری ساده ممکن است روی چند VM مدیریت‌شده پایدار باشد؛ تیمی با ده‌ها سرویس مستقل، release روزانه و الزام failover چند node زودتر از Kubernetes ارزش می‌گیرد. مسئله باید عملیاتی و قابل‌اندازه‌گیری باشد.
پاسخ سریع: وقتی یک host دیگر failure domain قابل‌قبول نیست، workloadها روی چند node باید schedule شوند، چند تیم release مستقل دارند و desired state/rollout استاندارد ارزش بیشتری از هزینه cluster ایجاد می‌کند، pilot Kubernetes منطقی است. پیش از آن image، health، CI/CD، observability، resource profile و راهبرد state باید بالغ باشند.
نشانه‌های واقعی نیاز
- SLO نیازمند تحمل خرابی node یا zone است.
- تعداد سرویس و deploy دستی از ظرفیت تیم عبور کرده است.
- workloadها منابع و زمان‌بندی متفاوت دارند.
- چند تیم به مرز دسترسی و self-service استاندارد نیاز دارند.
- rolling rollout، autoscaling یا policy declarative مکرراً لازم است.
- هزینه automation اختصاصی روی VMها از platform مشترک بیشتر شده است.
یک نشانه به‌تنهایی کافی نیست. اگر database هنوز single point of failure است، جابه‌جایی app به cluster ممکن است SLO را تغییر ندهد.
نشانه‌های کاذب
«شرکت‌های بزرگ استفاده می‌کنند»، «microservice داریم»، «می‌خواهیم cloud-native باشیم» یا «Kubernetes خودکار scale می‌کند» requirement نیست. کندی ناشی از query، memory leak، نبود cache یا release بی‌تست با scheduler حل نمی‌شود. ابتدا bottleneck را اندازه بگیرید و ساده‌ترین تغییر مؤثر را انتخاب کنید.
پیش‌نیاز اول: Image قابل‌تکرار
هر workload باید image نسخه‌دار، process اصلی درست، shutdown graceful و config بیرونی داشته باشد. اگر تیم هنوز داخل container زنده patch می‌کند یا tag شناور deploy می‌شود، Kubernetes drift را پنهان نمی‌کند. artifact یکسان باید در CI ساخته، تست و با digest به staging و production promote شود.
پیش‌نیاز دوم: Health و Resource Profile
readiness/liveness باید معنای درست داشته باشد. CPU و memory واقعی هر سرویس را برای requests/limits بدانید؛ اعداد حدسی scheduling را خراب یا OOM می‌سازند. startup time، concurrency و dependencyها را اندازه بگیرید. راهنمای مانیتورینگ baseline لازم برای تصمیم را شرح می‌دهد.
پیش‌نیاز سوم: CI/CD و Rollback
اعمال دستی manifest از لپ‌تاپ افراد، cluster را قابل‌اعتماد نمی‌کند. lint، policy، diff، approval، promotion و ثبت نسخه لازم‌اند. rollback کد باید با migration داده سازگار باشد. Kubernetes rollout را اجرا می‌کند، اما تصمیم business و سازگاری schema را نمی‌سازد.
پیش‌نیاز چهارم: Observability
Podها ephemeralاند و ممکن است جابه‌جا شوند؛ log محلی و SSH محور کافی نیست. metric، log، trace، event، audit و correlation لازم است. alert باید از دید سرویس و کاربر باشد، نه فقط تعداد Pod. بدون observability، self-healing می‌تواند crash را تکرار و شواهد را کوتاه‌عمر کند.
پیش‌نیاز پنجم: راهبرد State
دیتابیس، queue، upload و secret را جدا تصمیم بگیرید. PersistentVolume به‌تنهایی replication و backup نیست. managed database یا object storage می‌تواند ریسک migration را کم کند. اگر stateful workload داخل cluster می‌رود، operator، storage class، topology، backup و restore drill لازم است.
Control Plane مدیریت‌شده یا خودمدیریت؟
Managed Kubernetes patch و availability control plane را تا حدی به provider می‌سپارد، اما node pool، network، workload، RBAC، هزینه و upgrade compatibility همچنان بر عهده تیم است. cluster خودمدیریت کنترل بیشتری می‌دهد و عملیات etcd/control plane اضافه می‌کند. برای تیم کوچک، managed معمولاً نقطه بررسی منطقی‌تری است، نه پاسخ خودکار.
حداقل تیم و Ownership
عدد جادویی برای تعداد افراد وجود ندارد. باید owner برای cluster، security، release و incident مشخص باشد و پوشش on-call واقعی وجود داشته باشد. اگر فقط یک نفر Kubernetes می‌داند، bus factor و زمان مرخصی ریسک‌اند. مستندات، runbook، دسترسی break-glass و آموزش تیم بخشی از هزینه مهاجرت‌اند.
حاکمیت و Guardrail
توسعه‌دهنده نباید برای هر deploy دسترسی cluster-admin داشته باشد. namespace، service account، RBAC حداقلی، policy admission، quota و audit را پیش از self-service تعریف کنید. Secretها نباید در manifest plaintext یا log pipeline ظاهر شوند. guardrail باید بازخورد سریع در CI بدهد؛ policy مبهم که فقط production را block می‌کند، تیم را به bypass تشویق می‌کند.
چرخه Upgrade و API Deprecation
نسخه Kubernetes و add-onها عمر پشتیبانی دارند. پیش از هر upgrade، APIهای منسوخ، compatibility ingress/CNI/CSI، node drain، PodDisruptionBudget و ظرفیت جایگزین را بررسی کنید. cluster آزمایشی و rollout node pool مرحله‌ای لازم است. اگر تیم زمان منظم برای این چرخه ندارد، managed platform سطح بالاتر ممکن است انتخاب مناسب‌تری باشد.
هزینه پنهان
علاوه بر node و control plane، load balancer، egress، storage، registry، log/metric، backup و محیط‌های متعدد هزینه دارند. requests بیش‌برآوردشده ظرفیت را هدر می‌دهد و کم‌برآوردشده instability می‌سازد. زمان مهندسی برای upgrade، policy و incident را نیز به مدل هزینه اضافه کنید.
آیا یک Cluster برای همه محیط‌ها کافی است؟
اشتراک cluster هزینه را کم می‌کند اما blast radius و مرز دسترسی را پیچیده می‌سازد. جداسازی namespace معادل جداسازی account یا cluster نیست. حساسیت داده، تیم‌ها، compliance و تحمل خرابی معیارند. production و development نباید بدون policy و quota روی منابع هم اثر بگذارند.
معماری شبکه و Ingress
Service discovery، ingress، TLS، DNS و NetworkPolicy باید طراحی شوند. انتقال config Nginx و portهای Compose به objectهای متعدد بدون فهم مسیر ترافیک، outage می‌سازد. ابتدا جریان client تا app و dependency را مستند کنید. راهنمای Docker Network مفاهیم پایه name، port و exposure را روشن می‌کند.
Autoscaling چه زمانی ارزش دارد؟
وقتی workload stateless، metric مناسب و ظرفیت dependency مشخص دارد. HPA روی CPU برای هر سرویس مناسب نیست؛ queue length یا latency ممکن است بهتر باشد. node autoscaling نیز زمان provisioning و محدودیت quota دارد. اگر bottleneck دیتابیس است، replica app بیشتر می‌تواند connection storm ایجاد کند.
Pilot کم‌ریسک
- یک سرویس stateless و غیرحیاتی انتخاب کنید.
- SLO، هزینه و زمان عملیات فعلی را baseline بگیرید.
- CI/CD، secret، probe و resource را قبل از deploy آماده کنید.
- failure node، rollout و rollback را تمرین کنید.
- log، metric و هزینه واقعی را حداقل یک چرخه مشاهده کنید.
- نتیجه را با Compose/PaaS مقایسه کنید.
- سپس درباره platform عمومی تصمیم بگیرید.
معیار موفقیت Pilot
فقط «Pod اجرا شد» کافی نیست. زمان deploy و recovery، نرخ failure، تعداد گام دستی، هزینه، زمان on-call و رضایت توسعه‌دهنده را بسنجید. اگر platform team بیشتر وقتش را صرف نگهداری ابزار می‌کند و سرعت release بهتر نشده، scope یا ابزار را بازبینی کنید.
معیار توقف Pilot
از قبل بنویسید در چه شرایطی ادامه نمی‌دهید: هزینه بالاتر از بودجه، نبود owner on-call، recovery کندتر از baseline، وابستگی state حل‌نشده یا پیچیدگی امنیتی بدون نیروی کافی. توقف pilot شکست نیست؛ از قفل‌شدن هزینه جلوگیری می‌کند. artifact، مشاهده‌ها و gapها را نگه دارید تا در زمان مناسب دوباره ارزیابی شود.
Disaster Recovery خود Cluster
تعریف declarative workload مفید است، اما registry، secret، DNS، داده و دسترسی provider باید قابل‌بازیابی باشند. برای cluster خودمدیریت، control plane و etcd نیز طرح جدا می‌خواهند؛ در managed service، محدودیت backup و ساخت دوباره region را بررسی کنید. یک cluster دوم بدون تمرین cutover فقط هزینه است، نه DR اثبات‌شده.
مسیر مهاجرت مرحله‌ای
ابتدا سرویس stateless، سپس worker و dependencyهای کم‌ریسک را منتقل کنید. database را صرفاً برای کامل‌شدن نمودار جابه‌جا نکنید. DNS/traffic cutover، rollback به پلتفرم قبلی و dual-running محدود را طراحی کنید. از big bang migration چند سرویس و داده هم‌زمان بپرهیزید.
تصمیم را چه زمانی دوباره ارزیابی کنیم؟
تصمیم «فعلاً نه» دائمی نیست. پس از تغییر محسوس SLO، تعداد تیم‌ها، دفعات deploy، نیاز چند منطقه یا هزینه incident، ارزیابی را تکرار کنید. شاخص‌ها و فرض‌های تصمیم قبلی را نگه دارید تا بحث بعدی بر داده استوار باشد. بازبینی دوره‌ای مانع دو افراط می‌شود: مهاجرت زودهنگام به دلیل هیجان ابزار و ماندن طولانی روی معماری‌ای که دیگر failure domain یا سرعت انتشار موردنیاز کسب‌وکار را پوشش نمی‌دهد.
چه زمانی فعلاً Kubernetes نگیریم؟
اگر product-market fit در حال آزمون است، یک یا دو سرویس دارید، deploy کم است و یک VM ظرفیت دارد، بهبود Compose/PaaS احتمالاً بازده بیشتری دارد. مقایسه Compose و Kubernetes tradeoff را کامل‌تر نشان می‌دهد. قابلیت مهاجرت آینده را با image و contract خوب حفظ کنید.
اشتباه‌های رایج
- مهاجرت هم‌زمان app، database و CI
- نبود requests/limits و probe معتبر
- یک متخصص بدون جانشین
- cluster production بدون upgrade plan
- فرض اینکه managed یعنی بدون عملیات
- نادیده‌گرفتن egress و observability cost
- تعریف موفقیت فقط با تعداد Pod
برای ارزیابی مستقل
اگر هزینه قطعی و عملیات فعلی بالا رفته ولی معلوم نیست Kubernetes درمان آن است، DevOps استارتاپ می‌تواند readiness، SLO، هزینه و pilot را بدون تعهد زودهنگام به یک پلتفرم ارزیابی کند.
پرسش‌های متداول
از چه تعداد کاربر Kubernetes لازم می‌شود؟
آستانه ثابتی ندارد؛ معماری، SLO، deploy و تیم مهم‌تر از تعداد کاربرند.
آیا Microservice یعنی Kubernetes؟
نه؛ چند سرویس را می‌توان با ابزارهای دیگر اجرا کرد. پیچیدگی عملیاتی معیار است.
آیا دیتابیس را هم وارد Cluster کنیم؟
الزامی نیست؛ managed database اغلب انتخاب مستقل و کم‌ریسک‌تری است.
مهاجرت چقدر طول می‌کشد؟
به بلوغ image، CI/CD، state و تیم بستگی دارد؛ pilot زمان واقعی را بهتر از برآورد عمومی نشان می‌دهد.