Kubernetes يبلغ من العمر 10 سنوات! في منتصف عام 2024، سيحتفل العالم بالذكرى العاشرة لتأسيسه منصة تنظيم الحاويات الرائدة في السوقولكن وفقًا لمسؤول العلاقات مع المطورين في DataStax باتريك ماكفادينإن منصة تنسيق الحاويات تمر بمرحلة “المراهقة العابسة”، حيث لا تزال هناك بعض التحديات في كفاءة الإدارة التي يتعين حلها.
ويتذكر أيضًا كيف تغلبت Kubernetes، المعروفة أيضًا باسم K8s، على تحدياتها المبكرة ويعتقد أنها ستظل موجودة لبعض الوقت.
بدأت السنوات الأولى لـ Kubernetes عندما ظهرت الحاويات كطريقة جديدة لإضفاء الطابع الافتراضي على التطبيقات، ولكن مع وظيفة تخزين وحماية البيانات كان ذلك غير موجود عمليًا. الآن، تقدم Kubernetes منصة حاويات ناضجة للتطبيقات السحابية الأصلية مع كل ما هو مطلوب تخزين البيانات ذات الحالة.
نحتفل بالعقد الأول من Kubernetes بسلسلة من المقابلات مع المهندسين الذين ساعدوا في تطوير Kubernetes ومعالجة التحديات في مجال التخزين وحماية البيانات – بما في ذلك استخدام مشغلي Kubernetes – بينما نتطلع إلى مستقبل يتميز بـ الذكاء الاصطناعي أحمال العمل.
هنا، باتريك ماكفادين، نائب الرئيس للعلاقات مع المطورين في قاعدة بيانات NoSQL متخصص داتا ستاكستحدث عن كيف كان Kubernetes واحدًا من بين العديد من منظمي الحاويات، والوقت الذي أدرك فيه أن “Kubernetes فاز للتو”، والعقبات التي تحول دون التخزين الفعال، ودور StatefulSet والمشغلين الذين يوفرون الأتمتة القابلة للبرمجة للتخزين والخدمات الأخرى.
كيف كان السوق عندما تم إطلاق Kubernetes لأول مرة؟
عندما ظهر Kubernetes لأول مرة، كان هناك العديد من اللاعبين في مجال تنسيق الحاويات. كان لديك Docker Swarm وApache Mesos، الذي تم تصميمه لتشغيل أحمال عمل تحليلية كبيرة. جاء Kubernetes بدعوى واحدة للشهرة – جاء من Google. كانت قضية إدارة البنية الأساسية الكبيرة مشكلة واضحة كان الناس يحاولون حلها، لذلك كان السوق جاهزًا لحل جيد.
كيف انخرطت في العمل على البنية التحتية للبيانات حول Kubernetes؟
كان العمل على قاعدة بيانات كبيرة موزعة سبباً في وضعي في خضم التحديات التشغيلية التي تواجه المستخدمين. يمكنك إدارة عدد قليل من الخوادم دون الحاجة إلى الكثير من الأدوات، ولكن هذا الأمر يصبح غير مجدٍ عندما تجد نفسك تتوسع إلى ما يزيد عن 10 أو 100 أو 1000 عقدة. كان Mesos مناسباً لـ Apache Cassandra وكان هذا سبب بدئي العمل في هذا المشروع. كنت أعمل أيضاً على Apache Spark، الذي كان مناسباً بشكل جيد مع Mesos. في ذلك الوقت، أصبح Kubernetes معروفاً كمدير حاويات للواجهات الأمامية، لذا لم يكن له تأثير كبير في مجتمع البنية التحتية للواجهة الخلفية.
كيف أدركت أن Kubernetes يحتل المركز الرائد في السوق؟
خلال مؤتمر عقدته شركة Mesosphere في عام 2017، وهي الشركة التي قدمت نسخة مؤسسية من Mesos، أعلن الرئيس التنفيذي والمؤسس المشارك بن هندمان عن دعم Mesos لـ Kubernetes. كانت لحظة مضيئة. التفت إلى الشخص المجاور لي وقلت: “Kubernetes فاز للتو”. استغرق الأمر بعض الوقت حتى يتحقق ذلك، لكن هذه كانت إحدى نقاط التحول التي رأيتها.
عندما نظرت إلى Kubernetes، كيف تعاملت مع البيانات والتخزين؟
كانت هذه هي المشكلة الرئيسية بين Mesos وKubernetes. كان Mesos أفضل بكثير في إدارة موارد التخزين. تعامل Kubernetes مع التخزين باعتباره فكرة ثانوية في البداية، وعندما تعتمد قاعدة البيانات الخاصة بك على تخزين عالي الجودة، كان هذا مناسبًا بشكل رهيب. كان تجنب Kubernetes لأحمال عمل البيانات هو النهج الأفضل لفترة طويلة.
ما هي القضايا التي واجهتك أولاً فيما يتعلق بالبيانات والتخزين مع Kubernetes؟
التجهيز والجودة. تعامل Kubernetes في البداية مع التخزين باعتباره مؤقتًا، مما يعني أنه بمجرد إزالة الحاوية، تختفي كل مساحة التخزين لديك. وهذا ليس جيدًا لقواعد البيانات. كانت هناك بعض الحيل للحفاظ على البيانات من إعادة التشغيل إلى إعادة التشغيل، ولكن لم يتم تضمين أي منها في Kubernetes. ثم نظرًا لكونها أحجام حاويات، فقد ترك الأداء الكثير مما هو مرغوب فيه. بشكل عام، كان هناك الكثير من المشكلات التي منعت المستخدمين الجادين من القفز.
ما الذي كان يجب أن يتغير؟
كان تغيير طريقة معالجة التخزين هو أول أمر يجب القيام به. قدم Kubernetes مجموعة StatefulSet التي غيرت تمامًا كيفية تجهيز التخزين. لقد قامت بنمذجة ما هو مطلوب لخادم حالة مثل قاعدة البيانات. كان التغيير الكبير التالي هو إضافة المشغلين. نظرًا لأن الخوادم كانت تُضاف إلى نظام يتحكم في التجهيز، فقد كان من الضروري وجود طريقة لترجمة الأوامر مثل “start” و”stop”. أنشأ المشغلون طبقة الترجمة بين Kubernetes والخدمات الراسخة التي تم جلبها.
كيف انضممت إلى مشغلي Kubernetes؟
لقد بذل مجتمع البيانات على Kubernetes الكثير من العمل لجعل هذا المفهوم مفهومًا يرغب الناس في تبنيه. عندما بدأنا، تلقينا تعليقات تقول، “ضع بياناتي على Kubernetes؟ هل أنت غاضب؟” لكننا رأينا أيضًا الكثير من المطورين يقولون، “أريد كل شيء في مكان واحد، لذا اجعله يعمل”. بمرور الوقت، نجح هذا الجهد المجتمعي. أعتقد أن عام 2022 كان نقطة التحول حيث رأينا المزيد من الأشخاص على استعداد لتشغيل بياناتهم على Kubernetes. كان ذلك قائمًا على الجهود المبذولة لإنشاء مشغلين ذوي جودة.
ما الذي حدث حول المشغلين مما جعلهم ناجحين في مجال البيانات والتخزين؟
حلت المشغلات مشكلة ضخمة وكان من السهل تجميعها. قام العديد من الأشخاص بتجميع مشغلاتهم الخاصة – كان الأمر أشبه بظهور مشغل آخر للمشاريع كل عطلة نهاية أسبوع. كان هذا رائعًا، لكنه يعني أنك واجهت الكثير من التكسير مع المشاريع المهجورة التي قامت بالأساسيات، ولكن بدون تعاون. أراد الجميع أن يكونوا الشخص الذي يجمع المشغل معًا، لذلك انتهى بك الأمر مع الكثير من المشاريع التي فعلت الشيء نفسه بطرق مختلفة قليلاً.
لقد رأينا هذا في مجتمع Apache Cassandra. أعتقد أنه كان هناك حوالي 12 مشغلًا مختلفًا في وقت واحد في مرحلة ما وكانوا جميعًا جيدين في أشياء محددة. لكننا لم نستفد من التعاون مع بعضنا البعض وتحسين الأشياء. استغرق الأمر بعض الوقت حتى يجتمع المجتمع ويتفق على ما نريده وما نريد العمل عليه وكيفية القيام بذلك معًا. ولكن عندما بدأ ذلك، أعتقد أنه أحدث فرقًا كبيرًا.
كيف ساعد هذا في دعم المزيد من الأساليب السحابية الأصلية؟ وما هي العواقب؟
أعتقد أن هذا ساعد في النهج العام لتطبيقات السحابة الأصلية لأنك تستطيع تشغيل تطبيقاتك والبنية الأساسية الخاصة بك في نفس المكان وإدارة كل شيء باستمرار. عندما يكون لديك خدمات صغيرة وحاويات، فأنت تريد أن تكون قادرًا على التوسع وتريد أن تكون قادرًا على نقل الأشياء عندما تحتاج إليها بدلاً من أن تكون مرتبطًا بما لديك. عندما يمكنك القيام بذلك لقاعدة البيانات الخاصة بك أيضًا، فقد جعل الأمر أكثر بساطة. وعندما يمكنك البدء بالاختبار، فقد أصبح من الأسهل إثبات نجاح ذلك ويمكنك الانتقال إلى الإنتاج. إنها الحجة بأكملها حول جاذبية البيانات. لقد رأينا البيانات تنتقل إلى التخزين حول المحاكاة الافتراضية، ورأينا المزيد من البيانات تنتقل إلى السحابة جنبًا إلى جنب مع التطبيقات، لذلك من الطبيعي أن ترى ذلك يحدث مع السحابة الأصلية والحاويات أيضًا.
قامت DataStax ببناء Cassandra كخدمة، Astra DB، على Kubernetes. أعتقد أن هذا هو أقوى تأييد يمكنني تقديمه
باتريك ماكفادين، داتا ستاكس
Kubernetes أصبح الآن في عامه العاشر. ما رأيك فيه اليوم؟
أعتقد أن العديد من الأشخاص يعتقدون أن Kubernetes قد انتهى وأن الأمور ستستمر في النمو. لا أرى ذلك. أعتقد أننا في مرحلة المراهقة المتقلبة، ولا يزال هناك العديد من الأشياء التي تحتاج إلى العمل عليها. لكنه نظام مستقر يمكنك الاعتماد عليه. لقد بنت DataStax خدمة Cassandra الخاصة بها، Astra DB، على Kubernetes. أعتقد أن هذا هو أقوى تأييد يمكنني تقديمه.
ما هي المشاكل التي لا تزال قائمة حول Kubernetes عندما يتعلق الأمر بالبيانات والتخزين؟
إن نضج المشروع سوف يكون في الكفاءة. لا يزال الأمر يتطلب الكثير من الجهد اليدوي لتشغيل نشر Kubernetes بسلاسة. إن التوسع أمر سهل، ولكن التقليص أمر صعب، لدرجة أنه نادرًا ما يتم القيام به. GenAI [generative artificial intelligence] لا شك أن الفكرة ستظهر هنا كفكرة عمليات الذكاء الاصطناعي [artificial intelligence for IT operations] إن شرح ما تريده من وجهة نظر التطبيق ورؤية البنية الأساسية الناشئة قد يبدو وكأنه سحر، ولكن في الحقيقة هذا مجرد تقدم.
