کوبرنتیز چیست؟ هرآنچه باید درباره Kubernetes بدانید

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

کوبرنتیز چیست؟ تعریف کوبرنتیز به زبان ساده

کوبرنتیز (Kubernetes) که با نام‌های kube و k8s نیز شناخته می‌شود، یک پلتفرم هماهنگ‌سازی کانتینر است که فرایند زمان‌بندی (scheduling)، خودکارسازی استقرار (automating the deployment)، مدیریت (management) و مقیاس‌گذاری اپلیکیشن‌های کانتینری (scaling of containerized applications) را تسهیل می‌کند. کوبرنتیز برای اولین بار توسط مهندسان گوگل در سال 2014 توسعه پیدا کرد. این پلتفرم کانتینری در واقع از Borg، یک پلتفرم هماهنگ‌سازی کانتینر که فقط داخل گوگل استفاده می‌شد، گرفته شده است. Kubernetes یک کلمه یونانی به‌معنای سکان‌دار یا خلبان است؛ به همین خاطر لوگوی این پلتفرم با الهام از یک سکان طراحی شده است.

در حال حاضر، کوبرنتیز و اکوسیستم وسیع‌تر کانتینر، در حال تبدیل شدن به یک پلتفرم محاسباتی همه‌منظوره و اکوسیستمی است که با ماشین‌های مجازی (VMs) به‌عنوان بلاک‌های اساسی زیرساخت ابری مدرن رقابت می‌کند. این اکوسیستم سازمان‌ها را قادر می‌سازد تا یک PaaS (پلتفرم به‌عنوان یک سرویس) با بهره‌وری بالا ارائه دهند که به وظایف عملیات‌محور و زیرساخت‌محور و همچنین مسائل پیرامون توسعه ابر بومی (cloud-native) می‌پردازد تا تیم‌های توسعه بتوانند فقط روی کدنویسی و نوآوری تمرکز کنند.

برای آشنایی بیشتر با مباحث زیرساخت ابری توصیه می‌کنیم قبل از خواندن ادامه مطلب حتما مقاله پردازش ابری را با دقت بخوانید.

کانتینر (Container) چیست و چه کاربردهایی دارد؟

کانتینرها اجزای قابل اجرا و سبک اپلیکیشن هستند که کد منبع (source code) اپلیکیشن را با همه کتابخانه‌های سیستم‌عامل و وابستگی‌های مورد نیاز برای اجرای کد در هر محیطی ترکیب می‌کنند. کانتینرها از نوعی مجازی‌ساز سیستم‌عامل بهره می‌برند که به چندین اپلیکیشن اجازه می‌دهند تا نمونه واحدی از یک سیستم‌عامل را با جداسازی فرایندها و کنترل میزان CPU، مموری و حافظه‌ای که این فرایندها می‌توانند به آن دسترسی داشته باشند، به اشتراک بگذارند؛ زیرا کانتینرها نسبت به ماشین‌های مجازی کوچک‌تر، قابل حمل‌ترند و کارآمدی منابعشان بیشتر است. به‌علاوه، کانتینرها به واحدهای محاسباتی اپلیکیشن‌های مدرن ابر بومی تبدیل شده‌اند.

تفاوت کانتینرها، ماشین‌های مجازی و زیرساخت سنتی با یکدیگر

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

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

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

کانتینرها از نظر منابع کارآمدتر هستند؛ یعنی امکان اجرای برنامه‌های بیشتری روی ماشین‌های کمتری (مجازی و فیزیکی) با نمونه‌های سیستم‌عامل کمتر به شما می‌دهند. کانتینرها قابلیت حمل راحت‌تری در دسکتاپ، دیتاسنتر و محیط‌های ابری دارند؛ ازهمین رو برای روش‌های توسعه DevOps و Agile بسیار مناسب هستند.

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

داکر محبوب‌ترین ابزار برای ایجاد و اجرای کانتینرهای لینوکس است که برای ساخت، استقرار و مدیریت نرم‌افزارهای کانتینرشده استفاده می‌شود. داکر ابتدا به‌عنوان یک پروژه منبع‌باز (open source) شروع به کار کرد، اما امروزه Docker به‌عنوان کمپانی تولیدکننده این پروژه نیز شناخته می‌شود.

داکر بر اساس تکنولوژی سنتی کانتینر لینوکس (LXC) راه‌اندازی شده است، اما مجازی‌سازی فرایندهای هسته لینوکس را امکان‌پذیر می‌سازد و ویژگی‌هایی برای آسان‌تر کردن ساخت، استقرار، مدیریت و امنیت کانتینرها اضافه می‌کند.

هرچند امروزه پلتفرم‌های کانتینری جایگزین مانند Open Container Initiative، CoreOS و Canonical (Ubuntu) LXD وجود دارند، اما داکر از محبوبیت بیشتری برخوردار است و گاهی اوقات ممکن است به‌عنوان رقیب فناوری‌های مکمل مانند کوبرنیتیز اشتباه گرفته شود.

در مقاله «داکر چیست» به‌طور کامل این ابزار محبوب را معرفی کرده‌ایم. اگر می‌خواهید درباره داکر بیشتر بدانید، این مقاله را مطالعه کنید.

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

تا این قسمت از مقاله متوجه شدیم که کوبرنتیز جایگزین یا رقیبی برای داکر نیست؛ بااین‌حال می‌توان آن را جایگزینی برای Docker Swarm دانست. Docker Swarm یک پلتفرم هماهنگ‌سازی کانتینر منبع‌باز است که یک پشتیبانی بومی داکر برای سازماندهی به خوشه‌های (cluster) موتورهای داکر محسوب می‌شود.

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

درحالی‌که سایر گزینه‌های هماهنگ‌سازی کانتینرها مخصوصا Docker Swarm و Apache Mesos اوایل مورد توجه قرار گرفته بودند، کوبرنتیز به‌سرعت به محبوب‌ترین پروژه تبدیل شد. به عبارت دیگر، در یک مقطع زمانی، کوبرنتیز به‌عنوان سریع‌ترین پروژه در حال رشد در تاریخ نرم‌افزار منبع باز (open source) شناخته می‌شد.

توسعه‌دهندگان به‌دلیل گستردگی عملکرد، اکوسیستم وسیع و در حال رشد ابزارهای پشتیبانی منبع باز، پشتیبانی و قابلیت حمل در میان ارائه‌دهندگان سرویس ابری، کوبرنتیز را انتخاب کرده‌اند. همه ارائه‌دهندگان ابر عمومی مطرح در جهان از جمله Amazon Web Service، Google Cloud & IBM Cloud و Microsoft Azure سرویس‌های کاملا مدیریت‌شده کوبرنتیز ارائه می‌دهند.

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

کوبرنتیز وظایف مربوط به کانتینر را در طول چرخه عمر اپلیکیشن زمان‌بندی و اتوماتیک می‌کند. از جمله این وظایف می‌توانیم به موارد زیر اشاره کنیم:

• Deployment: تعداد مشخصی از کانتینرها را در یک هاست مشخص مستقر کرده و آن‌ها را در حالت مورد نظر در حال اجرا نگه می‌دارد.
• Rollouts: یک rollout تغییری در استقرار است. کوبرنتیز به شما امکان می‌دهد که rolloutها را آغاز، متوقف، ازسرگیری یا بازگردانی کنید.
• Service discovery: کوبرنتیز می‌تواند به‌طور خودکار یک کانتینر را با استفاده از نام DNS یا آدرس IP در اینترنت یا سایر کانتینرها به نمایش بگذارد.
• Storage provisioning: کوبرنتیز را می‌توان به‌صورتی تنظیم کرد تا در صورت نیاز فضای ذخیره‌سازی ابری یا محلی دائمی را برای کانتینرهای شما نصب کند.
• Load balancing: بر اساس استفاده از CPU یا معیارهای سفارشی، تعادل بار کوبرنتیز می‌تواند برای حفظ عملکرد و ثبات، حجم کاری را در سراسر شبکه توزیع کند.
• Autoscaling: درصورت افزایش ترافیک، مقیاس‌بندی خودکار کوبرنتیز در صورت نیاز خوشه‌های (clusters) جدیدی را برای کنترل بار کاری اضافی ایجاد می‌کند.
• Self-healing for high availability: هنگام خرابی کانتینر، کوبرنتیز می‌تواند برای جلوگیری از خارج شدن از دسترس (downtime) به‌صورت خودکار آن را دوباره راه‌اندازی یا جایگزین کند. این ویژگی همچنین می‌تواند کانتینرهایی را که از الزامات بررسی سلامت برخوردار نیستند، حذف کند.

آشنایی با معماری و اجزای کوبرنتیز

اصلی‌ترین اجزای کوبرنتیز شامل موارد زیر می‌شود:

نود (Node) و کلاستر (Cluster)

خوشه‌ها (cluster) بلاک‌های سازنده معماری کوبرنتیز هستند. کلاسترها از چندین گره (node) تشکیل شده‌اند که هرکدام از آن‌ها نشان‌دهنده یک هاست محاسباتی واحد (ماشین مجازی یا فیزیکی) است. هر کلاستر از یک گره اصلی و چندین گره کارگر تشکیل شده است.

گره اصلی به‌عنوان برنامه کنترلی (Control plan) برای کلاستر استفاده می‌شود. این گره به‌عنوان یک سرویس زمان‌بند (Scheduler) زمان و مکان کانتینرهایی را که بر اساس الزامات استقراری که توسعه‌دهندگان تنظیم کرده‌اند (developer-set deployment) و میزان حجم محاسباتی در دسترس مستقر شده‌اند، خودکار می‌کند. 

گره‌های کارگر اپلیکیشن‌های کانتینری را مستقر، اجرا و مدیریت می‌کنند. هر گره کارگر شامل دو جزء زیر است:

• ابزارهایی که برای مدیریت کانتینرها استفاده می‌شوند؛‌ مانند داکر.
• یک عامل (agent) نرم‌افزاری به نام Kubelet که دستورها را از گره اصلی دریافت و اجرا می‌کند.

توسعه‌دهندگان با استفاده از kubectl عملیات‌های خوشه را مدیریت می‌کنند؛ Kubectl یک رابط خط فرمان (cli) است که به‌طور مستقیم با API کوبرنتیز ارتباط دارد.

پادها (Pods) و استقرارها (Deployments)

پادها (Pods) گروه‌هایی از کانتینرها هستند که منابع محاسباتی و شبکه یکسانی به اشتراک می‌گذارند. آن‌ها همچنین واحد مقیاس‌پذیری در کوبرنتیز هستند: اگر یک کانتینر در یک پاد ترافیکی بیشتر از توانش دریافت کند، کوبرنتیز پاد را در سایر گره‌ها در کلاستر تکرار خواهد کرد. به همین دلیل، روش خوبی برای فشرده نگه داشتن پادها است تا فقط کانتینرهایی را که باید منابع را به اشتراک بگذارند، در بر بگیرد.

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

محاسبات بدون سرور (Serverless) و Knative

Knative که به‌صورت kay-native تلفظ می‌شود، یک پلتفرم منبع‌باز است که بالای کوبرنتیز قرار دارد و برای توسعه ابر بومی (cloud-native) دو مزیت بسیار مهم به ارمغان می‌آورد:

1. Knative یک onramp آسان برای محاسبات بدون سرور ارائه می‌دهد

محاسبات بدون سرور (Serverless computing) یک روش نسبتا جدید برای استقرار کد است که اپلیکیشن‌های ابر بومی (cloud native) را کارآمدتر و مقرون‌به‌صرفه‌تر می‌کند. بدون سرور (Serverless) از هدر رفتن ظرفیت و توان محاسباتی جلوگیری می‌کند و هزینه‌ها را کاهش می‌دهد؛ زیرا فقط زمانی که کد واقعا اجرا می‌شود، هزینه را پرداخت می‌کنید.

Knative این امکان را به توسعه‌دهندگان می‌دهد که یک بار یک کانتینر بسازند و آن را به‌عنوان یک سرویس نرم‌افزاری یا تابع بدون سرور اجرا کنند. همه چیز برای توسعه‌دهنده شفاف است؛ Knative جزئیات را در پس‌زمینه مدیریت می‌کند و توسعه‌دهنده می‌تواند روی کد متمرکز شود.

2. Knative توسعه کانتینر و هماهنگ‌سازی را آسان می‌کند

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

Knative انجام این وظایف را با خودکارسازی آن‌ها از طریق سه مولفه زیر آسان‌تر می‌کند:

• Build: مولفه Knative’s Build به‌طور خودکار کد منبع (source code) را به یک کانتینر یا تابع (function) ابر بومی تبدیل می‌کند. به‌طور خاص، این مولفه کد را از مخزن (repository) پول (pull) می‌کند، وابستگی‌های مورد نیاز را نصب می‌کند، image کانتینر را می‌سازد و آن را در یک رجیستری کانتینر برای استفاده سایر توسعه‌دهندگان قرار می‌دهد. توسعه‌دهندگان باید لوکیشن این اجزا را مشخص کنند تا Knative بتواند آن‌ها را پیدا کند؛ اما بعد از انجام این کار، Knative ساخت (build) را خودکار می‌کند.
• Serve: مولفه Serve کانتینرها را به‌عنوان سرویس‌های مقیاس‌پذیر اجرا می‌کند. این مولفه می‌تواند هزاران نمونه کانتینر را افزایش دهد یا آن‌ها را به صفر برساند که به آن مقیاس‌پذیری تا صفر می‌گویند. علاوه‌بر این، Serve دو ویژگی بسیار مفید دارد؛ پیکربندی و مسیریابی سرویس. با کمک ویژگی پیکربندی هر بار که کانتینر را به سمت تولید پوش (push) می‌کنید، نسخه‌های کانتینر را ذخیره می‌کند و به شما اجازه می‌دهد تا آن نسخه‌ها را هم‌زمان اجرا کنید. 

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

• Event: مولفه Event رویدادهای مشخص را برای راه‌اندازی سرویس‌ها یا عملکردهای مبتنی بر کانتینر راه‌اندازی می‌کند که در قابلیت‌های Knative’s serverless ضروری است. Event این امکان را برای تیم‌ها فراهم می‌کند تا در صورت نیاز به‌طور خودکار به تولیدکننده رویداد مورد نظرشان متصل شوند و رویدادها را به سمت کانتینر هدایت کنند. به‌این‌ترتیب نیاز به برنامه‌ریزی برای چنین اتصالاتی از بین می‌رود.

منبع: IBM