آموزش استفاده کردن از Volume ها و Multi-container Pod ها در Kubernetes

بسته ی آموزش ویدئویی استفاده کردن از Volum ها و Multi-container Pod ها در Kubernetes یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته ی آموزشی کار با Kubernetes برای برنامه نویسان و یکپارچه کردن Volume ها و استفاده از Multi-container Pod ها است که با نام اصلی Kubernetes for Developers Integrating Volumes and Using Multi-container Pods از شرکت Pluralsight منتشر شده است.

ماهیت Volume ها در کوبرنتیز(Kubernetes)

در کوبرنتیز یک volume شبیه یک فولدر است که می تواند توسط container های موجود در یک pod مورد دسترسی قرار بگیرد. در کوبرنتیز، انواع مختلفی از volume ها وجود دارند که هر کدام از انواع مختلف volume ها در کوبرنتیز به شکلی متفاوت، تولید شده و محتوای متفاوتی را نیز دارند.

مفهوم volume ها در ابزار داکر نیز وجود دارد. با این وجود، ایرادی که به volume های داکر وارد است این است که یک volume در داکر بسیار محدود به یک pod است و به محض اینکه یک pod از بین برود، volume مربوطه نیز از بین خواهد رفت. این در حالی است که volume های ایجاد شده توسط کوبرنتیز به هیچ container خاصی محدود نیستند. volume های ایجاد شده در کوبرنتیز از تمامی container های موجود در یک pod پشتیبانی می کند. یکی از مزیت های اصلی volume ها در کوبرنتیز، در این است که در انواع مختلف ذخیره سازی و یا storage پشتیبانی می کنند. در ادامه تعدادی از انواع مختلف volume ها در کوبرنتیز را بررسی می کنیم.

• نوع emptyDir: این نوع از volume ها، در زمان ایجاد شدن یک pod و قرار گرفتن آن در یک node ایجاد می شود. این volume ها، تا زمانی که pod در حال اجرا شدن بر روی یک node می باشد، فعال باقی خواهد ماند. این نوع volume ها در ابتدا خالی هستند و container های موجود در pod می توانند فایلهایی را درون این volume نوشته و یا از آن بخوانند. زمانی که pod نهایتاً از node مورد نظر حذف شد، داده های درون این volume نیز از بین می روند.
• نوع hostPath: با استفاده از این volume ها می توانید یک فایل و یا فولدر را از درون filesystem مربوط به میزبان یا host به درون pod جایگذاری و یا اصطلاحاً mount کنید.
• نوع gcePersistentDisk: با استفاده از این نوع از volume ها می توانید یک gcePersistentDisk را به درون pod بارگذاری و یا mount کنید. node های موجود gcePersistentDisk پس از حذف شدن pod از روی node همچنان باقی خواهند ماند.
• نوع awsElasticBlockStore: با استفاده از این نوع از volume ها می توانید یک awsElasticBlockStore را به درون pod بارگذاری و یا mount کنید. دقیقاً شبیه به gcePersistentDisk داده های درون awsElasticBlockStore پس از بین رفتن pod بر روی node همچنان باقی خواهند ماند.
• نوع nfs: یک volume از نوع nfs که مخفف network file system می باشد کمک می کند تا یک nfs از قبل موجود به درون pod بارگذاری و یا mount بشود. پس از حذف شدن pod از node مربوطه، داده های درون nfs از بین نمی روند و فقط از حالت بارگذاری شده خارج شده و یا اصطلاحاً unmount می شوند.
• نوع iscsi: این نوع از volume ها اجازه می دهند تا یک iscsi به درون pod مورد نظر شما mount بگردند.

در این قسمت فقط تعدادی از انواع volume ها در کوبرنتیز را بررسی کردیم. انواع مختلفی وجود دارند که برای بررسی دقیق آنها می‌توانید به مستندات کوبرنتیز مراجعه کنید.

ذخیره‌سازی داده‌ها در Kubernetes و مدیریت چرخه عمر آن‌ها

در Kubernetes، اپلیکیشن‌ها معمولاً درون Containerهایی اجرا می‌شوند که بخشی از Podها هستند. با این حال، فایل‌هایی که داخل محیط یک Container ذخیره می‌شوند، لزوماً برای نگهداری پایدار داده‌ها مناسب نیستند؛ زیرا ممکن است Container دوباره ایجاد شود یا جایگزین شود. Volumeها برای فراهم کردن فضای ذخیره‌سازی در اختیار Containerهای یک Pod به کار می‌روند و به برنامه اجازه می‌دهند داده‌های مورد نیاز خود را در محلی مناسب‌تر نگهداری کند.

انتخاب روش ذخیره‌سازی به نوع داده و نحوه استفاده اپلیکیشن از آن بستگی دارد. برای مثال، یک برنامه ممکن است به فایل‌های موقت نیاز داشته باشد، در حالی که برنامه دیگری باید به داده‌هایی دسترسی داشته باشد که پس از جایگزینی Container نیز حفظ شوند. درک تفاوت نیازهای ذخیره‌سازی به توسعه‌دهنده کمک می‌کند از Volume مناسب استفاده کند و محدودیت‌های فضای ذخیره‌سازی داخل Container را بهتر بشناسد. این موضوع در طراحی اپلیکیشن‌های قابل اجرا روی Kubernetes اهمیت دارد.

کاربرد Multi-container Pod در Kubernetes

در Kubernetes، یک Pod می‌تواند بیش از یک Container داشته باشد. این ساختار زمانی مفید است که چند فرایند مرتبط باید در یک واحد اجرایی مشترک قرار بگیرند و به منابع یا محیط اجرایی نزدیک به هم نیاز داشته باشند. Containerهای داخل یک Pod می‌توانند از شبکه مشترک Pod استفاده کنند و در صورت نیاز به Volumeهای مشترک دسترسی داشته باشند. این قابلیت امکان تفکیک مسئولیت‌ها را فراهم می‌کند، بدون آنکه برای هر فرایند الزاماً یک Pod جداگانه تعریف شود.

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

ارتباط Volumeها با Containerهای یک Pod

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

در طراحی چنین ساختاری، باید مشخص باشد هر Container چه داده‌ای را می‌خواند یا می‌نویسد و آیا لازم است داده‌ها پس از جایگزینی Container باقی بمانند یا خیر. همچنین نوع Volume انتخاب‌شده بر رفتار ذخیره‌سازی و طول عمر داده‌ها تأثیر می‌گذارد. بررسی این نیازها پیش از تعریف منابع Kubernetes کمک می‌کند ساختار ذخیره‌سازی با رفتار واقعی اپلیکیشن هماهنگ باشد. این رویکرد برای توسعه‌دهندگانی که اپلیکیشن‌های چندکانتینری طراحی می‌کنند، اهمیت عملی دارد.

ایمن‌سازی اپلیکیشن‌ها با Service Account در Kubernetes

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

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