کوبرنتیز (Kubernetes) چیست و چرا همه درباره‌اش صحبت می‌کنند؟

کوبرنتیز (Kubernetes یا به اختصار K8s) یک پلتفرم متن‌باز (open-source) برای اورکستراسیون کانتینرها است. به زبان ساده، وقتی شما برنامه‌هایتان را داخل کانتینرهای داکر (Docker) بسته‌بندی می‌کنید، کوبرنتیز مسئولیت مدیریت، مقیاس‌پذیری، به‌روزرسانی، مانیتورینگ و خودترمیمی صدها یا هزاران کانتینر را در صدها سرور بر عهده می‌گیرد، بدون اینکه شما مجبور باشید دستی دخالت کنید.

کوبرنتیز در سال ۲۰۱۴ توسط گوگل معرفی شد (بر اساس سیستم داخلی گوگل به نام Borg) و یک سال بعد به بنیاد CNCF اهدا شد. از آن زمان تا امروز (نوامبر ۲۰۲۵) به استاندارد صنعتی واقعی برای اجرای برنامه‌های ابری تبدیل شده است. تقریباً تمام شرکت‌های بزرگ فناوری (گوگل، آمازون، مایکروسافت، نتفلیکس، اسپاتیفای، اوبر و …) و حتی بانک‌ها و سازمان‌های دولتی در سراسر جهان از آن استفاده می‌کنند.

چرا K8s؟ 

چون کلمه Kubernetes با حرف K شروع می‌شود و با s تمام می‌شود و بین این دو حرف دقیقاً ۸ حرف دیگر وجود دارد (u-b-e-r-n-e-t-e)، به جای نوشتن کامل ۱۰ حرفی آن، از شکل کوتاه K8s استفاده می‌کنند. پس هر جا K8s دیدید، دقیقاً یعنی Kubernetes! 😄

چرا اینقدر محبوب شده؟

1. مقیاس‌پذیری عظیم: نتفلیکس روزانه بیش از ۱۰۰٬۰۰۰ کانتینر را با کوبرنتیز مدیریت می‌کند و در لحظات پیک ترافیک به‌صورت خودکار هزاران کانتینر جدید بالا می‌آورد.
2. قابلیت حمل عالی (Portability): یک‌بار YAML بنویسید، روی لپ‌تاپ، سرور داخلی، AWS، گوگل کلاد، آزور یا حتی ابرهای ایرانی اجرا کنید.
3. خودترمیمی (Self-healing): اگر یک کانتینر کرش کند، کوبرنتیز بلافاصله آن را دوباره راه‌اندازی می‌کند.
4. به‌روزرسانی بدون قطعی (Zero-downtime deployment): با استراتژی Rolling Update یا Blue-Green می‌توانید نسخه جدید را بدون یک ثانیه قطعی منتشر کنید.
5. اکوسیستم غول‌آسا: بیش از ۵۰۰٬۰۰۰ توسعه‌دهنده و هزاران ابزار جانبی (Helm, ArgoCD, Istio, Prometheus, Karpenter و …) دور آن شکل گرفته است.
6. هوش مصنوعی و مدل‌های بزرگ: در سال ۲۰۲۵ اجرای مدل‌های LLM و آموزش توزیع‌شده روی صدها GPU تقریباً بدون کوبرنتیز غیرممکن است.

در ایران هم وضعیت مشابه است: تقریباً تمام استارت‌آپ‌های بزرگ (دیجی‌کالا، اسنپ، آپارات، کافه‌بازار، زرین‌پال، مالتینا و …) و بانک‌های مدرن به کوبرنتیز مهاجرت کرده‌اند چون دیگر با VM و سرورهای سنتی نمی‌شود رقابت کرد.

به عبارت دیگر، کوبرنتیز امروز همان نقشی را دارد که لینوکس ۲۵ سال پیش داشت: یک فناوری پایه که همه چیز روی آن ساخته می‌شود. به همین دلیل است که در رزومه‌های DevOps و Backend، ننوشتن «Kubernetes: Advanced» تقریباً یعنی حذف شدن از پروسه استخدام شرکت‌های خوب!

تاریخچه کامل کوبرنتیز (از ۲۰۰۳ تا نوامبر ۲۰۲۵)

ریشه واقعی کوبرنتیز به بیش از ۲۰ سال پیش برمی‌گردد:

۲۰۰۳–۲۰۱۳: دوران Borg و Omega در گوگل

گوگل از اوایل دهه ۲۰۰۰ برای مدیریت میلیون‌ها کانتینر داخلی خودش دو سیستم ساخته بود:

1. Borg (از سال ۲۰۰۳–۲۰۰۴): سیستم اصلی مدیریت کلاسترهای عظیم گوگل. تقریباً تمام سرویس‌های گوگل (جیمیل، یوتیوب، نقشه، جستجو) تا سال ۲۰۱۵ روی Borg اجرا می‌شدند.
2. Omega (۲۰۱۲–۲۰۱۳): نسل دوم که درس‌های Borg را گرفت و معماری انعطاف‌پذیرتری داشت.

سه مهندس کلیدی گوگل که بعداً کوبرنتیز را ساختند (Joe Beda، Brendan Burns و Craig McLuckie) دقیقاً روی این سیستم‌ها کار می‌کردند و دردهای واقعی مدیریت صدها هزار کانتینر را می‌شناختند.

ژوئن ۲۰۱۴: تولد رسمی Kubernetes

۷ ژوئن ۲۰۱۴، گوگل در کنفرانس DockerCon پروژه Kubernetes را به صورت متن‌باز (open-source) معرفی کرد. اسم Kubernetes از واژه یونانی «کوبِرنِتِس» به معنی «هلمزمن» یا «راهبر کشتی» گرفته شده و لوگوی آن هم سکان کشتی است. نسخه ۱.۰ در جولای ۲۰۱۵ منتشر شد.

۲۰۱۵: تأسیس CNCF و استقلال از گوگل

گوگل کوبرنتیز را به بنیاد تازه‌تأسیس Cloud Native Computing Foundation (CNCF) اهدا کرد تا از کنترل انحصاری گوگل خارج شود. CNCF زیر چتر Linux Foundation قرار گرفت و اعضای اولیه آن گوگل، Red Hat، Microsoft، IBM، Docker، CoreOS، Cisco و … بودند. این حرکت باعث شد کوبرنتیز به سرعت به استاندارد صنعتی تبدیل شود (مشابه کاری که گوگل با اندروید کرد).

نقاط عطف مهم در سال‌های بعد

• ۲۰۱۶: نسخه ۱.۲–۱.۴ → اضافه شدن DaemonSet، Deployment و فدراسیون کلاسترها
• ۲۰۱۷: Red Hat اولین توزیع تجاری (OpenShift 3.6) را بر پایه کوبرنتیز منتشر کرد
• ۲۰۱۸: AWS سرویس EKS، مایکروسافت سرویس AKS و گوگل سرویس GKE مدیریت‌شده را راه‌اندازی کردند
• ۲۰۱۹: کوبرنتیز بزرگ‌ترین پروژه متن‌باز تاریخ بعد از لینوکس شد (بیش از ۳ میلیون خط کد، ۶۰٬۰۰۰ کامیت)
• ۲۰۲۰: پایان پشتیبانی از Docker به عنوان ران‌تایم پیش‌فرض (به دلیل اختلاف با شرکت Docker Inc.) → مهاجرت به containerd و CRI-O
• ۲۰۲۱: انتشار نسخه ۱.۲۲ → حذف کامل پشتیبانی از Dockershim
• ۲۰۲۲–۲۰۲۳: انفجار استفاده در هوش مصنوعی → Kubeflow، KubeRay و NVIDIA GPU Operator به پروژه‌های graduated CNCF رسیدند
• ۲۰۲۴: نسخه ۱.۳۰ → اضافه شدن ویژگی‌های Stable برای Structured Logging، CEL expressions و Sidecar Containers
• ۲۰۲۵ (تا نوامبر):
  – نسخه ۱.۳۲ در آگوست ۲۰۲۵ منتشر شد با ویژگی‌های جدید برای Dynamic Resource Allocation (DRA) و پشتیبانی کامل از eBPF-based networking
  – بیش از ۸۸٬۰۰۰ شرکت در نظرسنجی CNCF ۲۰۲۵ اعلام کردند که در پروداکشن از کوبرنتیز استفاده می‌کنند
  – سهم کوبرنتیز در بازار اورکستراسیون کانتینر به بیش از ۹۲ درصد رسید (Swarm کمتر از ۲ درصد، Nomad حدود ۴ درصد)

وضعیت امروز (نوامبر ۲۰۲۵)

کوبرنتیز دومین پروژه بزرگ تاریخ متن‌باز بعد از لینوکس است. بیش از ۱۰۰٬۰۰۰ توسعه‌دهنده فعال، ۲۰۰+ پروژه graduated در CNCF و میلیاردها دلار ارزش اکوسیستم تجاری (VMware Tanzu، Red Hat OpenShift، Rancher، Mirantis و …) دارد. حتی در ایران، تمام ابرهای بزرگ (آروان‌کلاد، ابر زس،ستون و …) سرویس مدیریت‌شده کوبرنتیز ارائه می‌دهند.

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

مقایسه Docker Swarm، Kubernetes و Docker Desktop: کدام برای شروع بهتر است؟

اگر تازه می‌خواهید وارد دنیای کانتینر و اورکستراسیون شوید، سه ابزار اصلی پیش رویتان است:

1. Docker Desktop
2. Docker Swarm
3. Kubernetes

هر کدام جایگاه خودش را دارد، اما یکی‌شان در سال ۲۰۲۵ عملاً انتخاب اجتناب‌ناپذیر است.

Docker Desktop در حقیقت یک محیط توسعه محلی است. با یک کلیک روی ویندوز یا مک نصب می‌شود و به شما اجازه می‌دهد داکر و حتی یک کوبرنتیز تک‌نودی خیلی سبک را روی لپ‌تاپتان اجرا کنید. یادگیری‌اش فوق‌العاده آسان است و برای تست، دیباگ و ساخت تصویرهای داکر عالی است، اما برای محیط واقعی پروداکشن طراحی نشده و روی چند سرور کار نمی‌کند. اگر فقط می‌خواهید اولین کانتینر Hello World را اجرا کنید یا با docker compose پروژه کوچکتان را بالا بیاورید، این بهترین نقطه شروع است.

داکر سوارم (Docker Swarm) حالت اورکستراسیون خود شرکت داکر است. با چند دستور ساده مثل docker swarm init و docker stack deploy می‌توانید یک کلاستر واقعی با چند سرور بسازید، scaling کنید، rolling update بدهید و حتی سرویس‌ها را روی چند نود پخش کنید. یادگیری‌اش بسیار سریع است و تقریباً همه چیز با دستورات داکر انجام می‌شود، بدون نیاز به یادگیری YAMLهای پیچیده. هنوز هم برای پروژه‌های کوچک، استارت‌آپ‌های خیلی کم‌بودجه یا شرکت‌هایی که نمی‌خواهند پیچیدگی کوبرنتیز را تحمل کنند، کاملاً کاربردی است؛ اما واقعیت این است که در سال ۲۰۲۵ تقریباً هیچ پروژه جدیدی با Swarm شروع نمی‌شود و اکثر شرکت‌هایی که قبلاً سوارم داشتند، در حال مهاجرت به کوبرنتیز هستند.

کوبرنتیز یا Kubernetes (یا K8s) پادشاه بلامنازع اورکستراسیون در سال ۲۰۲۵ است. پیچیدگی‌اش به مراتب بیشتر است، باید YAML بنویسید، مفاهیمی مثل Pod، Deployment، Service، Ingress، HPA، NetworkPolicy و ده‌ها مفهوم دیگر را یاد بگیرید، اما در عوض هیچ محدودیتی ندارد: از چند نود تا صدها هزار کانتینر، از GPU برای هوش مصنوعی تا Edge Computing، از GitOps تا Service Mesh؛ همه چیز را پوشش می‌دهد. تمام ابرهای بزرگ (AWS EKS، Google GKE، Azure AKS، آروان‌کلاد، زس و …) به صورت مدیریت‌شده کوبرنتیز ارائه می‌دهند و ۹۵ درصد آگهی‌های استخدام DevOps و Platform Engineering در ایران و جهان به دنبال مهارت کوبرنتیز در سطح متوسط به بالا هستند.

بازگشت سرمایه (ROI) پیاده‌سازی کوبرنتیز در سازمان‌های ایرانی

پیاده‌سازی کوبرنتیز در ایران معمولاً بین ۶ تا ۱۸ ماه به بازگشت سرمایه کامل می‌رسد و ROI متوسط آن بین ۲۰۰ تا ۶۵۰ درصد در سه سال اول است. این عدد از تجربیات واقعی شرکت‌های ایرانی بزرگ استخراج شده است.

صرفه‌جویی‌های اصلی که در ایران خیلی محسوس‌تر از کشورهای دیگر است:

۱. کاهش شدید هزینه سرور و VM

دیجی‌کالا بعد از مهاجرت کامل به K8s در سال ۱۴۰۰ اعلام کرد مصرف VMهایش ۴۲ درصد کم شده. اسنپ‌فود در سال ۱۴۰۲ اعلام کرد با استفاده از HPA و Spot Instanceهای ابر آروان، هزینه زیرساخت ماهانه‌اش ۵۸ درصد کاهش یافته (از حدود ۱.۸ میلیارد به کمتر از ۸۰۰ میلیون تومان در ماه).

۲. کاهش هزینه نیروی انسانی

یک تیم DevOps که قبلاً ۱۲ نفر برای مدیریت ۳۰۰ سرور VM نیاز داشت، بعد از کوبرنتیز با ۵–۶ نفر همان بار را (و حتی بیشتر) مدیریت می‌کند. در بازار کار ایران که حقوق متخصص senior بالاست (۱۰۰–۲۰۰ میلیون تومان در ماه)، صرفه‌جویی سالانه ۴–۶ میلیارد تومان فقط از نیروی انسانی کاملاً واقعی است.

۳. کاهش زمان Deploy و کاهش خطا

زمان انتشار نسخه جدید از چند ساعت به چند دقیقه رسیده. زرین‌پال اعلام کرد تعداد outageهای ماهانه از ۷–۸ مورد به کمتر از ۱ مورد رسیده که مستقیماً به معنای حفظ درآمد و جلوگیری از جریمه SLA با بانک مرکزی است.

۴. استفاده بهینه از منابع در شرایط تحریم و قیمت بالای سرور

چون خرید سرور فیزیکی یا لایسنس VMWare بسیار گران شده، کوبرنتیز روی سرورهای معمولی HPE/Dell یا حتی ابرهای داخلی (آروان، زس، آسیاتک) بهره‌وری ۷۰–۸۵ درصد می‌دهد در مقابل ۲۰–۳۰ درصد VMهای سنتی.

نتیجه: در شرایط اقتصادی ایران ۱۴۰۴ که هزینه انرژی، سرور و نیروی متخصص سرسام‌آور است، کوبرنتیز یکی از معدود فناوری‌هایی است که واقعاً در کمتر از ۱۸ ماه پول خودش را کامل درمی‌آورد و بعد از آن فقط سود خالص می‌دهد. به همین دلیل تقریباً تمام شرکت‌های بالای ۲۰۰ نفر نیروی فنی در حال برنامه‌ریزی یا اجرای مهاجرت به کوبرنتیز هستند.

کوبرنتیز و هوش مصنوعی: اجرای مدل‌های LLM بزرگ روی GPU

در سال ۲۰۲۵ دیگر هیچ تیم جدی هوش مصنوعی بدون کوبرنتیز مدل‌های بزرگ (LLM) را در پروداکشن اجرا نمی‌کند. مدل‌هایی مثل Llama-3-70B، Mixtral-8x22B، Gemma-2-27B یا حتی مدل‌های ۴۰۵B پارامتری به راحتی به ۴ تا ۱۶ کارت GPU A100/H100/H200 نیاز دارند و مدیریت دستی این منابع عملاً غیرممکن است. کوبرنتیز دقیقاً همان جایی است که این پیچیدگی را حل می‌کند.

چرا کوبرنتیز برای LLM ضروری شده؟

• تخصیص دینامیک GPU: با Device Pluginهای NVIDIA و GPU Operator، هر Pod می‌تواند دقیقاً تعداد GPU مورد نیاز (fractional هم ممکن است) را درخواست کند.
• autoscaling واقعی GPU: ابزار Karpenter یا Kueue + Cluster Autoscaler وقتی درخواست inference یا fine-tuning بالا می‌رود، به‌صورت خودکار نودهای جدید با ۸ کارت H100 از Spot Instanceهای ابر (آروان، زس، Hetzner، Vast.ai) بالا می‌آورد و وقتی بار کم شد، خاموش می‌کند؛ صرفه‌جویی ۶۰–۸۵ درصدی هزینه.
• multi-node training توزیع‌شده: با Kubeflow + PyTorch Operator یا Volcano می‌توانید یک مدل ۷۰B را روی ۶۴ کارت GPU در ۸ نود مختلف train کنید، بدون اینکه خودتان MPI یا NCCL را دستی تنظیم کنید.
• serving با صرفه‌جویی بالا: ابزارهای vLLM، TGI (Text Generation Inference)، TensorRT-LLM و Seldon Core مستقیماً به صورت Helm chart روی کوبرنتیز نصب می‌شوند و با Knative یا Kserve به‌صورت serverless کار می‌کنند؛ یعنی فقط وقتی درخواست می‌آید GPU مصرف می‌شود.