ذخیره داده ها در یک خوشه Kubernetes

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

روش 1: PV را در مانیفست غلاف مشخص کنید

یک مانیفست معمولی که یک غلاف در یک خوشه Kubernetes را توصیف می کند:

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

در بخش حجم نصب می شود نقاط مونت (mountPath) را نشان دهید - در کدام دایرکتوری در داخل کانتینر حجم دائمی و همچنین نام حجم نصب می شود.

در بخش x تمام حجم هایی که در پاد استفاده می شود را فهرست می کند. نام هر حجم و همچنین نوع (در مورد ما: awsElasticBlockStore) و پارامترهای اتصال را مشخص کنید. اینکه کدام پارامتر در مانیفست فهرست شده است به نوع حجم بستگی دارد.

همان حجم را می توان به طور همزمان در چندین ظرف غلاف نصب کرد. به این ترتیب، فرآیندهای برنامه های مختلف می توانند به داده های مشابه دسترسی داشته باشند.

این روش اتصال در همان ابتدا ابداع شد، زمانی که Kubernetes تازه در ابتدای راه بود و امروزه این روش منسوخ شده است.

هنگام استفاده از آن چندین مشکل وجود دارد:

1. همه حجم ها باید به صورت دستی ایجاد شوند؛ Kubernetes نمی تواند چیزی برای ما ایجاد کند.
2. پارامترهای دسترسی برای هر حجم منحصربه‌فرد هستند و باید در مانیفست‌های همه پادهایی که از حجم استفاده می‌کنند مشخص شوند.
3. برای تغییر سیستم ذخیره سازی (به عنوان مثال، انتقال از AWS به Google Cloud)، باید تنظیمات و نوع حجم های نصب شده را در همه مانیفست ها تغییر دهید.

همه اینها بسیار ناخوشایند است، بنابراین در واقعیت از این روش برای اتصال فقط برخی از انواع خاصی از حجم ها استفاده می شود: configMap، Secret، valaDir، hostPath:

• configMap و Secret حجم‌های سرویسی هستند که به شما امکان می‌دهند یک حجم با فایل‌های مانیفست Kubernetes در کانتینر ایجاد کنید.

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

• hostPath - به شما این امکان را می دهد که هر دایرکتوری را روی دیسک محلی سروری که برنامه روی آن در داخل کانتینر برنامه در حال اجرا است سوار کنید، از جمله /etc/kubernetes. این یک ویژگی ناامن است، بنابراین سیاست‌های امنیتی معمولاً استفاده از حجم‌هایی از این نوع را ممنوع می‌کنند. در غیر این صورت، برنامه مهاجم می‌تواند دایرکتوری HTC Kubernetes را در کانتینر خود نصب کند و تمام گواهی‌های کلاستر را بدزدد. به طور معمول، حجم های hostPath فقط توسط برنامه های کاربردی سیستمی که در فضای نام سیستم kube اجرا می شوند مجاز هستند.

سیستم های ذخیره سازی که Kubernetes خارج از جعبه با آنها کار می کند در اسناد آورده شده است.

روش 2. اتصال به کوره های SC/PVC/PV

یک روش اتصال جایگزین مفهوم کلاس Storage، PersistentVolumeClaim، PersistentVolume است.

کلاس ذخیره سازی پارامترهای اتصال به سیستم ذخیره سازی داده را ذخیره می کند.

PersistentVolumeClaim الزامات مورد نیاز برنامه را شرح می دهد.
Persistent Volume پارامترهای دسترسی و وضعیت حجم را ذخیره می کند.

ماهیت ایده: در مانیفست pod حجمی از نوع PersistentVolumeClaim را نشان می‌دهند و نام این موجودیت را در پارامتر pretendName نشان می‌دهند.

مانیفست PersistentVolumeClaim الزامات حجم داده مورد نیاز برنامه را توضیح می دهد. شامل:

• اندازه دیسک؛
• روش دسترسی: ReadWriteOnce یا ReadWriteMany.
• پیوند به کلاس Storage - در کدام سیستم ذخیره سازی داده می خواهیم حجم را ایجاد کنیم.

مانیفست کلاس Storage نوع و پارامترهای اتصال به سیستم ذخیره سازی را ذخیره می کند. cubelet به آنها نیاز دارد تا حجم را روی گره خود نصب کنند.

مانیفست های PersistentVolume کلاس Storage و پارامترهای دسترسی را برای یک حجم خاص (شناسه حجم، مسیر و غیره) نشان می دهد.

هنگام ایجاد PVC، Kubernetes به حجم حجم و کلاس ذخیره سازی مورد نیاز نگاه می کند و یک PersistentVolume رایگان را انتخاب می کند.

اگر چنین PV هایی در دسترس نباشند، Kubernetes می تواند یک برنامه ویژه - Provisioner (نام آن در کلاس Storage نشان داده شده است) راه اندازی کند. این برنامه به سیستم ذخیره سازی متصل می شود، حجمی به اندازه مورد نیاز ایجاد می کند، یک شناسه دریافت می کند و یک مانیفست PersistentVolume در خوشه Kubernetes ایجاد می کند که با PersistentVolumeClaim مرتبط است.

تمام این مجموعه انتزاعات به شما امکان می دهد اطلاعات مربوط به سیستم ذخیره سازی برنامه را از سطح مانیفست برنامه به سطح مدیریت حذف کنید.

تمامی پارامترهای اتصال به سیستم ذخیره سازی اطلاعات در کلاس Storage قرار دارند که مسئولیت آن بر عهده مدیران کلاستر است. تنها کاری که باید هنگام انتقال از AWS به Google Cloud انجام دهید این است که نام کلاس Storage را در مانیفست برنامه به PVC تغییر دهید. Persistance Volume برای ذخیره سازی داده ها به طور خودکار با استفاده از برنامه Provisioner در خوشه ایجاد می شود.

روش 3: رابط ذخیره سازی کانتینر

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

برای حل این مشکل، توسعه دهندگان از Cloud Foundry، Kubernetes، Mesos و Docker، Container Storage Interface (CSI) را ایجاد کردند - یک رابط یکپارچه ساده که تعامل سیستم مدیریت کانتینر و یک درایور خاص (CSI Driver) را توصیف می کند که با یک درایور خاص کار می کند. سیستم ذخیره سازی. تمام کدهای تعامل با سیستم های ذخیره سازی از هسته Kubernetes به یک سیستم جداگانه منتقل شد.

اسناد رابط ذخیره سازی کانتینر.

به طور معمول، درایور CSI از دو جزء تشکیل شده است: پلاگین Node و پلاگین کنترلر.

Node Plugin بر روی هر گره اجرا می شود و وظیفه نصب ولوم ها و انجام عملیات بر روی آنها را بر عهده دارد. افزونه Controller با سیستم ذخیره سازی تعامل دارد: حجم ها را ایجاد یا حذف می کند، حقوق دسترسی را اختصاص می دهد و غیره.

در حال حاضر، درایورهای قدیمی در هسته Kubernetes باقی مانده اند، اما دیگر استفاده از آنها توصیه نمی شود و به همه توصیه می شود که درایور CSI را به طور خاص برای سیستمی که با آن کار می کنند نصب کنند.

این نوآوری ممکن است کسانی را که قبلاً به راه اندازی ذخیره سازی داده از طریق کلاس Storage عادت کرده اند، بترساند، اما در واقع هیچ اتفاق وحشتناکی رخ نداده است. برای برنامه نویسان، هیچ چیز واقعاً تغییر نمی کند - آنها فقط با نام کلاس Storage کار کرده اند و به این کار ادامه خواهند داد. برای مدیران، نصب نمودار فرمان اضافه شده است و ساختار تنظیمات تغییر کرده است. اگر قبلاً تنظیمات مستقیماً در کلاس Storage وارد می شد، اکنون باید ابتدا در نمودار فرمان و سپس در کلاس Storage تنظیم شوند. اگر به آن نگاه کنید، اتفاق بدی نیفتاده است.

بیایید مثالی بزنیم تا مزایایی را که می‌توانید با اتصال به سیستم‌های ذخیره‌سازی Ceph با استفاده از درایور CSI به دست آورید، بررسی کنیم.

هنگام کار با Ceph، افزونه CSI گزینه های بیشتری را برای کار با سیستم های ذخیره سازی نسبت به درایورهای داخلی ارائه می دهد.

1. ایجاد دیسک پویا معمولاً دیسک‌های RBD فقط در حالت RWO استفاده می‌شوند، اما CSI برای Ceph به آنها اجازه می‌دهد در حالت RWX استفاده شوند. چندین پاد در گره های مختلف می توانند دیسک RDB یکسان را روی گره های خود نصب کنند و با آنها به صورت موازی کار کنند. اگر منصف باشیم، همه چیز چندان روشن نیست - این دیسک را فقط می توان به عنوان یک دستگاه بلوک متصل کرد، به این معنی که باید برنامه را برای کار با آن در حالت دسترسی چندگانه تطبیق دهید.
2. ایجاد عکس های فوری در یک خوشه Kubernetes، می توانید یک مانیفست با نیاز به ایجاد یک عکس فوری ایجاد کنید. افزونه CSI آن را می بیند و یک عکس فوری از دیسک می گیرد. بر اساس آن، می توانید یک نسخه پشتیبان یا یک کپی از PersistentVolume ایجاد کنید.
3. افزایش حجم دیسک در ذخیره سازی و حجم پایدار در یک خوشه Kubernetes.
4. سهمیه ها درایورهای CephFS ساخته شده در Kubernetes از سهمیه ها پشتیبانی نمی کنند، اما پلاگین های جدید CSI با آخرین Ceph Nautilus می توانند سهمیه ها را در پارتیشن های CephFS فعال کنند.
5. متریکی. پلاگین CSI می تواند معیارهای مختلفی را در مورد اینکه کدام حجم ها متصل هستند، چه ارتباطاتی در حال انجام است و غیره به Prometheus ارائه می دهد.
6. آگاه از توپولوژی به شما امکان می دهد در مانیفست ها نحوه توزیع جغرافیایی خوشه را مشخص کنید و از اتصال یک سیستم ذخیره سازی واقع در آمستردام به غلاف های در حال اجرا در لندن اجتناب کنید.

نحوه اتصال Ceph به خوشه Kubernetes از طریق CSI، ببینید در بخش عملی سخنرانی مدرسه عصر Slurm. شما همچنین می توانید مشترک شوید دوره ویدیویی Ceph، که در 15 اکتبر راه اندازی می شود.

نویسنده مقاله: سرگئی بوندارف، معمار مجرب در Southbridge، مدیر معتبر Kubernetes، یکی از توسعه دهندگان kubespray.

یک پست اسکریپت کوچک نه برای تبلیغات، بلکه برای سود...

PS سرگئی بوندارف دو دوره فشرده را هدایت می کند: به روز شده پایگاه کوبرنتیس 28-30 سپتامبر و پیشرفته Kubernetes Mega 14 تا 16 اکتبر.

منبع: www.habr.com