storage در کوبرنتیز

در محیط‌های عملیاتی کلاستر کوبرنتیز قطعا باید از remote storage‌هایی با backend قوی همانند Ceph استفاده کرد

بحث storage در کوبرنتیز دارای گستردگی‌های زیادی است. برای ارائه مطالب در این حوزه در ابتدا دو مفهوم در storage را مورد بررسی قرار می‌دهیم.

Ephemeral storage

دیتا‌های مربوط به کانتینر‌ها است، که این دیتا‌ها به محض stop و یا restart شدن pod‌ها به صورت کامل از بین خواهند رفت.

persistent volume

دیتای‌های مهم مربوط به کانتینر‌ها را می‌توان در PV‌ها یا همان persistent volume‌ها ذخیره سازی کرد. درصورت پاک شدن و یا stop شدن Pod‌ها به هر دلیل data‌های موجود در PV‌ها حدف نخواهد شد. PV‌ها در ساختار yml تعریف می‌شوند که در ادامه به آنها خواهیم پرداخت. PV‌ها در حقیقت ماهیت کوبرنتیزی دارند وbackend یک PV هر نوع storage می‌تواند باشد، می‌تواند NFS و یا cluster و… باشد. persistent volume‌ها به صورت cluster wide است یعنی در سطح کاربر کوبرنتیز نیست و فقط می‌بایست توسط ادمین ساخته شود. storage‌ها در کوبرنتیز مدل‌های مختلفی دارند.

Local storage

در این حالت دیتای هر کانتینر در همان نود خود ذخیره می‌شود. یکی از مشکلات local storage این است که dynamic بودن سیستم از دست می‌رود.به هر دلیلی سروری که دیتا‌های Pod‌ها روی آن ذخیره شده باشد دچار مشکل می‌شود، کل دیتا‌ها از بین خواهند رفت و به همین دلیل در محیط‌های عملیات موارد مربوط به storage‌ها به صورت remote storage در نظر گرفته می‌شوند که تحت backend‌های مختلف storage راه اندازی می‌گردند. در storage‌های local از برخی ویژگی‌های کوبرنتیز نمی‌توان استفاده ‌کرد، مواردی مثل جا به جایی pod‌ها روی نود‌های مختلف و…

Remote storage

برای storage در کوبرنتیز می‌توان از backend‌های مختلفی بهره مند شد. می‌توان سیستم storage ایجاد و دیتا‌های مهم مربوط به کانتینر‌ها را در storage راه اندازی شده ذخیره سازی کرد. به عنوان مثال می‌توان یک NFS storage راه اندازی کرد و دیتای کانتینر‌های کلاستر کوبرنتیز را ذخیره سازی کرد. برای نگهداری سرویس‌های بزرگ و در محیط‌های عملیاتی، حتما می‌بایست از Remote Storage‌ها در کلاستر کوبرنتیز استفاده کرد.

انواع storage از دیدگاه فیزیکال

SAN

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

DAS

تجهیزات خاصی مانند SAN ندارد، و در اصل خود سرور است که آن را متصل به‌هارد‌های مختلف می‌کند. remote storage‌هایی مانند NFS و Ceph از نوع DAS است.

چندین مفهوم مهم در storage مربوط به کوبرنتیز وجود دارند که به شرح آنها خواهیم پرداخت.

Volume

والیوم بخشی از تنظیمات Pod است که در template مربوط به آن , و در ساختار پاد تعریف می‌شوند و یا به عبارتی دیگر فیلد مربوط به volume در سطح Pod تعریف می‌شود. این والیوم می‌تواند یک فضای موقت مانند یک فولدر در‌ هاست نود کوبرنتیز باشد. بنا به صلاح دید می‌توانیم هر نوع و هر تعداد والیومی ‌را به pod تخصیص دهیم. والیوم‌ها دارای انوع مختلفی هستند که گستردگی زیادی دارند. در تصویر زیر برخی از نام والیوم‌ها می‌توان مشاهده کرد.

همه والیوم‌های فوق این ویژگی را ندارند که بتوان به عنوان PV از آنها بهره‌مند شد و فقط برخی از آنها هستند که می‌توانند به عنوان PV عمل کنند، و دیتای‌های مربوط به Pod‌ها را به صورت دائمی‌در خود ذخیره کنند. (والیوم‌های ذکر شده با رنگ قرمز می‌توانند به صورت PV عمل کنند)

والیوم‌ها در ساختار pod می‌توانند در spec تعریف شوند. در ساختار yaml در pod در قسمت spec از فیلد volume می‌توان استفاده کرد که در زیر مجموعه آن می‌توان نام و نوع والیوم را مشخص کرد. برای اینکه بتوان از والیوم‌های تعریفی در کانتینر‌های استفاده کرد یک تو رفتگی در فیلد container از فیلد volumeMounts استفاده می‌کنیم. volumeMount را به ازای هر کانتینر به صورت جداگانه تعریف می‌کنند. در مثال زیر یک مانیفست که از والیوم استفاده می‌کند گرد آوری شده است.

در این مانفیست دو کانتینر در ساختار Pod تعریف شده است، هر کدام از کانتینر‌ها volumeMount مربوط به خود را دارند. در ساختار فوق یک والیوم وجود دارد که نام آن html است و نوع emtyDir که است که این نوع والیوم ماهیت کوبرنتیزی و از نوع ephemeral است که در صورت stop شدن پاد دیتای آن نیز پاک خواهد شد. که این والیوم در هر مسیر مشخص شده‌ای در هر کانتینر mount شده است. یکی از کانتینر‌ها فایلی ایجاد می‌کند و تاریخ را در فایل چاپ می‌کند و کانتینر دیگر در مسیر nginx خود فایل را فراخوانی کرده است و موارد ساخته شده توسط کانتینر دیگر را در خروجی وب خود نمایش خواهد داد.

persistentVolumeClaim

برای اینکه بتوان از PVها استفاده کرد می‌بایست از persistentVolumeClaim استفاده کرد. به عبارت دیگر نمی‌توان در ساختار Pod به صورت مستقیم PV را فراخوانی و از آنها استفاده کرد. همانطور که توضیحات ارائه شده PV‌های به صورت cluster wide است و توسط ادمین‌ها در سطح کلاستر تعریف می‌شوند، و برای اینکه بتوان از PV‌ها برای والیوم‌ها در ساختار پاد استفاده کرد، می‌بایست از مفهومی‌به نام persistentVolumeClaim یا PVC بهره مند شد. به بیانی دیگر کاربر در سطح کلاستر کوبرنتیز PVC می‌سازد و با کمک PVC می‌تواند PV که توسط ادمین ساخته شده است را فراخانی کند. همچنین لازم به ذکر است که PVC به صورتname space base است، یعنی هر کاربری می‌تواند در name space جداگانه خود اقدام به ساخت PVC مورد نیاز خود کند.

کارکرد PV و PVC

در تصویر زیر چرخه کاری این دو concept در کلاستر کوبرنتیز نمایان است.

همانطور که در تصویر مشخص است، سه PV وجود دارد که در سطح کلاستر توسط ادمین ساخته شده است و در سمت مقابل PVC‌ها وجود دارند که توسط کاربران درname space‌های خود ساخته شده‌اند. PVC‌های ساخته شده هر یک به PV مورد نظر خود متصل شده است و POD می‌آید و با استفاده از PVC‌های ساخته شده به PV‌ها برای ذخیره سازی data‌های مد نظر متصل می‌شود.

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

با توحه به backend مربوط به storage، ساختار فایل‌های مانیفست مربوط به PV می‌تواند متفاوت باشد. مثال فوق ساخت یک PV در زیر ساخت NFS است. ظرفیت PV فوق در فیلد storage مشخص شده است که ۵۰ گیگ است. در فیلد accessModes نوع دسترسی به PV مشخص می‌شود که فقط می‌تواند یک نوع در آن فراخوانی شود. به عنوان مثال فیلد ReadWriteOnce بیانگر این است که از در لحظه با دسترسی خواندن و نوشتن فقط در یک مسیری که آن mount شده است ویک پاد می‌تواند به آن دسترسی داشته باشد. در فیلد NFS نیز فیلد آدرس سرور مربوط به storage فوق به همراه مسیر آن فراخوانی شده است. در قسمت VolumeModes نیز دو فیلد می‌توان ذکر کرد یکی block که می‌آید پارتیشنی خام را در نظر می‌گیرد. (raw disk) و یا می‌توان file system درنظر گرفت که می‌تواند فضایی به صورت پارتیشن اما فرمت شده در نظر می‌گیرد. فیلد PersistentVolumeReclaimPolicy نیز می‌تواند مقادیر مختلفی به خود اختصاص دهد. به عنوان مثال اگر مقدار Retain برای آن set شود، به هیچ عنوان PV مورد نظر پاک نخواهد شد مگر آنکه با کامند به صورت مستقیم اقدام به حذف PV نماییم. و اگر مقدار فیلد مورد نظر delete باشد، در صورتی که کسی آن PVC را ساخته باشد اگر پاک شود، به صورت اتومات PV آن نیز پاک خواهد شد. (namespace که  در آن PVC ساخته شده است اگر پاک شود PV  متصل به آن نیز حذف خواهد شد)

در مانفیست‌های زیر یک نمونه از ساختPVC  که PV را فراخوانی می‌کند گرد آوری شده است.

در PVC ساخته شده در قسمت selector در فیلد matchlabels لیبلی مشخص فراخوانی شده است، لیبلی که در PV وجود دارد و نحوه برقراری ارتباط PVC با PV به همین صورت با تخصیص label‌ها و فراخوانی در PVC به وسیله selector‌ها است.

نتیجه

در محیط‌های عملیاتی کلاستر کوبرنتیز قطعا باید از remote storage‌هایی با backend قوی همانند Ceph استفاده کرد. و همیشه می‌بایست دیتای مهم کانتینر‌ها همانند پایگاههای داده را با کمک persistent volume‌ها دائمی‌کرد.