برای شروع و پیش از ورود به جزئیات فنی باید درک کلی از این ابزار و اجزای مختلفش  داشته باشیم. در ادامه سعی می‌کنیم مروری کلی بر این ابزار داشته باشیم.

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

احتمالاً وقتی شما هم برای اولین بار به واژه کوبرنتیز برخوردید کمی این واژه برای‌تان عجیب بود. یکی از روش‌های معمول در نام‌گذاری‌های علمی و فنی استفاده از مفاهیمی است که ریشه‌های یونانی دارد. 

کوبرنتیز هم از واژه یونانی κυβερνήτης گرفته شده است و به معنای سکان‌دار یا ناخدای کشتی است.  حتماً شما هم موافقید که این واژه برای نامیدن  ابزاری که قرار است هر روز درباره‌اش حرف بزنید و یا راجع به آن بنویسید واژه‌ای طولانی است. به همین‌خاطر  بسیاری آن را به صورت K8s می‌نویسند. K حرف اول کوبرنتیز و s حرف آخر آن است و 8 نشان دهنده تعداد حروف بین K و s.

 البته این نام‌گذاری چندان هم بی‌ربط نیست و اشاره‌ای به کارکرد کوبرنتیز دارد؛ کار کوبرنتیز مدیریت و راهبری کانتینرهاست و تصویر سکانی که در لوگوی کوبرنتیز استفاده شده دقیقاً بیانگر همین ویژگی کوبرنتیز است. کوبرنتیز مدیریت کانتینرها را به شیوه‌ای خودکار انجام می‌دهد. با استفاده از کوبرنتیز دیگر نیازی به مدیریت کانتینرها به‌صورت دستی نیست.

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

استفاده از سرور‌های فیزیکال و مشکلات آن

جمله‌ معروفی وجود دارد که می‌گوید: «در آغاز کلمه بود». اگر بخواهیم تاریخ رسیدن به استفاده از کوبرنتیز را از همان اول بررسی کنیم باید بگوییم: «در آغاز فلز بود»؛ منظورمان همان سرورهای فیزیکی است.

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

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

 مشکلی که این روش داشت این بود که هر چقدر که تعداد اپلیکیشن‌ها بیشتر می‌شد مجبور بودیم سرورهای بیشتری داشته باشیم و این به‌معنای صرف هزینه بیشتر بود.

استفاده از ماشین مجازی

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

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

عصر اپلیکیشن‌های کانتینری‌شده

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

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

در کانتینرها از ویژگی‌های لینوکسی مانند namespaceها و cgroupها برای ایجاد سطح مشخصی از جداسازی در ذخیره‌سازی، منابع محاسباتی و شبکه استفاده می‌شود.

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

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

کوبرنتنیز؛ راه‌حلی برای مدیریت اپلیکیشن‌های کانتینری

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

در معماری میکروسریس که امروزه رایج‌ترین معماری در توسعه و استقرار اپلیکیشن‌هاست ما با تعداد زیادی اپلیکشن کانیتنری‌شده مواجه هستیم. این کانتینرها را چطور می‌شود مدیریت کرد؟

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

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

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

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

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

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

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

برای اینکه بدانیم کوبرنتیز چگونه می‌تواند کار ارکستریشن کانتینرها را انجام دهد، خوب است درکی کلی از معماری کوبرنتیز داشته باشیم. کلاستر کوبرنتیز لااقل از یک node مستر ( یا control plane) و تعدادی node ورکر (Worker node) ساخته شده است. بر روی هر کدام از این nodeها تعدادی پردازش در حال انجام است.

بر روی هر کدام از nodeهای ورکر کانتینرهایی وجود دارد که بر روی هر کدام اپلکیشنی قرار دارد. کار اصلی در کوبرنتیز در node ورکر انجام می‌شود و اپلیکیشن‌های شما در آنجا اجرا می‌شود.

Control plane

سوالی که اینجا پیش می‌آید این است که اگر کانتینرهای ما بر روی worker nodeها قرار دارند، پس control plane چه کاری انجام می‌دهد؟به‌طورکلی، control plane تعدادی از پردازش‌های کوبرنتیزی را که برای اجرا و مدیریت کلاسترها لازم است انجام می‌دهد.

node

کوبرنتیز ابزاری است که مفاهیم خاص خود را دارد.  Node یکی از مفاهیمی است که در ادبیات مربوط به کوبرنتیز زیاد استفاده می شود. در نگاه اول شاید مفهوم node برای شما مبهم باشد. اما نگران نباشید. برای درک مفهوم node کافی است به این فکر کنید که ما کلاستر کوبرنتیز را در خلاء نمی‌سازیم. بالاخره به یک سرور فیزیکی یا ماشین مجازی نیاز داریم تا کلاستر خود را روی آن بسازیم. Nodeها همین ماشین‌های فیزیکال یا مجازی هستند. بنابراین node را با کوبرنتیز نمی‌سازیم بلکه کوبرنتیز و کانتینرها را روی این نودها بالا می‌آوریم.

معمولاً  در هر کلاستر چند node داریم؛ اما ممکن است در آموزش کوبرنتیز یا وقتی با کمبود منابع مواجه هستیم صرفاً از یک node استفاده شود.

گفتیم که nodeها با استفاده از کوبرنتیز ساخته نمی‌شوند. پس چطور node می‌سازیم؟ nodeها را می‌توان به‌صورت دستی ساخت یا از سرویس‌های ابر عمومی استفاده کرد. 

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

API Server

یکی از این پردازش‌ها API Server است. ای‌پی‌آی سرور مدخل و دروازه ورود به کلاستر کوبرنتیز است. کلاینت‌های مختلف کوبرنتیز مثل UI دشبورد، api و ابزار کامندلاینی با API Server ارتباط برقرار می‌کنند.

controller manager

پردازش دیگری که بر روی control plane انجام می‌شود controller manager است. این پردازش کلیت و مختصری از اتفاقاتی را که بر روی کلاستر می‌افتد در خود نگه می‌دارد؛ مثلا اگر چیزی به تعمیر و ترمیم نیاز داشته باشد یا اگر کانتینری از بین رفته باشد و نیاز به شروع مجدد داشته باشد از طریق همین پردازش رصد می‌شود.

scheduler

Scheduler یکی دیگر از پردازش‌های مهمی است که بر روی نود مستر(control plane) انجام می‌شود.

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

در واقع scheduler فرایندی هوشمند است که تصمیم می‌گیرد بر اساس منابع آزادی که هر کدام از worker nodeها دارند کانتینر بعدی باید روی کدام یکی از آن‌ها بنشیند.

etcd

کار etcd ذخیره‌ وضعیت کلاستر در هر لحظه است. به خاطر همین، تمام داده‌های مربوط به پیکربندی کلاستر در etcd قرار دارد. همچنین etcd تمام اطلاعات مربوط به هر node و کانتینرهای درون آن را نیز در خود ذخیره می‌کند.

آبجکت‌های کوبرنتیز

یکی از راه‌های آشنایی با کوبرنتیز شناخت مفاهیم و ابزارهای مربوط به آن است:

پاد

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

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

مثلاً در تصویر زیر، سمت چپ، ما یک node داریم با دو پاد؛ پاد اپ و پاد دیتابیس. این پادها می‌توانند از طریق IP با هم ارتباط بگیرند.

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

سرویس

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

 سرویس‌ها به دو دسته تقسیم می‌شوند: سرویس‌ داخلی و سرویس خارجی. 

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

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

ingress

راه‌های مختلفی برای نمایش دادن و دسترسی داشتن به یک کلاستر از بیرون آن وجود دارد. شما باید بر اساس کاری که می‌کنید و بسته به نیازتان یکی از این روش‌ها را انتخاب کنید. Ingress هم یکی از همین روش‌های دسترسی و نمایش دادن جزئیات کلاستر است. اینگرس API آبجکتی است که دسترسی به سرویس‌های درون یک کلاستر را از بیرون، معمولاً با استفاده از HTTP، فراهم می‌کند. شما می‌توانید قواعدی برای هر دسترسی از طریق ingress  تعریف بکنید. 

configmap

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

با استفاده از configmap شما کد اپلیکیشنتان را از فایل پیکربندی جدا می‌کنید. 

secret

هر پاد اطلاعات محرمانه خاص خود را دارد. سوالی که پیش می‌آید این است که این اطلاعات چطور ذخیره می‌شود و چطور می‌شد آن‌ها را تغییر داد؟ این اطلاعات در کانفیگ مپ نیست. در کوبرنتیز بخش دیگری به نام secret برای این مدل اطلاعات داریم.

volume

مسئله مهم دیگر در کوبرنتیز به نحوه ذخیره‌سازی داده برمی‌گردد. 

همانطور که گفتیم پادها خیلی سریع از بین می‌روند. اگر پاد از بین برود اطلاعاتش نیز از بین می‌رود. این مسئله باعث ناکارآمدی ابزار می‌شود. راه‌حل کوبرنتیز استفاده از volume است. volume، اطلاعات پاد را ذخیره می‌کند. volume هم می‌تواند داخل کلاستر کوبرنتیز باشد هم بیرون از آن.

deployment

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

در واقع کار deployment این است که به کوبرنتیز می‌گوید چطور instanceهای از  اپ‌های کانتینری‌شده بسازد. 

kubectl چیست؟

تصور کنید که ما با استفاده از مینی‌کیوب یه کلاستر ساخته‌ایم. حالا چطور می‌توان با این کلاستر تعامل کرد؟

اینجا از kubectl استفاده می‌کنیم. Kubectl یک ابزار کامندلاینی برای تعامل با کلاستر کوبرنتیز است.

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

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

پس کی از کوبرنتیز استفاده می‌کنیم؟ بیایید با همین مثال شرکت جلو برویم. اگر شما یک شرکت داشته باشید که تیم‌های مختلفی از فروش، مارکتینگ تا فنی و منابع انسانی داشته باشید اینجا شما نیاز به استخدام و مدیریت کارمندان دارید.

کوبرنتیز هم قابلیت‌هایش را زمانی نشان می‌دهد که شما تعداد زیادی اپ کانتینری شده داشته باشید و مسئله مدیریت این اپ‌ها برایتان مهم می‌شود. کار کوبرنتیز مدیریت اپلیکیشن‌ها و تسهیل توسعه‌پذیری و استقرار کانتینرها به تعداد زیاد است.

لود بالانسینگ

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

هماهنگ‌سازی ذخیره‌سازی

کوبرنتیز به شما کمک می‌کند تا برخی از کارهای مربوط به ذخیره‌سازی را از طریق دیسک‌ها مدیریت کنید.

Rollout و rollback خودکار

کوبرنتیز بسیاری از فرایندهای دستی سنتی در فرایند استقرار و مقیاس پذیری اپلیکیشن های کانتینری را از بین می‌برد و فرایندها را استاندارد می‌کند.

خودترمیمی

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

قابلیت‌های مانیتورینگ

در فرایند مانیتورینگ، عمدتا یکسری متریک‌ها و لاگ‌ها از بخش‌های مختلف کلاستر کوبرنتیز جمع‌آوری می‌شود.  Nodeها، Podها و سرویس‌های اجرایی از جمله این بخش‌ها هستند.

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

دسترسی بالا یا بدون downtime

با استفاده از کوبرنتیز اپلیکیشن شما همیشه در دسترس کاربران‌تان خواهد بود.

مقیاس‌پذیری

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

disaster recovery

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

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

• نت‌فلیکس
• اسپاتیفای
• IBM
• OpenAI
• Google

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

• یکتانت
• ترب
• گروه اسنپ
• دیجی‌کالا

پلتفرم ابری دارکوب؛ تجربه زیرساختی پایدار و مطمئن

ایجاد و مدیریت زیرساخت همواره یکی از مشکلات همیشگی کسب‌وکارها و استارتاپ‌های مختلف بوده است. معمولاً مدیریت زیرساخت‌ها نیاز به تیمی متخصص دارد که به‌صورت شبانه‌روزی بر روی نگه‌داری و توسعه زیرساخت وقت بگذارند. این امکان برای بسیاری از شرکت‌ها وجود ندارد.

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

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

The post کوبرنتیز چیست؟ راهنمای کوبرنتیز به زبان ساده appeared first on بلاگ هم‌روش.