چرا کوبرنتیز این شکلی طراحی شده؟ - قسمت چهارم و آخر

مقدمه

این مطلب قسمت چهارم و آخر از سری نوشته‌های اصول طراحی کوبرنتیز هست. در سه قسمت قبلی سه اصل رو گفتیم و در مورد هر کدوم توضیحاتی داده شد. الان می‌خوایم اصل چهارم رو بررسی کنیم که ایجاد abstraction از زیرساخت هست. کوبرنتیز با داشتن این ویژگی مثل یک سیستم عامل اون چیزی که در زیرساخت هست رو از اپلیکیشن پنهان می‌کنه و باعث میشه بتونیم به راحتی بین زیرساخت‌های مختلف جابجا بشیم. این مطالب از یک ارائه در kubecon 2018 گرفته شدن.

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

معرفی volume و persistent volume در کوبرنتیز

قبل از رسیدن به بحث اصلی در مورد ذخیره‌سازی داده در کوبرنتیز صحبت می‌کنم. چون بهمون در درک مطلب کمک می‌کنه. راهی که ما در کوبرنتیز برای ذخیره کردن داده داریم استفاده از volume هست؛ مثل داکر که مفهوم volume رو داره و میشه اون رو داخل کانتینر mount کرد. اما در کوبرنتیز بسیار بیشتر به بحث ذخیره‌سازی پرداخته شده و انواع و اقسام گزینه‌ها برای این کار فراهم هست. بیاید یک نمونه پاد که از volume استفاده می‌کنه رو ببینیم:

به دو قسمت توجه کنید؛ اول به volumes که در spec پاد نوشته میشه و بعد به volumeMounts که در داخل تعریف هر کانتینر میاد. با استفاده از volume میشه نوع اون رو مشخص کرد و در volumeMounts در تعریف کانتینر میشه volumeهای تعریف شده رو mount کرد. برای دیدن انواع volumeها به این لینک مراجعه کنید. با دیدن انواع volumeها ممکنه این طور به نظر بیاد که برای هر زیرساختی لازمه که تعریف volumeها رو تغییر بدیم؛ اما یک نوع volume بسیار مهم در کوبرنتیز وجود داره که در ایجاد abstraction به ما کمک می‌کنه و اون persistent volume هست.

برای آشنایی با persistent volume در کوبرنتیز بیاید یک پاد رو با این نوع volume ببینیم:

دقت کنید فقط تعریف volume عوض شده و از PersistentVolumeClaim استفاده شده که یک آبجکت در کوبرنتیز هست و نقش اصلی رو در ایجاد abstraction بازی می‌کنه. برای این که PersistentVolumeClaim رو در تعریف volume بیاریم باید قبلش این شکلی یه آبجکت ازش بسازیم:

اینجا حجم دیسک درخواستی ۲ گیگ هست. توجه کنید که این آبجکت فقط یک درخواست برای منابع ذخیره‌سازی هست و باید یک PersistentVolume هم باشه که به این آبجکت bind بشه. بعد از ساختن این آبجکت با این دستور:

kubectl apply -f pvc.yaml

دو حالت داریم. یا باید یک آبجکت PersistentVolume رو ادمین کلاستر برامون بسازه که مشخصات claim رو برآورده کنه یا باید StorageClass داشته باشیم که به شکل اتوماتیک برای claim یک PersistentVolume بسازه. به طور خلاصه میشه ارتباط پاد با PersistentVolume و PersistentVolumeClaim رو در این عکس نشون داد:

ما یک پاد می‌سازیم و یک PVC که به یک PV وصل یا bind میشه. خود PV می‌تونه به شکل dynamic یا static ساخته بشه. راجع به اون تقسیم‌بندی user space و kernel space در عکس در قسمت بعد توضیح میدم.

اصل چهارم: ایجاد abstraction از زیرساخت

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

در مورد کوبرنتیز میشه به PVC و PV اشاره کرد. ما (به عنوان کاربر معمولی کلاستر) موقعی که پاد رو تعریف می‌کنیم تنها اسم PVC رو میاریم و پاد رو با اون تعریف می‌کنیم؛ به همین دلیل این دو تا آبجکت رو در شکل قبلی در user space آوردم. موقع تعریف PVC هم مقدار و نوع storage درخواستی رو می‌نویسیم. از اینجا به بعد دیگه دست ادمین کلاستر هست که یا به شکل static (دستی) یا dynamic (اتوماتیک) برای ما PV رو ایجاد کنه. در شکل قبلی هم اگر نگاه کنید می‌بینید ساخت PV در kernel space گذاشته شده که نشون میده اگه کلاستر کوبرنتیز رو سیستم عامل در نظر بگیریم، ساخت PV رو کرنل (ادمین کلاستر) باید انجام بده. با این ویژگی کاربران به راحتی می‌تونن workloadهای خودشون رو بین زیرساخت‌های مختلف انتقال بدن و دغدغه‌ای برای این جابجایی نداشته باشن.

جمع‌بندی

در این قسمت اصل چهارم طراحی کوبرنتیز رو معرفی کردیم. به کمک کوبرنتیز ما می‌تونیم workloadهای خودمون رو به زیرساخت‌های مختلف ببریم و این موضوع اصل چهارم است. در مورد PVC و PV هم صحبت کردیم که به ما امکان ایجاد این abstraction از زیرساخت رو میدن.

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

قسمت قبلی