لقد بدأ العقد مع ظهور الحاويات كوسيلة جديدة للتطبيقات الافتراضية ولكن التخزين وحماية البيانات لم تكن موجودة عمليًا. الآن، يقدم Kubernetes منصة حاوية ناضجة للتطبيقات السحابية الأصلية مع جميع الوظائف المطلوبة لـ تخزين البيانات ذات الحالة.
نحتفل بالعقد الأول من Kubernetes من خلال سلسلة من المقابلات مع المهندسين الذين ساعدوا في تطوير Kubernetes ومعالجة التحديات في التخزين وحماية البيانات – بما في ذلك استخدام مشغلي Kubernetes – بينما نتطلع إلى مستقبل يتميز بـ الذكاء الاصطناعي (AI) أعباء العمل.
هنا، يتحدث سعد علي، كبير مهندسي البرمجيات في شركة Google – التي صممت Kubernetes – عن تحديات التخزين المبكرة وحماية البيانات، ومشاركته في واجهة تخزين الحاويات (CSI) برامج التشغيل، وحل معضلة التخزين ذي الحالة الخاصة لبيئة مرنة ومحمولة، وكيف حقق مشغلو Kubernetes قفزة هائلة إلى الأمام في كسر هذا المأزق.
كيف كان شكل السوق عند إطلاق Kubernetes لأول مرة؟
سعد علي: عندما تم إطلاق Kubernetes لأول مرة، كان المطورون والبائعين مهتمين جدًا به حاويات ولكن لم يكن لديه أي فكرة من أين تبدأ. عامل ميناء لقد ساهمت في تنشيط الصناعة وجعل التطوير أسهل، وكان هناك اهتمام كبير بمعرفة كيفية جعلها مفيدة لعمليات النشر على نطاق واسع.
كان العديد من بائعي وحدات التخزين ينتظرون على الخطوط الجانبية محاولين تحديد مكان الاستثمار. قفز عدد قليل في وقت مبكر وكتبوا النص الأصلي المكونات الإضافية لحجم الشجرة بالنسبة لـ Kubernetes، والتي كانت عملية شاقة تتطلب التحقق من التعليمات البرمجية مباشرة في مستودع Kubernetes الأساسي. مع كل حالة عدم اليقين، اتخذ معظم بائعي وحدات التخزين نهج الانتظار والترقب. إذا لم نتجاوز هذا التردد أبدًا، فلن يكون نظام Kubernetes على ما هو عليه اليوم.
كيف شاركت في التخزين لـ Kubernetes؟
علي: لقد انخرطت في جانب التخزين في Kubernetes من خلال إصلاح مجموعة من المشكلات المتعلقة بالتخزين. في نهاية المطاف، تم تكليفي بإصلاح شروط السباق التي كانت موجودة منذ 1.0 في مكدس التخزين. انتهى بي الأمر بالدفع إعادة هندسة كبيرة من مكدس دورة حياة الحجم إلى Kubernetes 1.3، بما في ذلك استخراج منطق الإرفاق/الفصل من kubelet ونقله إلى وحدة تحكم مركزية لتقليل ظروف السباق. وقد ساعد ذلك، إلى جانب العديد من الإصلاحات الإضافية التي أجراها العديد من المطورين عبر العديد من الإصدارات اللاحقة، على تحسين استقرار النظام الفرعي للحجم الإجمالي.
لقد أصبحت Kubernetes SIG [Special Interest Group] شارك في قيادة وحدة التخزين، وكان أحد مجالات التركيز الرئيسية خلال السنوات اللاحقة هو اكتشاف كيفية جعل تخزين Kubernetes أكثر قابلية للتوسيع. لقد ساعدت في بدء وتطوير واجهة تخزين الحاويات.
متى أدركت أن Kubernetes كان في موقع الريادة في السوق؟
علي: بالنسبة لـ Kubernetes بشكل عام، أتذكر أنني سمعت ذلك بوكيمون جو كان يعمل على رأس Kubernetes. لقد كانت تلك لحظة مذهلة وإدراكًا لنجاح نظام Kubernetes.
جعلت CSI بائعي وحدات التخزين مريحين بما يكفي للاستثمار في بناء المكونات الإضافية، وأدت إلى دورة حميدة – المزيد من البائعين الذين قاموا بتطوير Kubernetes جعل Kubernetes أكثر فائدة، وزاد اعتماد Kubernetes وأدى إلى تطوير المزيد من البائعين له
سعد علي، جوجل
ل تخزين كوبيرنيت، عندما بدأنا في تطوير CSI لأول مرة، ذهبت إلى اجتماع في سان فرانسيسكو للحديث عنه وسأل أحد الجمهور: “ما الذي يجعل هذا الجهد مختلفًا عن العديد من الجهود السابقة لتوحيد التخزين الذي جربه مجتمع OpenStack؟ ما الذي يجعلك تعتقد أن هذه المرة ستكون مختلفة؟ “
كان ذلك بمثابة تذكير بأن النجاح غير مضمون، لذلك بذلنا جهدًا نشطًا مع CSI للعمل بشكل وثيق مع مجتمع التخزين ومنسقي الحاويات المتعددين، وبناء التكرار بشكل منهجي ومستمر على CSI، ولم نطلق عليه 1.0 حتى أصبح لدينا العديد من برامج التشغيل العاملة /تكاملات.
وهذا جعل بائعي وحدات التخزين مرتاحين بما يكفي للاستثمار في بناء المكونات الإضافية، وأدى إلى دورة حميدة – حيث أدى المزيد من البائعين الذين قاموا بتطوير Kubernetes إلى جعل Kubernetes أكثر فائدة، وزيادة اعتماد Kubernetes، وأدى إلى تطوير المزيد من البائعين له. وكان عندما قائمة برامج تشغيل CSI لقد تجاوز عدد السائقين 100 سائق وأدركت أننا حققنا شيئًا مميزًا.
عندما نظرت إلى Kubernetes، كيف تعاملت مع البيانات والتخزين؟
علي: بعيدًا عن قابلية توسيع منصة Kubernetes (مع عمليات تكامل مثل CSI)، في رأيي، يكمن سحر تخزين Kubernetes في أنه يفصل تخزين الكتل/الملفات عن الحوسبة – “فصل الاهتمامات” – ويجعل أعباء العمل ذات الحالة مرنة مثل أعباء العمل غير ذات الحالة أعباء العمل. عندما لم تعد هناك حاجة إلى ربط أحمال العمل ذات الحالة بالعقدة التي تم توفيرها لها، أصبح من الأسهل الإصلاح الذاتي دون تدخل بشري.
حتى Kubernetes 1.0 تضمن نظامًا أساسيًا “مكونًا إضافيًا لوحدة التخزين” يسمح لـ Kubernetes بإرفاق/تنسيق/تركيب وحدات تخزين كتلة/ملفات عشوائية تلقائيًا على القرون وإلغاء تحميلها/فصلها أثناء تحرك القرون عبر العقد. وكان هذا أمرًا بالغ الأهمية في تمكين مرونة الجدولة لأحمال العمل ذات الحالة. حتى عندما يحدث خطأ ما في عقدة حسابية، يمكن إتاحة بياناتك تلقائيًا على عقدة أخرى دون تدخل بشري.
ما هي المشكلات التي ظهرت لأول مرة فيما يتعلق بالبيانات والتخزين في Kubernetes؟
علي: إن المكدس الفرعي للتخزين Kubernetes معقد بشكل لا يصدق. لقد تعاملنا في الأصل مع الكثير من ظروف السباق. أحد أكبر التحديات التي تواجه مكدس التخزين هو أنه يتعين عليه التعامل مع أسوأ حالة مفاضلة بين الاسترداد التلقائي واحتمال فقدان البيانات والفساد. ولا تعد أي من النتائج مقبولة، لذلك بذلت Kubernetes SIG Storage جهدًا لا يصدق لتحديد وضمان التعافي السلس من حالات التخزين المؤقت هذه.
يكمن سحر تخزين Kubernetes في أنه يفصل تخزين الكتل/الملفات عن الحوسبة ويجعل أعباء العمل ذات الحالة المرنة مثل أعباء العمل غير ذات الحالة
سعد علي، جوجل
ما الذي كان يجب أن يتغير؟
علي: في الأصل، افترضت حزمة تخزين Kubernetes أن مسؤول التخزين سيقوم مسبقًا بتوفير مجموعة من وحدات تخزين الكتل/الملفات بأحجام مختلفة ليستخدمها مشغلو التطبيقات. وأدى ذلك إلى الاستخدام غير الفعال لسعة التخزين المتاحة.
قدمت SIG Storage مفهوم التزويد الديناميكي في Kubernetes 1.6. كان هذا بمثابة تغيير في قواعد اللعبة فيما يتعلق بسهولة استخدام تخزين الكتل/الملفات على نطاق واسع وإكمال أتمتة دورة حياة حجم التخزين لأنه يوفر التخزين عند الطلب حسب الحاجة لأعباء العمل، ويزيل التدخل البشري ويتيح الاستخدام الفعال لسعة التخزين.
ماذا حدث لمشغلي Kubernetes مما جعلهم ناجحين في مجال البيانات والتخزين؟
علي: مثل لبنات البناء تم وضعها في مكانها – واجهات StorageClass وPersistentVolumeClaim (PVC) وPersistentVolume (PV) وCSI والتوفير الديناميكي – وأصبح تنسيق العناصر الأولية ذات الحالة الأعلى موضع التركيز.
عرضت Kubernetes مجموعات StatefulSets ككتلة أساسية لأحمال العمل ذات الحالة. ولكن أصبح من الواضح أن العديد من التطبيقات ذات الحالة المعقدة تتطلب مزيدًا من التنسيق الدقيق لبياناتها لتمكين أشياء مثل النسخ المتماثل والقياس وما إلى ذلك.
هذا هو المكان الذي جاء فيه مشغلو Kubernetes. لقد قدموا طريقة سهلة لتوسيع Kubernetes لتمكين العمليات المرتبطة بالتطبيقات مثل تقسيم البيانات لضمان التوفر العالي، وتجنب أن تصبح جميع النسخ المتماثلة غير متاحة مرة واحدة، وما إلى ذلك.
كيف دعم هذا المزيد من الأساليب السحابية الأصلية؟ ماذا كانت العواقب؟
علي: تتيح مجموعة تخزين Kubernetes جنبًا إلى جنب مع مشغلي Kubernetes الاستخدام المرن حقًا لموارد الحوسبة المتاحة. هذا، في رأيي، هو جوهر ما يعنيه البناء في السحابة – وجود مجموعة مرنة كبيرة من موارد الحوسبة التي يمكن استخدامها من قبل جميع أعباء العمل الخاصة بك، عند الطلب، والتوسع والتوسع دون تدخل بشري لزيادة الحد الأقصى توافرها وخفض التكاليف.
في عمر 10 سنوات، بدأ Kubernetes يشعر وكأنه Linux بالنسبة للحوسبة الموزعة. إنها أداة مفتوحة المصدر قوية وقابلة للتوسيع وقد تم اعتمادها على نطاق واسع وهي لبنة أساسية للبنية التحتية الحاسوبية الموزعة الحديثة
سعد علي، جوجل
يبلغ عمر Kubernetes الآن 10 سنوات. ما رأيك في ذلك اليوم؟
في عمر 10 سنوات، بدأ Kubernetes يشعر وكأنه Linux بالنسبة للحوسبة الموزعة. إنها أداة مفتوحة المصدر قوية وقابلة للتوسيع وقد تم اعتمادها على نطاق واسع وتشكل لبنة أساسية للبنية التحتية الحاسوبية الموزعة الحديثة.
ما هي المشاكل التي لا تزال موجودة حول Kubernetes عندما يتعلق الأمر بالبيانات والتخزين؟
علي: لقد سهّل Kubernetes تطوير تطبيقات محمولة وقابلة للتطوير ومفيدة الحالة تستفيد من تخزين الكتل والملفات. لكن التخزين لا يزال صعبًا بالنسبة للعديد من المطورين الذين لا يريدون القلق بشأن كيفية عمل قواعد البيانات المختلفة، والاختلافات بين النسخ المتماثل غير المتزامن والمتزامن، والمفاضلة بين ملفات تعريف تكرار التخزين المختلفة، وما إلى ذلك.
قد لا تكون هذه مشكلة يتعين على Kubernetes حلها، ولكن، كصناعة، يتعين علينا أن نجعل من السهل إنشاء تطبيقات ذات حالة جيدة لجميع أنواع المطورين ذوي النطاق المتفاوت والتكرار ومتطلبات الأداء مع الحفاظ على قابلية النقل بغض النظر عن البائع.
هل هناك أي حكايات أو معلومات أخرى للمشاركة؟
علي: أصبحت المشاريع مفتوحة المصدر مثل Kubernetes ممكنة بفضل الكثير من المساهمين الرائعين من جميع أنحاء العالم. إنهم بحاجة إلى الصيانة والتحسين المستمر. وأشجع أي شخص مهتم أن يأتي وينضم إلينا. إذا كنت مهتمًا بالتخزين، انضم تخزين Kubernetes SIG. إذا كنت مهتمًا بالبيانات، انضم إلى البيانات على Kubernetes مجتمع. شارك وساعدنا في قيادة الجيل القادم من التحسينات.
