Kubernetes يبلغ من العمر 10 سنوات! في منتصف عام 2024، سيحتفل العالم بالذكرى العاشرة لتأسيسه منصة تنظيم الحاويات الرائدة في السوقولكن، كما يقول سيرجي برونين، مدير مجموعة المنتجات في شركة Percona، التي تقوم بتطوير منتجات مفتوحة المصدر لقواعد بيانات SQL وNoSQL، لم تكن الشركة دائمًا في هذا الوضع.
يتذكر برونين السنوات الأولى عندما وصل Kubernetes إلى السوق، وكان محصورًا إلى حد كبير في تنظيم التطبيقات عديمة الجنسية، مع وظيفة تخزين وحماية البيانات وهذا كان غير موجود عمليا.
كان هو أيضًا من دعاة “Kubernetes للأشخاص عديمي الجنسية”. ولكن بمرور الوقت، ومع إضافة وظائف الخدمات ذات الحالة عبر مشغلي Kubernetes وStatefulSet، أصبحت منصة التنسيق هي الخيار الأمثل للمطورين الذين يريدون منصة حاويات ناضجة للتطبيقات السحابية الأصلية مع كل ما هو مطلوب تخزين البيانات ذات الحالة.
نحتفل بالعقد الأول من Kubernetes بسلسلة من المقابلات مع المهندسين الذين ساعدوا في تطوير Kubernetes ومعالجة التحديات في مجال التخزين وحماية البيانات – بما في ذلك استخدام مشغلي Kubernetes – ونحن نتطلع إلى مستقبل يتميز بـ الذكاء الاصطناعي أحمال العمل.
كيف كان السوق عندما تم إطلاق Kubernetes لأول مرة؟
سيرجي برونين:نظرًا لأن المؤسسات اعتمدت بشكل متزايد على بنية الخدمات المصغرة، فقد كانت هناك حاجة لإدارة وتوسيع نطاق أعداد كبيرة من الحاويات بكفاءة. تم تنفيذ عمليات نشر الحاويات وتوسيع نطاقها يدويًا، وهو ما كان عرضة للخطأ ويستغرق وقتًا طويلاً، لذلك كان هناك طلب على أدوات التنسيق الآلية.
في عام 2014، دخلت Kubernetes سوق تنسيق الحاويات الذي كان مليئًا بالإمكانات ولكنه يفتقر إلى قائد واضح. أشعلت Docker ثورة الحاويات، لكن إدارة الحاويات على نطاق واسعظلت هذه المشكلة لغزًا معقدًا. كانت هناك خيارات مثل Apache Mesos، لكنها كانت غالبًا غير قابلة للإدارة وتتطلب معرفة متخصصة.
كيف انخرطت في العمل على البنية التحتية للبيانات حول Kubernetes؟
برونين:في ذلك الوقت، كنت أقود فرقًا هندسية متعددة تعمل على بناء حلول مختلفة لمنصة كخدمة. يرغب المطورون دائمًا في إزالة العناء من خلال الأتمتة، وكان تبسيط التنسيق شيئًا أراده الجميع. لم يكن Kubernetes متطورًا كما هو عليه اليوم، لكنه كان يكتسب زخمًا ببطء في المجتمع.
يفتح الفضول الكثير من الأبواب، وقد رأيت Kubernetes خلف أحدها. وبمجرد أن نظرت إلى ما ينطوي عليه الأمر، اعتقدت أنه مشروع يجب أن أتابعه. ولم أكن أعلم إلى أي مدى سيكون جزءًا من حياتي المهنية في المستقبل.
كيف أدركت أن Kubernetes يحتل مكانة رائدة في السوق؟
برونين:لم يكن إدراكي لهذا الأمر مفاجئًا. بل حدث ببطء. فقد كانت الحلول مثل Apache Mesos وDocker Swarm وحتى AWS ECS (خدمة الحاويات المرنة) مستخدمة على نطاق واسع. والسبب وراء فوز Kubernetes هو المجتمع. فقد أدى بنيته القابلة للتوصيل والتطور السريع إلى تبنيه وأكل حصة السوق من الحلول الأخرى ببطء.
عندما نظرت إلى Kubernetes، كيف تعاملت مع البيانات؟
برونين:لفترة طويلة بالنسبة لي، كان Kubernetes مخصصًا فقط للتطبيقات عديمة الجنسية. حتى أننا وضعنا قيودًا صارمة للغاية على الجودة على أنظمتنا حيث لم نسمح بالتطبيقات عديمة الجنسية في Kubernetes. كان هذا تطبيق 12 عامل إن التفكير في أفضل السبل لتصميم وبناء تطبيقات سحابية قابلة للتطوير ومرنة. ومن بين المبادئ الأساسية التعامل مع الخدمات الخلفية، بما في ذلك قواعد البيانات، كموارد مرفقة، لتعزيز تصميم التطبيقات عديمة الجنسية.
ما هي القضايا التي واجهتك أولاً فيما يتعلق بالبيانات والتخزين مع Kubernetes؟
برونين:كانت المشكلة الأكبر هي عدم النضج. كان توفير وحدات تخزين ثابتة أشبه بالمعرفة المقدسة، التي لا يعرفها إلا القليلون، ولم تكن آلية بالكامل ومتاحة من خلال بعض عمليات الاختراق الأساسية. وكان التكامل مع موفري التخزين غير موجود، مما يعني أن تجربة المستخدم كانت مربكة للغاية.
ثم في عام 2019، بدأت AWS EKS (خدمة Kubernetes المرنة) رسميًا في دعم AWS EBS (تخزين الكتل المرنة). ربما كان هذا هو الإنجاز الذي بدأ في تغيير المفاهيم.
ما الذي كان يجب أن يتغير؟
برونين:تم إصدار Stateful Sets and Operators بعد ثلاثة أعوام من الإصدار الأول، لذا فقد استغرق الأمر بعض الوقت حتى أصبح جاهزًا للاستخدام مع Kubernetes. وبمجرد إصدارهما، استغرق الأمر بعض الوقت للتغلب على التحفظات بشأن نشرهما. وكان هناك حاجة إلى الكثير من الاختبارات للتغلب على هذه العقبة قبل أن نكون مستعدين لتغيير سياساتنا.
كيف انضممت إلى مشغلي Kubernetes؟
برونين:انضممت إلى Percona منذ 3.5 سنوات لقيادة فريق إدارة المنتجات المسؤول عن المشغلين ونشر التطبيقات السحابية الأصلية. كان الأمر في ذلك الوقت بمثابة حقل أخضر كامل، مع الكثير من عدم اليقين ومجتمع صغير نسبيًا. كنت مؤمنًا بشدة بـ “Kubernetes للأشخاص عديمي الجنسية” لذا كان استيعاب الفكرة تحديًا كبيرًا. رأى فريق قيادة Percona فرصة وأحس باتجاه السوق قبل فترة طويلة من أن يصبح سائدًا.
ما الذي حدث حول المشغلين مما جعلهم ناجحين في مجال البيانات والتخزين؟
برونين:إنه مزيج من الأحداث.
في عصر الخدمات المصغرة، حاول المستخدمون تشغيل قواعد البيانات في حاويات Docker، خارج Kubernetes. هذه مهمة معقدة، خاصة إذا كان هناك تجميع في عمليات النشر، وهو ما قد تحتاجه لقواعد البيانات.
كان Kubernetes يتحول إلى معيار فعلي لتشغيل الخدمات المصغرة وبناء المنصات. وقد تم وصفه بأنه “منصة لبناء المنصات” وأعتقد أن هذا التعريف دقيق الآن.
وعدت Kubernetes بحل بعض مشكلات التعقيد، لكن إدارة قواعد البيانات صعبة. إن تعلم كل أساسيات Kubernetes وفهم المفاهيم أمر شاق. لقد نجح المشغلون في تلخيص كل هذا التعقيد وخفضوا حاجز الدخول بشكل كبير.
لم يقتصر الأمر على ذلك، فقد حل المشغلون مشكلة عمليات اليوم الثاني. وهذا هو مصدر معظم تعقيدات قاعدة البيانات – مهام مثل الصيانة المستمرة والترقيات والنسخ الاحتياطي والاستعادة والأمان وما إلى ذلك. يمكن أن يساعدك Kubernetes في تحسين سرعة تنفيذ البنية الأساسية، لكنه لا يستطيع تنفيذ استعلام قاعدة البيانات نيابة عنك.
كيف ساعد هذا في دعم المزيد من الأساليب السحابية الأصلية؟ وما هي العواقب؟
برونين:أعطى المشغلون – وخاصة لقواعد البيانات – دفعة إضافية لـ Kubernetes و النظام البيئي CNCF وجعلت من الأسهل اعتماد خيارات المصدر المفتوح تلك.
كان تقييد الموردين مشكلة في السحابة العامة، بينما وفرت Kubernetes طريقة لتشغيل التطبيقات في أي مكان باستخدام واجهة برمجة تطبيقات موحدة. وقد أثبتت Kubernetes أنها يمكن أن تعمل بشكل مثالي للتطبيقات عديمة الجنسية ومع المشغلين، وبالتالي حصلت قواعد البيانات أيضًا على فرصة للعمل بنفس الطريقة.
Kubernetes أصبح الآن في عامه العاشر. ما رأيك فيه اليوم؟
برونين:على مدار السنوات العشر الماضية، أصبح Kubernetes هو المعيار الصناعي وأحدث تغييرًا جذريًا في كيفية تطوير التطبيقات ونشرها. ولا يمكن إنكار تأثيره. فقد عزز الابتكار ودفع صعود بنية الخدمات المصغرة.
في حين لا تزال التحديات مثل التعقيد والأمان قائمة، فإن مستقبل Kubernetes مشرق. فالمجتمع المتنامي وكل الابتكارات الجارية ستضمن استمراره في التكيف مع الاتجاهات الجديدة.
ما هي المشاكل التي لا تزال قائمة حول Kubernetes عندما يتعلق الأمر بالبيانات والتخزين؟
برونين:لا يزال التعقيد يمثل مشكلة، حتى مع قيام المشغلين بتسهيل إدارة البيانات وموارد التخزين. ويرجع ذلك في الغالب إلى الافتقار إلى التوحيد القياسي عبر واجهات تخزين الحاويات المختلفة (CSIs) وتعقيدات التكامل مع موفري التخزين المختلفين.
قد يكون إدارة البيانات والتخزين عبر عدة سحابات أو بيئات هجينة أمرًا صعبًا بسبب الاختلافات في واجهات برمجة تطبيقات التخزين والتكوينات. هناك محاولات مختلفة لتبسيط ذلك من خلال مستويات التحكم في الاتحاد أو المجموعات المتعددة.
تم تصميم محركات قواعد البيانات مثل MySQL أو PostgreSQL قبل فترة طويلة من ظهور الخدمات المصغرة. وقد قام المهندسون بتكييفها للعمل على Kubernetes، ولكن الأمر يتطلب أحيانًا حلولًا بديلة لجعلها تعمل.
هل لديك أي حكايات أو معلومات أخرى تود مشاركتها؟
برونين:لقد انتقل المشغلون وقواعد البيانات على Kubernetes بسرعة من الاختراقات البسيطة لجعل الأشياء تعمل إلى أن تكون على مستوى المؤسسة. والآن أصبح الأمر يتعلق بـ “الكيفية” وليس “السبب” من قبل المنظمات على مستويات مختلفة. لم تعد البيانات على Kubernetes “للشجعان فقط”. لقد أصبحت سائدة.
