کوبرنتیز (Kubernetes) چیست؟

کوبرنتیز (Kubernetes) که به‌اختصار K8s نیز نامیده می‌شود، یک پلتفرم متن‌باز و قدرتمند برای مدیریت، هماهنگ‌سازی (Orchestration) و مقیاس‌دهی خودکار برنامه‌های کانتینری (Containerized) است. به زبان ساده بخواهیم بگوییم کوبرنتیز چیست، فرض کنید اگر شما صدها کانتینر داکر داشته باشید، مدیریت دستی آن‌ها غیرممکن است؛ در این شرایط است کوبرنتیز می‌تواند استقرار و مدیریت آن‌ها را به‌صورت هوشمند و اتوماتیک انجام دهد.

این ابزار ابتدا توسط گوگل طراحی شد و اکنون توسط بنیاد CNCF توسعه می‌یابد. از سال ۲۰۱۴ که معرفی شد و خیلی زود توسط سازمان‌ها مورد استقبال قرار گرفت تا برنامه‌ها و خدمات توزیع‌شده را در مقیاس بزرگ اجرا کنند.

در این مقاله کوبرنتیز را به زبان ساده توضیح می‌دهیم و اجزا و معماری آن و تفاوت اصلی آن با داکر را توضیح می‌دهیم.

چرا به کوبرنتیز نیاز داریم؟

برای اینکه دقیقاً درک کنیم کوبرنتیز چیست باید نگاهی سریع به مسیر پرپیچ‌وخم زیرساخت‌های IT بیندازیم. داستان تولد K8s، داستان تلاش برای کارایی بیشتر و هزینه کمتر است. بیایید سه دوره اصلی را مرور کنیم:

۱. عصر سنتی (سرورهای فیزیکی):

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

۲. عصر مجازی‌سازی (Virtualization):

با ورود ماشین‌های مجازی (VMs)، توانستیم روی یک سرور فیزیکی، چندین ماشین مجازی مستقل اجرا کنیم. این کار هزینه‌ها را کاهش داد اما یک ایراد بزرگ داشت: هر VM نیاز به یک سیستم‌عامل کامل (OS) داشت که خودش گیگابایت‌ها رم و فضای دیسک اشغال می‌کرد و سنگین و کُند بود.

۳. عصر کانتینرها (Containers):

کانتینرها همه‌چیز را تغییر دادند. آن‌ها شبیه VMها هستند اما با یک تفاوت حیاتی: کانتینرها سیستم‌عامل را مجازی نمی‌کنند، بلکه هسته (Kernel) سیستم‌عامل میزبان را به اشتراک می‌گذارند. این یعنی کانتینرها فوق‌العاده سبک و سریع هستند.

تغییر معماری نرم‌افزار (تولد میکروسرویس‌ها)

درکنار تغییرات سخت‌افزاری، روش نوشتن برنامه‌ها هم عوض شد. قبلاً برنامه‌ها به‌صورت یکپارچه (Monolithic) نوشته می‌شدند؛ یعنی یک اکوسیستم نرم‌افزاری بزرگ که همه کارها (ثبت‌نام، پرداخت، انبارداری) را یک‌جا انجام می‌داد. مدیریت این سیستم‌ها سخت بود.

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

مقاله پیشنهادی: میکروسرویس (Microservice) چیست؟

اما مشکل جدید چه بود؟

کانتینرها عالی بودند، اما وقتی تعداد آن‌ها از ۱۰ به ۱۰۰۰ رسید، مدیریت دستی آن‌ها غیرممکن شد. اگر یک کانتینر وسط شب از کار می‌افتاد، چه کسی آن را ریستارت می‌کرد؟ اگر ترافیک سایت ۱۰ برابر می‌شد، چه کسی کانتینر جدید می‌ساخت؟

اینجا بود که نیاز به یک مدیر هوشمند احساس شد و پاسخ صنعت به این نیاز، کوبرنتیز بود. در واقع اگر از ما بپرسید K8s چیست، می‌گوییم: ناجیِ تیم‌های فنی برای رهایی از مدیریت دستی هزاران کانتینر سرگردان.

Kubernetes چه مشکلاتی را حل می‌کند؟

تیم‌های عملیاتی زیادی تاکنون با کوبرنتیز کار کرده‌اند و پس‌از بررسی تجربه آن‌ها می‌توانیم بگوییم که بااستفاده از این ابزار می‌توانیم انتظار داشته باشیم که مشکلات زیر برای ما حل شوند:

رفع مشکل داون‌تایم هنگام آپدیت (Downtime):

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

حل مشکل ناهماهنگی محیط تست و عملیات:

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

کاهش هزینه‌های زیرساخت:

بدون کوبرنتیز، معمولاً سرورها را برای روز مبادا (ترافیک اوج) قوی‌تر می‌خریدند که در روزهای عادی هدر می‌رفت (Over-provisioning). کوبرنتیز منابع را فشرده و بهینه استفاده می‌کند (Bin Packing).

بدون نیاز به مانیتورینگ ۲۴ ساعته:

اگر ساعت ۳ صبح یک سرور یا کانتینر کرش می‌کرد، ادمین باید بیدار می‌شد و دستی آن را ریستارت می‌کرد. کوبرنتیز این کار را اتوماتیک انجام می‌دهد (Self-healing).

ویژگی‌های کوبرنتیز

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

اگر بخواهیم به زبان ساده بگوییم کوبرنتیز چیست، باید به این ۴ قابلیت کلیدی اشاره کنیم که خیال تیم‌های دواپس (DevOps) را راحت کرده است:

۱. خودترمیمی

باید خودترمیمی را با یک مثال توضیح دهیم. سیستمی را درنظر بگیرید که اگر مثلا کارمندی پشت میز کارش بیهوش شود، سیستم بلافاصله یک نفر دیگر را دقیقاً با همان مهارت جایگزین او می‌کند! کوبرنتیز همین کار را می‌کند. اگر یک کانتینر خراب شود (Fail)، کوبرنتیز آن را می‌کشد و یکی جدید می‌سازد. اگر نود (Node) از دسترس خارج شود، کانتینرها را به نودِ سالم دیگری منتقل می‌کند.

۲. مقیاس‌پذیری خودکار

یکی از جذاب‌ترین بخش‌های مدیریت کانتینر با Kubernetes مقیاس‌پذیری آن است. شما می‌توانید به سیستم بگویید: «اگر استفاده از CPU بالای ۷۰٪ رفت، تعداد کانتینرها را ۲ برابر کن». به محض کاهش ترافیک، کوبرنتیز کانتینرهای اضافی را حذف می‌کند تا منابع (و پول شما) هدر نرود.

۳. توازن بار

کوبرنتیز ترافیک ورودی را هوشمندانه بین کانتینرها تقسیم می‌کند. اگر ترافیک ورودی به یک کانتینر خیلی زیاد شود، K8s با استفاده از سرویس‌های Kubernetes و آدرس‌دهی IP، بار را توزیع می‌کند تا هیچ بخشی از برنامه زیر فشار له نشود.

۴. مدیریت فضای ذخیره‌سازی

کانتینرها ذاتاً فرّار هستند (با حذف شدنشان، اطلاعاتشان هم می‌پرد). کوبرنتیز به شما اجازه می‌دهد سیستم‌های ذخیره‌سازی مختلف (مانند هارد دیسک سیستم، فضاهای ابری عمومی مثل AWS یا سرویس‌های ذخیره‌سازی ابری و…) را به‌صورت خودکار به کانتینرها متصل (Mount) کنید تا داده‌هایتان حفظ شود.

معماری کوبرنتیز

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

کلاستر کوبرنتیز چیست؟

کلاستر کوبرنتیز در واقع مجموعه‌ای از کامپیوترها (یا سرورها) است که به هم متصل شده‌اند تا مثل یک واحد یکپارچه عمل کنند. این کلاستر دو بخش حیاتی دارد:

1. بخش کنترل (Control Plane): که تصمیم می‌گیرد چه کاری انجام شود (مغز سیستم).
2. بخش نودها (Nodes): که کارهای محول شده را عملاً اجرا می‌کنند (عضلات سیستم).

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

بخش کنترل

بخش کنترل یا Control Plane، وظیفه مدیریت کل کلاستر را بر عهده دارد. در این بخش تمام تصمیم‌گیری‌های هوشمندانه، مثل زمان‌بندی (Scheduling)، شناسایی خرابی‌ها و پاسخ به رویدادها انجام می‌شود. در ادامه با ۴ جزء اصلی این اتاق فرمان آشنا می‌شویم:

۱. سرور API

دروازه ورودی کلاستر است. هر دستوری که شما (به‌عنوان کاربر) یا سایر اجزای سیستم بخواهند صادر کنند، باید حتماً از کانال kube-apiserver رد شود. این سرور مثل یک منشی دقیق، تمام درخواست‌ها را احراز هویت و اعتبارسنجی می‌کند و سپس اجازه ورود می‌دهد. هیچ‌کس در کلاستر بدون اجازه API Server آب هم نمی‌خورد!

۲. ذخیره‌ساز داده‌ها (etcd)

etcd را باید بایگانی کل سیستم بنامیم. تمام اطلاعات مربوط به کلاستر، تنظیمات، وضعیت پادها و هر تغییری که رخ می‌دهد، در etcd ذخیره می‌شود. این دیتابیس از نوع کلیدمقدار (Key-Value) است و بسیار حساس؛ چون اگر اطلاعات etcd پاک شود، انگار کلاستر حافظه‌اش را از دست داده است.

۳. زمان‌بندی‌کننده

وقتی شما می‌خواهید یک برنامه (Pod) جدید اجرا کنید، kube-scheduler نگاه می‌کند کدام نود (Node) فضای خالی دارد؟ کدام نود رم و CPU کافی دارد؟ سپس بهترین مکان را برای اجرای پاد شما انتخاب می‌کند. در واقع کنترل خوشه‌های Kubernetes و توزیع مناسب بار، هنرِ دستِ این زمان‌بندی‌کننده است.

۴. مدیر کنترلرها

وظیفه kube-controller این است که دائماً وضعیت موجود را با وضعیت مطلوب مقایسه کند.

• مثال: شما گفته‌اید همیشه باید ۳ نسخه از برنامه من اجرا شود. اگر یکی از آن‌ها خراب شود، مدیر کنترلر متوجه می‌شود که الان ۲ نسخه داریم (وضعیت موجود) ولی باید ۳ تا باشد (وضعیت مطلوب). پس دستور ساخت یک نسخه جدید را صادر می‌کند.

بخش نودها (Nodes)

هر کلاستر حداقل به یک نود کاری (Worker Node) نیاز دارد (هرچند در محیط‌های عملیاتی معمولاً چندین نود وجود دارد). نودها می‌توانند ماشین فیزیکی یا مجازی باشند که کانتینرها روی آن‌ها زنده می‌شوند. اجزای اصلی یک نود عبارت‌اند از:

۱. کوبلت (Kubelet)

روی هر نود، یک کنترلگر به نام Kubelet نصب شده است. کوبلت مثل سرکارگر آن نود عمل می‌کند. او دستورات را از Control Plane می‌گیرد و مطمئن می‌شود که کانتینرهای موردنظر در آن نود به‌درستی اجرا شده و سالم هستند. اگر مشکلی برای کانتینر پیش بیاید، کوبلت فوراً به بخش کنترل گزارش می‌دهد.

۲. پروکسی شبکه

مدیریت شبکه در محیط‌های توزیع‌شده پیچیده است، اما kube-proxy آن را ساده می‌کند. این بخش قوانین شبکه را روی هر نود تنظیم می‌کند تا ترافیک بتواند بین پادها و دنیای بیرون جریان پیدا کند. بدون Kube-proxy، بخش‌های مختلف برنامه شما نمی‌توانند با هم یا با اینترنت صحبت کنند.

۳. اجراکننده کانتینر

در نهایت، ما نیاز به نرم‌افزاری داریم که بتواند خودِ کانتینر را اجرا کند. اگرچه داکر (Docker) معروف‌ترین نام در این زمینه است، اما کوبرنتیز با سایر اجراکننده‌ها مثل containerd یا CRI-O نیز کار می‌کند. وظیفه این بخش ساده است: دریافت ایمیج برنامه و تبدیل آن به یک کانتینر درحال اجرا.

تمام این اجزا دست‌به‌دست هم می‌دهند تا وقتی شما دستوری صادر می‌کنید، بدون اینکه درگیر جزئیات فنی شوید، برنامه شما همیشه در دسترس و پایدار باقی بماند.

شناخت ابزارهای Kubernetes

رسیدن به پاسخ کوبرنتیز چیست، بدون شناخت ابزارهای آن غیرممکن است. در ادامه مهم‌ترین آن‌ها را خیلی ساده توضیح می‌دهیم.

۱. پاد (Pod)

در کوبرنتیز، ما مستقیماً با کانتینرها سر و کار نداریم؛ بلکه با چیزی به نام Pod کار می‌کنیم. پاد کوچک‌ترین واحد قابل‌اجرا در کوبرنتیز است.

• نکته مهم: یک پاد معمولاً شامل یک کانتینر است، اما می‌تواند چند کانتینر را هم که نیاز دارند شدیداً به هم نزدیک باشند (مثلاً منابع شبکه مشترک داشته باشند) در خود جای دهد.

۲. سرویس (Service)

پادها عناصر فانی هستند! آن‌ها ممکن است خراب شوند، پاک شوند یا با تغییر نسخه برنامه جایگزین شوند. هر بار که پاد جدیدی ساخته می‌شود یک IP جدید می‌گیرد و مفهوم سرویس اینجا معنا پیدا می‌کند.

• کاربرد: سرویس یک آدرس ثابت و پایدار است که تغییر نمی‌کند. درخواست‌ها را می‌گیرد و به پادهای موجود در پشت صحنه تحویل می‌دهد. بدون سرویس، پادها نمی‌توانند یکدیگر را پیدا کنند.

همان‌طور که می‌بینید، درخواست‌ها از طریق دروازه ورودی (API Gateway) مدیریت شده و به سمت پادها (که در معماری ریزسرویس به آن‌ها Nano Service هم می‌گویند) هدایت می‌شوند تا در نهایت به دیتابیس برسند.

۳. نیم‌اسپیس (Namespace)

فرض کنید شما یک کلاستر بزرگ دارید که هم تیمِ توسعه (Dev) و هم تیمِ عملیات (Ops) از آن استفاده می‌کنند. برای اینکه کارهای این دو تیم با هم تداخل نداشته باشد از Namespace استفاده می‌کنیم.

• کاربرد: نیم‌اسپیس کلاستر فیزیکی شما را به چندین کلاستر مجازی تقسیم می‌کند. مثلاً می‌توانید یک Namespace به نام Production داشته باشید و یکی به نام Test تا اگر در محیط تست اشتباهی رخ داد، سایت اصلی شما (Production) آسیب نبیند.

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

اصطلاح	کارکرد به زبان ساده
Deployment	مدیرِ پادها. شما به دیپلویمنت می‌گویید «۳ نسخه از برنامه من را همیشه زنده نگه دار» و او اگر پادی ازبین برود جایگزینش می‌کند.
Ingress	مدیریت ترافیک (مثل HTTP/HTTPS) که از اینترنت به داخل کلاستر می‌آید (معمولاً با ابزاری مثل Nginx).
ConfigMap	جدا کردن تنظیمات برنامه (مثل متغیرهای محیطی) از کد اصلی تا برای تغییر کانفیگ نیاز به بیلد مجدد برنامه نباشد.
Secret	شبیه ConfigMap است اما برای ذخیره اطلاعات حساس مثل پسورد دیتابیس یا کلیدهای SSH استفاده می‌شود.
Volume	چون پادها موقتی هستند، اگر اطلاعاتی دارید که باید دائمی بماند، باید آن را روی Volume ذخیره کنید.
StatefulSet	برخلاف Deployment که پادها را بی‌نام و نشان می‌داند، این ابزار هویت و ترتیب پادها را حفظ می‌کند (مناسب برای دیتابیس‌ها).

برای مطالعه عمیق‌تر درباره هر یک از این مفاهیم، می‌توانید به دایره‌المعارف رسمی IBM Kubernetes Topics مراجعه کنید.

 تفاوت کوبرنتیز و داکر

ویژگی	داکر (Docker)	کوبرنتیز (Kubernetes)
وظیفه اصلی	ساخت و اجرای کانتینر (Container Engine)	مدیریت و هماهنگی کانتینرها (Orchestrator)
دامنه فعالیت	روی یک نود (تک سرور) عالی کار می‌کند.	روی مجموعه‌ای از سرورها (کلاستر) کار می‌کند.
مدیریت خرابی	اگر کانتینر خراب شود، باید دستی یا با اسکریپت ساده ریستارت شود.	اگر کانتینر خراب شود، خودکار ترمیم و جایگزین می‌شود (Self-healing).
نصب و راه‌اندازی	بسیار ساده و سریع	پیچیده و نیازمند دانش فنی (البته ارزشش را دارد).

یکی از رایج‌ترین سؤالاتی که کاربران هنگام تحقیق درباره اینکه کوبرنتیز چیست می‌پرسند، این است: «آیا باید از داکر استفاده کنم یا کوبرنتیز؟» پاسخ کوتاه و قاطع این است: این سوال غلط است! شما معمولاً باید از هر دو استفاده کنید.

برای درک عمیق تفاوت Kubernetes و Docker، باید بدانیم که این دو ابزار در لایه‌های متفاوتی کار می‌کنند و مکمل یکدیگرند:

• داکر (Docker): ابزاری است که به شما کمک می‌کند برنامه‌تان را بسته‌بندی (Containerize) کنید. یعنی کدها و وابستگی‌ها را داخل یک کانتینر می‌گذارید تا همه‌جا اجرا شود. داکر مسئول ساختن و اجرا کردن یک کانتینر واحد است.

مقاله مرتبط: داکر (Docker) چیست؟

• کوبرنتیز (Kubernetes): کاری به ساخت کانتینر ندارد؛ بلکه وظیفه دارد این کانتینرها را کنار هم بچیند تا یک اپلیکیشن کامل بسازد.

به‌طورخلاصه در یک سناریوی واقعی، شما ابتدا برنامه خود را با داکر بسته‌بندی می‌کنید (ایمیج می‌سازید) و سپس از کوبرنتیز استفاده می‌کنید تا آن ایمیج‌ها را روی صدها سرور مدیریت، به‌روزرسانی و مقیاس‌دهی کنید.

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

تا اینجا یاد گرفتیم که کوبرنتیز چیست و چگونه مثل یک مغز متفکر، کانتینرها را مدیریت می‌کند. اما فراموش نکنید که هر مغزی برای فعالیت به یک جسم سالم نیاز دارد. در معماری کوبرنتیز، این جسم همان نودها (Nodes) هستند.

کوبرنتیز نرم‌افزار قدرتمندی است، اما روی هوا اجرا نمی‌شود! پادهای شما نیاز به رم، پردازنده و فضای ذخیره‌سازی دارند که باید توسط سرورها تأمین شود.

چالش اصلی بسیاری از متخصصان دواپس (DevOps) دقیقاً همین‌جاست:

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

چرا سرور ابری بهترین زیرساخت کوبرنتیز است؟

برای همین است که امروزه از سرور ابری یا Cloud Server به‌عنوان منطقی‌ترین زیرساخت برای راه‌اندازی کلاستر مطرح می‌شود.

مزایای استفاده از سرور ابری فردوسی:

• هر زمان که کوبرنتیز نیاز به نود جدید داشته باشد، می‌توانید در چند ثانیه یک سرور ابری جدید به کلاستر اضافه کنید (Scale-out).
• سرورهای ابری فردوسی وابستگی مستقیم به سخت‌افزار ندارند و درصورت خرابی سخت‌افزار به‌سرعت روی سخت‌افزار دیگری بالا می‌آیند.
• هزینه سرور به‌صورت پرداخت به‌ازای مصرف محاسبه می‌شود و می‌توانید با خاموش کردن سرور هزینه‌های خود را مدیریت کنید.

پیشنهاد ویژه برای تست کلاستر:

اگر قصد دارید دانش خود را عملی کنید یا یک محیط آزمایشگاهی (Staging) برای کلاستر کوبرنتیز خود بسازید، ما در ابر فردوسی کنارتان هستیم. شما می‌توانید همین حالا با استفاده از ۱۰۰ هزار تومان اعتبار اولیه (رایگان)، چند سرور ابری بسازید، کلاستر خود را کانفیگ کنید و قدرت سرورهای ما را بدون ریسک مالی تجربه کنید.

جمع‌بندی

ما از مقاله کوبرنتیز چیست نتیجه می‌گیریم که کوبرنتیز فقط یک ابزار جدید نیست که بخواهید به رزومه خود اضافه کنید؛ K8s یک تغییر نگرش در مدیریت نرم‌افزار است. ما از دورانی که تیم عملیات شب‌ها بیدار می‌ماند تا سرورهای خراب را ریستارت کند عبور کرده‌ایم. امروز شما با کوبرنتیز یک سیستم خودگردان می‌سازید که قوانینش را خودتان نوشته‌اید، اما اجرایش را به ماشین سپرده‌اید.

یادگیری کوبرنتیز شاید در ابتدا شبیه یادگیری خلبانی سخت به‌نظر برسد، اما وقتی اولین کلاستر خود را مدیریت کنید و ببینید که چطور زیر بار ترافیک سنگین، خم به ابرو نمی‌آورد، متوجه می‌شوید که ارزشش را داشته است.

نوبت شماست: آیا تا‌به‌حال تجربه تلخی از مدیریت دستی کانتینرها و کرش کردن (Crash) سرویس‌ها داشته‌اید؟ یا شاید در ابتدای مسیر یادگیری هستید و سوالی ذهن‌تان را درگیر کرده؟ در بخش نظرات برای ما بنویسید تا با هم به آن پاسخ دهیم.

منابع:
Kubernetes | redhat | criticalcase | ibm | aws.amazon

سؤالات متداول