عندما وصل أوركسترا الحاويات مثل Kubernetes ، تغير النهج المتبع في تطوير التطبيقات ونشرها بشكل كبير. ظهرت Microservices ، ولم يعد مطور منطق التطبيق مرتبطًا بالبنية التحتية: أنشئ تطبيقات لنفسك وقدم وظائف جديدة.
Kubernetes المستخلصات من أجهزة الكمبيوتر الفعلية التي تسيطر عليها. فقط أخبره عن مقدار الذاكرة والطاقة التي تحتاجها - وستحصل على كل شيء. البنية التحتية؟ لا ، لم يسمع.
إدارة الصور Docker ، Kubernetes والتطبيقات يجعلها المحمولة. بعد تطوير تطبيقات الحاوية مع Kubernetes ، يمكنك نشرها في أي مكان: إلى سحابة مفتوحة ، محليًا أو في بيئة مختلطة - دون تغيير الكود.
نحن نحب Kubernetes لقابلية التوسع والقابلية وسهولة الإدارة ، لكنه لا يخزن الحالة. ولكن لدينا جميع تطبيقات الحالة تقريبا ، أي أنها تحتاج إلى وحدة تخزين خارجية.
Kubernetes لديها بنية ديناميكية للغاية. يتم إنشاء حاويات وتدميرها اعتمادا على الحمل وتعليمات المطورين. السنفات والحاويات ذاتية الشفاء والتكرار. هم أساسا سريعة الزوال.
التخزين الخارجي صعب للغاية بالنسبة لمثل هذا التباين. لا تطيع قواعد الخلق والتدمير الديناميكي.
كل ما تحتاجه هو نشر تطبيق فعال في بنية أساسية أخرى: في سحابة أخرى هناك ، محليًا أو في نموذج هجين - كيف توجد مشكلات في قابلية النقل. يمكن ربط التخزين الخارجي بسحابة معينة.
ولكن فقط في هذه المخازن المخصصة للتطبيقات السحابية ، فإن الشيطان نفسه سوف يكسر ساقه. واذهب لفهم المعاني والمعاني الوهمية لمصطلحات التخزين في Kubernetes . وهناك مستودعات Kubernetes الخاصة بها ومنصات مفتوحة المصدر وخدمات مدارة أو مدفوعة ...
فيما يلي بعض الأمثلة على التخزين السحابي CNCF :
يبدو أن نشر قاعدة البيانات في Kubernetes - تحتاج فقط إلى تحديد الحل المناسب ، وتعبئته في حاوية للعمل على القرص المحلي ونشره على الكتلة كحمل العمل التالي. لكن قاعدة البيانات لها خصائصها الخاصة ، لذلك التفكير ليس جليدًا.
الحاويات - إنها مرصوفة ببعضها البعض بحيث لا تحافظ على حالتها. هذا هو السبب في أنها سهلة جدا لبدء والتوقف. ولأنه لا يوجد شيء للحفظ والنقل ، فإن المجموعة لا تهتم بعمليات القراءة والنسخ.
سيكون لديك لتخزين الحالة مع قاعدة البيانات. إذا لم يتم ترحيل قاعدة البيانات التي تم نشرها إلى كتلة في حاوية في أي مكان ولم تبدأ من جديد كثيرًا ، فسيتم تشغيل فيزياء تخزين البيانات. من الناحية المثالية ، يجب أن تكون الحاويات التي تستخدم البيانات في نفس قاعدة البيانات.
في بعض الحالات ، يمكن نشر قاعدة البيانات ، بالطبع ، في حاوية. في بيئة الاختبار أو في المهام التي توجد فيها بيانات قليلة ، تعيش قواعد البيانات بشكل مريح في مجموعات.
عادة ما يتطلب الإنتاج تخزين خارجي.
تتواصل Kubernet مع المستودع من خلال واجهات طائرة التحكم. يربطون Kubernetes بالتخزين الخارجي. يسمى التخزين الخارجي المتصل بـ Kubernetes الإضافات الصوتية. معهم ، يمكنك تجريد التخزين ونقل التخزين.
تستخدم الإضافات الصوتية لوحدات التخزين وربطها وتجميعها وتسليمها باستخدام قاعدة كود Kubernetes. هذا مطور محدود للغاية والصيانة الإضافية المطلوبة: إذا كنت ترغب في إضافة مستودعات جديدة ، يرجى تغيير قاعدة كود Kubernetes.
الآن نشر المكونات الإضافية لحجم الكتلة - لا أريد ذلك. ولا تحتاج إلى الحفر في قاعدة الشفرة. بفضل CSI و Flexvolume.
Kubernetes التخزين الأصلي
كيف تقوم Kubernetes بحل مشكلات التخزين؟ هناك العديد من الحلول: خيارات سريعة الزوال ، تخزين مستمر في وحدات التخزين الثابتة ، استعلامات المطالبة بالحجم الثابت ، فئات التخزين ، أو StatefulSets. الذهاب معرفة ذلك ، بشكل عام.
وحدات التخزين الثابتة (PV) هي وحدات تخزين من إعداد المسؤول. انهم لا يعتمدون على الموقد وحياتهم عابرة.
المطالبة المستمرة بالحجم (PVC) هي طلبات تخزين ، أي الكهروضوئية. باستخدام PVC ، يمكنك ربط التخزين بالعقدة ، وسوف تستخدمه هذه العقدة.
يمكنك العمل مع التخزين بشكل ثابت أو ديناميكي.
مع اتباع نهج ثابت ، يعد المسؤول PVs ، والتي من المفترض أن تكون مطلوبة مسبقًا ، قبل الطلبات ، وترتبط هذه PVs يدويًا بأقراص محددة باستخدام مواد PVC واضحة.
في الممارسة العملية ، لا تتوافق PVs المحددة بشكل خاص مع البنية المحمولة Kubernetes - يعتمد التخزين على البيئة ، مثل AWS EBS أو محرك أقراص دائم من GCE. للربط يدويًا ، تحتاج إلى الإشارة إلى مستودع محدد في ملف YAML.
يتناقض النهج الثابت بشكل عام مع فلسفة Kubernetes: لا يتم تخصيص وحدات المعالجة المركزية والذاكرة مسبقًا ولا ترتبط بالأقراص أو الحاويات. يتم إصدارها بشكل حيوي.
لتوفير ديناميكي ، نستخدم فئات التخزين. لا يحتاج مسؤول الكتلة إلى إنشاء PV مقدماً. يخلق العديد من ملفات التخزين ، مثل القوالب. عندما يقوم مطور بتقديم طلب PVC ، في وقت الطلب ، يتم إنشاء أحد هذه الأنماط وإرفاقه بالموقد.
لذلك ، بشكل عام ، تعمل Kubernetes مع وحدة التخزين الخارجية. هناك العديد من الخيارات الأخرى.
CSI - واجهة تخزين الحاويات
هناك شيء من هذا القبيل - واجهة حاوية التخزين . تم إنشاء CSI بواسطة مجموعة عمل CNCF vault ، التي قررت تحديد واجهة تخزين حاويات قياسية بحيث تعمل برامج تشغيل vault مع أي أوركسترا.
تم تكييف مواصفات CSI بالفعل مع Kubernetes ، وهناك أطنان من مكونات برامج التشغيل للنشر في مجموعة Kubernetes. يجب الوصول إلى المستودع من خلال برنامج تشغيل وحدة تخزين متوافق مع CSI - استخدم نوع وحدة تخزين csi في Kubernetes.
مع CSI ، يمكن اعتبار التخزين عبء عمل آخر من أجل حاويات ونشر مجموعة Kubernetes.
لمزيد من التفاصيل ، استمع إلى Jie Yu تتحدث عن CSI في البودكاست الخاص بنا .
مشاريع مفتوحة المصدر
تتضاعف الأدوات والمشروعات الخاصة بالتقنيات السحابية بسرعة ، وحصة عادلة من المشاريع مفتوحة المصدر - وهو أمر منطقي - تحل إحدى مشكلات الإنتاج الرئيسية: العمل مع التخزين في البنية السحابية.
الأكثر شعبية منهم Ceph و Rook.
Ceph عبارة عن مجموعة تخزين موزعة تدار ديناميكيًا مع تحجيم أفقي. يوفر Ceph تجريدًا منطقيًا لموارد التخزين. ليس لديها نقطة فشل واحدة ، فهي تدير نفسها وتعمل على أساس البرامج. يوفر Ceph واجهات لتخزين الكتل والأشياء والملفات في وقت واحد لمجموعة تخزين واحدة.
Ceph لديها بنية معقدة للغاية مع خوارزمية RADOS ، librados ، RADOSGW ، RDB ، CRUSH ومكونات مختلفة (الشاشات ، OSD ، MDS). لن نتعمق في البنية ، يكفي أن نفهم أن Ceph هي مجموعة تخزين موزعة تبسط قابلية التوسع ، وتزيل نقطة فشل واحدة دون التضحية بالأداء وتوفر تخزينًا فرديًا مع إمكانية الوصول إلى الكائنات والكتل والملفات.
وبطبيعة الحال ، يتم تكييف Ceph للسحابة. يمكنك نشر مجموعة Ceph بطرق مختلفة ، على سبيل المثال ، باستخدام Ansible أو في كتلة Kubernetes من خلال CSI و PVC.
Ceph العمارة
الغراب هو مشروع آخر مثير للاهتمام وشعبية. فهو يجمع Kubernetes مع الحوسبة و Ceph مع مستودعاتها في مجموعة واحدة.
Rook هو أوركسترا التخزين السحابي الذي يكمل Kubernetes. يقومون بتعبئة Ceph في حاويات باستخدام منطق إدارة الكتلة للتشغيل الموثوق به لـ Ceph في Kubernetes. تعمل Rook على أتمتة النشر ، والتشغيل ، والتوليف ، والتحجيم ، وإعادة التوازن - بشكل عام ، كل ما يفعله مسؤول النظام.
مع Rook ، يمكن نشر مجموعة Ceph من yaml ، مثل Kubernetes. في هذا الملف ، يحدد المسؤول ما يحتاجه في الكتلة. Rook تطلق مجموعة ويبدأ في المراقبة النشطة. هذا يشبه المشغل أو جهاز التحكم - فهو يضمن تلبية جميع متطلبات yaml. يعمل Rook مع دورات التزامن - يرى الحالة ويتحرك إذا كانت هناك انحرافات.
ليس لديه حالته الدائمة ولا يحتاج إلى السيطرة عليها. إنه بروح Kubernetes.
يعد Rook ، الذي يجمع بين Ceph و Kubernetes ، أحد أكثر حلول التخزين السحابية شيوعًا: 4000 نجمة على Github و 16.3 مليون تنزيل وأكثر من مائة مساهم.
تم قبول مشروع Rook بالفعل في CNCF ، وانتهى به الأمر مؤخرًا في حاضنة .
سوف يخبرك بسام طبارة بمزيد من المعلومات عن Rook في مستودعات Kubernetes الخاصة بنا .
إذا واجه التطبيق مشكلة ، فأنت بحاجة إلى معرفة المتطلبات وإنشاء نظام أو استخدام الأدوات اللازمة. وهذا ينطبق أيضا على التخزين السحابي. وعلى الرغم من أن المشكلة ليست مشكلة بسيطة ، إلا أن الأدوات والمناهج لم تصل. تستمر تقنية السحابة في التطور ، وسوف تنتظرنا بالتأكيد حلول جديدة.