🐋 🔧 🕦 أنماط التخزين Kubernetes 🤵🏿 ✊🏽 ✝️

مرحبا يا هابر!

نذكركم أننا أصدرنا كتابًا آخر مثيرًا للاهتمام ومفيدًا للغاية حول أنماط Kubernetes. بدأ كل شيء مع " أنماط " بريندان بيرنز ، وبالمناسبة ، فإن العمل في هذا الجزء على قدم وساق . ندعوكم اليوم لقراءة مقال من مدونة MinIO يلخص اتجاهات وتفاصيل أنماط تخزين البيانات في Kubernetes.

غيرت Kubernetes بشكل أساسي الأنماط التقليدية لتطوير التطبيقات ونشرها. الآن يمكن أن يستغرق الفريق أيامًا لتطوير التطبيق واختباره ونشره - في بيئات مختلفة ، وكل هذا داخل مجموعات Kubernetes. عادة ما يستغرق هذا العمل مع التكنولوجيا من الأجيال السابقة أسابيع ، إن لم يكن شهورًا.

تم تحقيق هذا التسارع بفضل التجريد الذي قدمته Kubernetes - وهذا يرجع إلى حقيقة أن Kubernetes نفسها تتفاعل مع التفاصيل ذات المستوى المنخفض من الأجهزة المادية أو الافتراضية ، مما يسمح للمستخدمين بالإعلان ، من بين معلمات أخرى ، المعالج المطلوب ، والذاكرة المطلوبة ، وعدد حالات الحاوية. نظرًا لأن Kubernetes مدعوم من قبل مجتمع ضخم ، ونطاق Kubernetes يتوسع باستمرار ، فإنه يقود بهامش كبير بين جميع منصات تنسيق الحاويات.

مع توسع استخدام Kubernetes ، يتزايد الارتباك حول أنماط التخزين المستخدمة فيه .

مع المنافسة العامة لقطعة من فطيرة Kubernetes (أي لتخزين البيانات) ، عندما يتعلق الأمر بالحديث عن تخزين البيانات ، فإن الإشارة تغرق في ضوضاء عالية.
تجسد Kubernetes نموذجًا حديثًا لتطوير التطبيقات ونشرها وإدارتها. يعمل هذا النموذج الحديث على فصل تخزين البيانات عن الحوسبة. لفهم هذا الفصل بشكل كامل في سياق Kubernetes ، تحتاج أيضًا إلى فهم التطبيقات ذات الحالة وعديمي الجنسية ، وكيفية دمج تخزين البيانات مع هذا. هذا هو المكان الذي يتميز منهج REST API الذي تستخدمه S3 بمزايا واضحة مقارنة بنهج POSIX / CSI النموذجي للحلول الأخرى.

في هذه المقالة ، سنتحدث عن أنماط التخزين في Kubernetes وسنناقش بشكل منفصل النقاش حول التطبيقات الآمنة للدولة والتطبيقات عديمة الحالة ، حتى نتمكن من فهم الفرق بينها بوضوح وسبب أهميتها. كذلك في النص ، سننظر في التطبيقات وأنماط تخزين البيانات المستخدمة فيها في ضوء أفضل الممارسات للعمل مع الحاويات و Kubernetes.

حاويات عديمة الجنسية

الحاويات خفيفة الوزن وذات زوال بطبيعتها. يمكن إيقافها أو حذفها أو نشرها بسهولة على عقدة أخرى - كل هذا يستغرق بضع ثوان. في نظام تنسيق الحاويات الكبير ، تحدث مثل هذه العمليات طوال الوقت ، ولا يلاحظ المستخدمون مثل هذه التغييرات. ومع ذلك ، تكون الحركات ممكنة فقط إذا كانت الحاوية ليس لها تبعيات على العقدة التي تقع عليها. ويقال أن هذه الحاويات تعمل دون حفظ الدولة .

حاويات رسمية

إذا قامت الحاوية بتخزين البيانات على الأجهزة المتصلة محليًا (أو على جهاز كتلة) ، فسيتعين نقل مستودع البيانات الموجود عليه إلى عقدة جديدة مع الحاوية نفسها - في حالة الفشل. هذا مهم ، لأنه بخلاف ذلك لن يتمكن التطبيق الذي يتم تشغيله في الحاوية من العمل بشكل صحيح ، لأنه يحتاج إلى الوصول إلى البيانات المخزنة على الوسائط المحلية. ويقال إن هذه الحاويات لتكون جليل .

من وجهة نظر فنية بحتة ، يمكن أيضًا نقل الحاويات ذات الحالات إلى عقد أخرى. عادة ، يتم تحقيق ذلك باستخدام أنظمة الملفات الموزعة أو حجب مخازن الشبكة المتصلة بجميع العقد التي تعمل عليها الحاويات. وبالتالي ، يمكن للحاويات الوصول إلى وحدات التخزين لتخزين البيانات المستمر ، ويتم تخزين المعلومات على الأقراص الموجودة في جميع أنحاء الشبكة. سأطلق على مثل هذه الطريقة " نهج حاوية الحفاظ على الدولة " ، وسأطلق عليها في بقية المقالة من أجل التوحيد.

في نهج الحاوية النموذجية ، يتم إرفاق جميع لوحات التطبيق بنظام ملفات موزع واحد - يتم الحصول على نوع من التخزين المشترك ، حيث يتم الحصول على جميع بيانات التطبيق. في حين أن بعض الاختلافات ممكنة ، إلا أن هذا نهج عالي المستوى.

الآن دعونا نلقي نظرة على سبب كون نهج الحاوية الرسمية في العالم القائم على السحابة مضادًا.

تصميم التطبيقات المستندة إلى السحابة

تقليديا ، استخدمت التطبيقات قواعد البيانات للتخزين المنظم للمعلومات والأقراص المحلية أو أنظمة الملفات الموزعة ، حيث تم التخلص من جميع البيانات غير المنظمة أو حتى شبه المنظمة. مع نمو حجم البيانات غير المنظمة ، أدرك المطورون أن POSIX كانت ثرثارة للغاية ، وترتبط بتكاليف كبيرة ، وفي النهاية تتداخل مع التطبيق عند الانتقال إلى نطاق كبير حقًا.

ساهم هذا بشكل رئيسي في ظهور معيار جديد لتخزين البيانات ، أي التخزين القائم على السحابة الذي يعمل بشكل أساسي على أساس REST API وتحرير التطبيق من الصيانة المرهقة لمستودع البيانات المحلية. في هذه الحالة ، يدخل التطبيق فعليًا في وضع التشغيل دون حفظ الحالة (نظرًا لأن الحالة في التخزين البعيد). يتم بناء التطبيقات الحديثة من الصفر مع مراعاة هذا العامل بالفعل. كقاعدة ، يتم بناء أي تطبيق حديث يعالج البيانات من نوع أو آخر (السجلات ، البيانات الوصفية ، النقط ، وما إلى ذلك) على نموذج موجه نحو السحابة ، حيث يتم نقل الحالة إلى نظام برمجيات مخصص خصيصًا لتخزينه.

نهج الحاوية ذو الحالة يجعل هذا النموذج برمته يتراجع تمامًا إلى حيث بدأ!

عند استخدام واجهات POSIX لتخزين البيانات ، تعمل التطبيقات بنفس الطريقة كما لو كانت تحافظ على الحالة ، وبسبب ذلك ، تنحرف عن أهم الافتراضات للتصميم المستند إلى السحابة ، أي من القدرة على تغيير حجم سير عمل التطبيق اعتمادًا على الوارد تحميل ، انتقل إلى عقدة جديدة بمجرد فشل العقدة الحالية ، وهكذا.

نظرة فاحصة على هذا الموقف تكشف أنه عند اختيار مستودع بيانات ، نواجه مرارًا وتكرارًا معضلة "POSIX مقابل REST API" ، ولكن مع تفاقم إضافي لمشاكل POSIX الناجمة عن الطبيعة الموزعة لبيئات Kubernetes. خاصه،

POSIX : POSIX , . , . API , , S3 API, , , «» . , . .
: , , . , , ( ), , . - POSIX . , S3 API , , , .
: POSIX : . - . , API, , , ..
: , . , , , . , , , .

في حين أن واجهة تخزين بيانات الحاوية (CSI) ساعدت كثيرًا في توزيع مستوى حجم Kubernetes ، وتمريره جزئيًا إلى بائعي مستودعات بيانات الجهات الخارجية ، ولكن ساهمت أيضًا عن طريق الخطأ في الاقتناع بأن نهج الحاوية ذات الحالة هو الطريقة الموصى بها لتخزين البيانات في Kubernetes.

تم تطوير CSI كمعيار لتوفير أنظمة التخزين العشوائي للكتل والملفات للتطبيقات القديمة عند العمل مع Kubernetes. وكما هو موضح في هذه المقالة ، فإن الوضع الوحيد الذي يكون فيه نهج الحاوية ذات الحالة المناسبة (و CSI في شكله الحالي) مناسبًا هو عندما يكون التطبيق نفسه نظامًا قديمًا يستحيل فيه إضافة دعم لواجهة برمجة التطبيقات لتخزين بيانات الكائن.

من المهم أن نفهم أن استخدام CSI في شكله الحالي ، أي عند تركيب وحدات التخزين عند العمل مع التطبيقات الحديثة ، سوف نواجه نفس المشكلات تقريبًا مثل تلك التي تمت مواجهتها في الأنظمة حيث يتم تنظيم تخزين البيانات بأسلوب POSIX.

نهج أفضل

في هذه الحالة ، من المهم أن نفهم أن معظم التطبيقات لا يتم صقلها بطبيعتها خصيصًا للعمل مع أو بدون الحفاظ على الحالة. يعتمد هذا السلوك على البنية العامة للنظام وعلى الخيارات المحددة المحددة أثناء التصميم. لنتحدث قليلاً عن التطبيقات ذات الحالة.

من حيث المبدأ ، يمكن تقسيم جميع بيانات التطبيق إلى عدة أنواع واسعة:

تسجيل البيانات
بيانات الطابع الزمني
بيانات المعاملات
البيانات الوصفية
صور الحاوية
بيانات النقطة (النقط)

جميع أنواع البيانات هذه مدعومة بشكل جيد للغاية على منصات تخزين البيانات الحديثة ، وهناك العديد من الأنظمة الأساسية المستندة إلى السحابة المكيفة لتقديم البيانات في كل من هذه التنسيقات المحددة. على سبيل المثال ، قد تتواجد بيانات المعاملات والبيانات الوصفية في قاعدة بيانات حديثة قائمة على السحابة مثل CockroachDB ، YugaByte ، إلخ. يمكن تخزين صور الحاوية أو بيانات النقطة في سجل عامل الميناء بناءً على MinIO. يمكن تخزين بيانات الطابع الزمني في قاعدة بيانات سلسلة زمنية ، مثل InfluxDB ، إلخ. لن ندخل في تفاصيل كل نوع من البيانات والتطبيقات ذات الصلة ، ولكن الفكرة العامة هي تجنب التخزين المستمر للبيانات بناءً على تركيب القرص المحلي.

بالإضافة إلى ذلك ، غالبًا ما يكون من الفعال توفير طبقة تخزين مؤقت مؤقتة ، والتي تعمل كنوع من تخزين الملفات المؤقتة للتطبيقات ، ولكن لا يجب أن تعتمد التطبيقات على هذا المستوى كمصدر للحقيقة.

تخزين التطبيق الرسمي

في حين أنه من المفيد في معظم الحالات إبقاء التطبيقات بدون حالة ، فإن تلك التطبيقات المصممة لتخزين البيانات - على سبيل المثال ، قواعد البيانات ، ومخازن الكائنات ، ومخازن المفاتيح والقيمة - يجب أن تحافظ على الحالة. دعونا نرى لماذا يتم نشر هذه التطبيقات في Kubernetes. خذ MinIO كمثال ، ولكن تنطبق مبادئ مماثلة على أي أنظمة تخزين كبيرة أخرى قائمة على السحابة.

تم تصميم التطبيقات التي تتمحور حول السحابة لتعظيم استخدام المرونة المتأصلة في الحاويات. هذا يعني أنهم لا يضعون أي افتراضات حول البيئة التي سيتم نشرهم فيها. على سبيل المثال ، يستخدم MinIO آلية تشفير محو داخلية ، والتي توفر للنظام استقرارًا كافيًا حتى تظل تعمل حتى في حالة فشل نصف محركات الأقراص. يدير MinIO أيضًا سلامة البيانات وأمانها باستخدام التجزئة والتشفير الخاصين بها من جانب الخادم.

بالنسبة إلى هذه التطبيقات المستندة إلى السحابة ، تكون الأحجام الثابتة المحلية (PV) هي الأكثر ملاءمة لتخزين النسخ الاحتياطي. يوفر PV المحلي القدرة على تخزين البيانات الخام ، بينما تقوم التطبيقات التي تعمل فوق هذه PVs بجمع المعلومات بشكل مستقل لقياس البيانات وإدارة متطلبات البيانات المتزايدة.

هذا النهج أبسط بكثير وقابل للتطوير بشكل ملحوظ مقارنةً بـ PVI القائم على CSI ، والتي تجلب مستوياتها الخاصة من إدارة البيانات والتكرار إلى النظام ؛ والحقيقة هي أن هذه المستويات تتعارض عادةً مع التطبيقات المصممة وفقًا لمبدأ الحفاظ على الدولة.

حركة واثقة لفك تثبيت البيانات من الحوسبة

في هذه المقالة ، تحدثنا عن كيفية إعادة توجيه التطبيقات للعمل دون حفظ الحالة ، أو بعبارة أخرى ، يتم تحديد تخزين البيانات من الحوسبة عليها. في الختام ، نعتبر بعض الأمثلة الواقعية لمثل هذا الاتجاه.

تم استخدام Spark ، منصة تحليل البيانات الشهيرة ، تقليديًا مع النشر والنشر الرسمي لنظام الملفات HDFS. ومع ذلك ، مع انتقال Spark إلى عالم قائم على السحابة ، يتم استخدام هذه المنصة بشكل متزايد دون الحفاظ على الدولة باستخدام `s3a`. تستخدم Spark s3a لنقل الحالة إلى أنظمة أخرى ، بينما تعمل حاويات Spark نفسها تمامًا بدون الحفاظ على الحالة. الجهات الفاعلة الأخرى للمؤسسات الكبيرة في مجال تحليلات البيانات الضخمة ، على وجه الخصوص ، Vertica ، Teradata، يذهب Greenplum أيضًا للعمل مع قسم تخزين البيانات والحوسبة عليها.

يمكن أيضًا رؤية أنماط مماثلة على منصات تحليلية كبيرة أخرى ، بما في ذلك Presto و Tensorflow إلى R و Jupyter. يجعل تحميل الحالة إلى أنظمة التخزين السحابية البعيدة إدارة التطبيق وتوسيع نطاقه أسهل بكثير. بالإضافة إلى ذلك ، يساعد على نقل التطبيق إلى مجموعة متنوعة من البيئات.