متى ولماذا وكيف يتم تشغيل قواعد البيانات في Kubernetes

“هل يجب تشغيل قاعدة البيانات الخاصة بي في Kubernetes؟” إنه سؤال بسيط بدون إجابة بسيطة لأن الإجابة الصادقة هي: “الأمر يعتمد”.

وبينما قد تكون هناك فوائد كبيرة، هناك أيضًا مقايضات. لكن أي قرار يتوقف على ما هو مناسب لحالة الاستخدام الخاصة بك.

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

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

لكن الأمور تصبح أكثر تعقيدًا عندما نفكر في البيانات ونظام Kubernetes البيئي. تتطلب التطبيقات ذات الحالة بنية قاعدة بيانات جديدة تأخذ في الاعتبار النطاق ووقت الاستجابة والتوافر واحتياجات الأمان للتطبيقات.

كيف تعرف بنية قاعدة البيانات الأفضل تجهيزًا للتعامل مع هذه التحديات؟

في هذه المقالة، سنناقش الفوائد والمفاضلات المحتملة لتشغيل قاعدة بيانات في Kubernetes واستكشاف عدد هذه المفاضلات التي يمكن تخفيفها. لنبدأ بالمزايا:

استخدام أفضل للموارد

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

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

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

تحجيم ديناميكي ومرن لموارد الكبسولات

يتمتع Kubernetes بقدرة فريدة على تعديل الذاكرة ووحدة المعالجة المركزية والقرص لتوسيع نطاق قواعد البيانات بناءً على متطلبات عبء العمل.

إن القدرة على التوسع تلقائيًا دون تكبد فترات توقف لا تقدر بثمن بالنسبة للمؤسسات الكبيرة التي تشهد ارتفاعًا في الطلب بشكل منتظم.

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

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

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

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

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

تنسيق البنية التحتية خارج الصندوق

في Kubernetes، يمكن بدء تشغيل pods في أي مكان نظرًا لقدرة النظام الأساسي على نقل أعباء العمل من الكبسولة إلى العقد والعكس بالعكس.

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

هذه مشكلة أكبر لقواعد البيانات عند التعامل مع أعباء العمل ذات الحالة، لأنها تتطلب إعداد سياسات محددة في Kubernetes.

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

عمليات اليوم الثاني المؤتمتة

تعتبر عمليات النسخ الاحتياطي الدورية وترقيات البرامج أمرًا بالغ الأهمية، ولكنها تستغرق أيضًا وقتًا طويلاً. لحسن الحظ، تعمل Kubernetes على أتمتة معظم عمليات اليوم الثاني.

والأفضل من ذلك، يعد إجراء هذه التحديثات عبر مجموعة أمرًا سهلاً. لذلك، على سبيل المثال، إذا كنت ترغب في تصحيح ثغرة أمنية عبر مجموعة، فإن Kubernetes يجعل ذلك أمرًا سهلاً.

من المهم أن نلاحظ، مع ذلك، أن عمليات اليوم الثاني الآلية يمكن أن تكون معقدة بالنسبة لنظام إدارة قواعد البيانات العلائقية التقليدية (RDBMS).

عند استخدام نظام RDBMS تقليدي مع Kubernetes، عادة ما يكون لديك نسخ متعددة من البيانات، لذلك عندما تفقد الكبسولة، هناك نسخة أخرى في مكان آخر.

هذا يعني أن المستخدم لا يزال مسؤولاً عن ترحيل البيانات بين البودات وإعادة المزامنة.

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

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

المقايضات المهمة وكيفية التخفيف منها

لجميع مزايا تشغيل قواعد البيانات في Kubernetes، هناك مفاضلات يجب وضعها في الاعتبار. بالنسبة للمبتدئين، هناك احتمال متزايد لحدوث أعطال في البودات.

قد تتعطل السنفات بسبب تقارب العملية، وإذا تعطلت العملية التي تبدأ الكبسولة، فقد تختفي الكبسولة بأكملها.

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

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

يجب أن تفهم المنظمات أيضًا التعقيدات المحتملة التي تأتي من قيود الشبكات في مجموعات Kubernetes.

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

أخيرًا، يجب على المرء أن يراقب “المشاكل” التشغيلية نظرًا لأن بناء خبرة Kubernetes الداخلية يستغرق وقتًا. لتحقيق أقصى استفادة من عمليات نشر قاعدة البيانات، ستحتاج المؤسسات إلى: