Kubernetes يبلغ من العمر 10 سنوات! في منتصف عام 2024، سيحتفل العالم بالذكرى العاشرة لتأسيسه منصة تنظيم الحاويات الرائدة في السوق.
كان جان سافرانك، كبير مهندسي البرمجيات في شركة Red Hat، حاضرًا أثناء موجة النشاط التي شهدت ظهور Docker ثم Kubernetes على الساحة والشركات والمطورين الذين يتصارعون مع كيفية توفير التخزين الدائم لها.
كان Safranek موجودًا عندما ظهرت Pets Sets وStatefulSets وساعد في معالجة هذه المشكلة من خلال إدارة نشر وتوسيع حاويات الحاويات. ثم شارك Safranek في تطوير برامج تشغيل CSI (واجهة تخزين الحاويات) والمشغلين الذين قدموا ملحقات البرامج لإدارة التطبيقات ومكوناتها.
نحتفل بالعقد الأول من Kubernetes بسلسلة من المقابلات مع المهندسين الذين ساعدوا في تطوير Kubernetes ومعالجة التحديات في تخزين وحماية البيانات – بما في ذلك استخدام مشغلي Kubernetes – ونحن نتطلع إلى مستقبل يتميز بـ الذكاء الاصطناعي أحمال العمل.
كيف كان السوق عندما تم إطلاق Kubernetes لأول مرة؟
يان سافرانيك:كان العالم يهيمن عليه المعدن العاري أو الآلات الافتراضية الثقيلة. اكتسبت حاويات Docker شعبية كبيرة بسرعة كبيرة، لكن لم يكن أحد يعرف كيفية إدارتها بسبب عدم وجود أدوات متاحة. جلب Kubernetes مفهومًا جديدًا تمامًا لتشغيل التطبيقات في أجزاء خفيفة الوزن ومعزولة.
كيف انخرطت في العمل على البنية التحتية للبيانات حول Kubernetes؟
سفرانيك:كان الأمر سهلاً بالنسبة لي. كنت أعمل على أدوات إدارة تخزين Linux هنا في Red Hat ورأيت فريقًا جديدًا يتم إنشاؤه للمساعدة في Kubernetes. لم أكن أعرف أي شيء عن ذلك، لكنه بدا رائعًا لذا تقدمت بطلب هناك.
كيف أدركت أن Kubernetes يحتل مكانة رائدة في السوق؟
سفرانيك:لقد كان ذلك في مؤتمر KubeCon الأول الذي حضرته في سياتل عام 2016. وقبل ذلك، التقيت بزملاء مهندسين كانوا يقومون بأشياء مثيرة للاهتمام. ولكن هناك التقيت بشركات حقيقية تدير أجزاء مهمة من أعمالها. البنية التحتية على Kubernetes.
عندما نظرت إلى Kubernetes، كيف تعاملت مع البيانات والتخزين؟
سفرانيك:عندما انضممت إلى Kubernetes، أدرك الناس بالفعل أنه حتى عندما تكون الحاويات مؤقتة بطبيعتها، يجب أن يكون هناك شيء دائم في الصورة الأكبر. واجهات برمجة التطبيقات الأساسية [application programming interfaces] كانت هناك بالفعل، حتى مع مكونات إضافية للحجم الأول، لكن لم يكن أحد يعرف حقًا كيفية استخدامها. ظهرت PetSets، ثم تغيرت لاحقًا إلى StatefulSets، ولكن حتى مع ذلك، لا يزال من الصعب تشغيل تطبيقات تعتمد على البيانات الثقيلة على Kubernetes.
ما هي القضايا التي واجهتك أولاً فيما يتعلق بالبيانات والتخزين مع Kubernetes؟
سفرانيك:بدأت في البحث عن ما هو موجود بالفعل في Kubernetes وكيفية استخدامه. أضفت بعض الأمثلة والاختبارات الشاملة للتعرف على الكود والعملية الإجمالية. كان الأمر سهلاً للغاية في ذلك الوقت. أتذكر أنه كان يتقدم بسرعة كبيرة لدرجة أنه كان من الصعب جدًا تحديث طلبات السحب الخاصة بي.
كانت أولى المشكلات الحقيقية التي كان علينا حلها هي كيفية تشغيل تطبيق بحالة، والذي تم حله بواسطة PetSets/StatefulSets، وكيفية استهلاك البيانات من أنظمة التخزين خارج Kubernetes. بدأنا أولاً بالكود داخل الشجرة للتخزين السحابي وعدد قليل من المكونات الإضافية العامة للتخزين التقليدي مثل NFS وiSCSI.
ما الذي كان يجب أن يتغير؟
سفرانيك:مع زيادة الاعتماد، أدركنا بسرعة أننا بحاجة إلى كود أكثر قوة. كانت وحدات التحكم الأولية لدينا هشة للغاية، لذا كان علينا إعادة كتابة كل شيء لتوفير سلوك مستقر ومتسق. ومع ذلك، لا يزال هناك مجال للتحسينات، حيث نجت جميعها لسنوات مع إصلاحات طفيفة للأخطاء فقط.
بالإضافة إلى ذلك، مع رغبة المزيد والمزيد من بائعي التخزين في دمج واجهات التخزين الخلفية الخاصة بهم مع Kubernetes، علمنا أننا بحاجة إلى واجهة تمديد عامة لمكونات وحدة التخزين. أولاً، توصلنا إلى FlexVolumes، والتي كانت مرهقة للغاية في الاستخدام، لكننا تعلمنا وأنشأنا CSI، وهي واجهة التخزين الرئيسية لـ Kubernetes اليوم. لقد حققت نجاحًا هائلاً، وهناك ما لا يقل عن 130 برنامج تشغيل لقد قاموا بإدراج أنفسهم طواعية ومن يدري كم عدد الأشياء الأخرى التي لا نعرف عنها شيئًا.
ومع تبني Kubernetes وبدء تشغيل البنية الأساسية الحيوية، كان علينا التأكد من عدم إتلافها. والآن أصبح من الصعب للغاية تقديم ميزة جديدة أو تغيير ميزة موجودة، حيث توجد مراجعات وموافقات لا حصر لها مطلوبة لضمان استقرار إصداراتنا.
كيف انضممت إلى مشغلي Kubernetes؟
سفرانيك:كانت شركة Red Hat من أوائل الشركات التي تبنت Operators. وكانت البدايات مفعمة بالحيوية. لقد بدأت شخصيًا ببعض Operators السيئة، ولكن سرعان ما تعلمت كيفية كتابة Operators جيدة. كل هذا يأتي بالممارسة، كما هو الحال مع أي شيء في تطوير البرمجيات. كما أن هناك اليوم المزيد من الوثائق أكثر من أي وقت مضى.
ما الذي حدث حول المشغلين مما جعلهم ناجحين في مجال البيانات والتخزين؟
سفرانيك:لدي خبرة مختلطة هنا. العديد من المشغلين ليسوا أفضل من مخططات Helm [which describe a related set of Kubernetes resources]ومع ذلك، ساعدت التطبيقات الجيدة الشركات على تخفيف معاناتها مع التطبيقات التي تحتاج إلى بيانات مستمرة. لا يزال من الصعب تشغيل تطبيق بحالة صحيحة، مع تغطية جميع الحالات الخاصة.
كيف ساعد هذا في دعم المزيد من الأساليب السحابية الأصلية؟ وما هي العواقب؟
سفرانيك:كما ذكرت، من الأسهل بالنسبة لمطوري عمليات التطوير الاعتماد على مشغل تابع لجهة خارجية لتشغيل قاعدة البيانات الخاصة بهم أو أي عبء عمل آخر ذي حالة بينما يركزون على تجميع هذه الأجزاء في تطبيق رائع يدير أعمالهم.
Kubernetes أصبح الآن في عامه العاشر. ما رأيك فيه اليوم؟
سفرانيك:حسنًا، لقد كانت رحلة شاقة. من البداية حيث كان بإمكان أي شخص إعادة كتابة أي شيء وتحويله إلى برنامج ثابت للغاية يحافظ على استمرار هذا العالم أو على الأقل بعض الأجزاء المهمة جدًا منه إلى حيث تحول إلى جزء ممل من البنية الأساسية.
ما هي المشاكل التي لا تزال قائمة حول Kubernetes عندما يتعلق الأمر بالبيانات والتخزين؟
سفرانيك:جميع الحاويات مؤقتة بطبيعتها وقد تكون قصيرة العمر. يمكن لـ Kubernetes محاولة تشغيلها لفترة طويلة، ولكن عندما يحتاج إلى حذفها، فسوف يفعل ذلك. تقدم Kubernetes بعض واجهات برمجة التطبيقات، مثل PodDisruptionBudget، للحفاظ على العدد الضروري المطلق من الحاويات قيد التشغيل، ولكن يجب أن تعتمد جميع التطبيقات ذات الحالة على بعض الانقطاع. هذا مفهوم جديد ولا يزال من الصعب التعامل معه بشكل صحيح.
هل لديك أي حكايات أو معلومات أخرى تود مشاركتها؟
سفرانيك:أفضل شيء في العمل على Kubernetes هو أنني قابلت أشخاصًا أذكياء للغاية، وتعلمت الكثير، وما زلت أتعلم.
