Kubernetes يبلغ من العمر 10 سنوات! في منتصف عام 2024، سيحتفل العالم بالذكرى العاشرة لتأسيسه منصة تنظيم الحاويات الرائدة في السوق.
بدأ Xing Yang، رئيس تقنية التخزين السحابي في VMware by Broadcom، العمل على التخزين في Kubernetes في عام 2017، تم إطلاق مشاريع تعتمد على تعريفات الموارد المخصصة (CRDs)، والتي تسمح لمنصة التنسيق بالعمل حول جوهر قابل للتوسيع.
وفي وقت لاحق، واصلت رؤية منصة تنسيق الحاويات Kubernetes تحقق الريادة في السوق والعمل على واجهة تخزين الحاويات (CSI) ومشغلي Kubernetes، والتي تعتمد على CRDs والتي توفر وظائف التخزين وحماية البيانات مع الاحتفاظ بخصائص Kubernetes الأساسية.
نحتفل بالعقد الأول من Kubernetes بسلسلة من المقابلات مع المهندسين الذين ساعدوا في تطوير Kubernetes ومعالجة التحديات في تخزين وحماية البيانات – بما في ذلك استخدام مشغلي Kubernetes – ونحن نتطلع إلى مستقبل يتميز بـ الذكاء الاصطناعي أحمال العمل
كيف كان السوق عندما تم إطلاق Kubernetes لأول مرة؟
شينغ يانغ:عندما تم إطلاق Kubernetes لأول مرة، كان سوق تنسيق الحاويات لا يزال ناشئًا. كما تم تقديم Docker للتو وأصبح أداة شائعة لبناء الصور. Kubernetes هو نظام تنسيق حاويات يجعل من السهل نشر صور Docker على الأنظمة الموزعة. وهذا يجعل Kubernetes خيارًا شائعًا تطور إلى نظام تنسيق الحاويات الفعلي اليوم.
كيف دخلت إلى هذا المجال؟
يانغ:بدأت بالمساهمة في لقطة من الحجم مشروع في Kubernetes SIG Storage في عام 2017، بالتعاون الوثيق مع Jing Xu من Google. لقد حاولنا في البداية تقديم واجهة برمجة التطبيقات ووحدة التحكم VolumeSnapshot في قاعدة كود Kubernetes الأساسية، لكن تم رفضها من قبل SIG Architecture.
لقد طلبوا منا استخدام CRDs بدلاً من ذلك. والسبب هو أن Kubernetes يجب أن يكون معياريًا حقًا وقابلًا للتوسع وقابلًا للصيانة مع الحد الأدنى من النواة. لذا، قمنا بتنفيذ ميزة VolumeSnapshot خارج الشجرة تحت Kubernetes CSIلقد أصبحت هذه أول ميزة أساسية في SIG Storage يتم تنفيذها كأجهزة CRD. لقد روينا قصتنا خلال عرض تقديمي رئيسي في KubeCon China في عام 2019: CRDs لم تعد شيئا من الدرجة الثانية!
لقد عملنا مع أعضاء آخرين في المجتمع لنقل ميزة VolumeSnapshot من الإصدار التجريبي إلى الإصدار التجريبي، وأخيرًا جعلناها متاحة للجميع في إصدار Kubernetes 1.20. لقد أصبحت مسؤول صيانة في Kubernetes SIG Storage.
كيف أدركت أن Kubernetes يحتل مكانة رائدة في السوق؟
يانغتم تقديم Kubernetes لأول مرة بواسطة Google في يونيو 2014 وتم التبرع به بعد ذلك لمؤسسة Linux وأصبح مشروع البذر في مؤسسة Cloud Native Computing Foundation (CNCF).
بدأت شركات توفير السحابة العامة الرائدة الأخرى مثل AWS وAzure في تقديم توزيعات Kubernetes على السحابات الخاصة بها في عام 2017 وجعلتها متاحة بشكل عام في عام 2018. عندما حصلت شركات توفير السحابة الرائدة على توزيعات Kubernetes في السحابة الخاصة بها، أدركت أن Kubernetes كانت تكتسب زخمًا في السحابة وحققت اعتماد المؤسسات.
عندما نظرت إلى Kubernetes، كيف تعاملت مع البيانات والتخزين؟
يانغ:عندما تم تقديم Kubernetes لأول مرة، كان مخصصًا لأحمال العمل عديمة الجنسية فقط. في ذلك الوقت، كانت تطبيقات الحاويات تعتبر مؤقتة وعديمة الجنسية وبالتالي لم تكن بحاجة إلى الاحتفاظ بالبيانات.
ولكن، تغير ذلك بشكل كبير. بدأت أحمال العمل التي تخضع للحالة في العمل في Kubernetes. وتم تقديم مطالبات الحجم المستمر والأحجام المستمرة وفئات التخزين لتوفير أحجام البيانات للتطبيقات التي تعمل في Kubernetes. كما تم تقديم واجهة برمجة تطبيقات عبء العمل StatefulSet لتشغيل أحمال العمل التي تخضع للحالة في Kubernetes. يتم تشغيل المزيد والمزيد من أحمال العمل التي تخضع للحالة في Kubernetes اليوم.
ما هي القضايا التي واجهتك أولاً فيما يتعلق بالبيانات والتخزين مع Kubernetes؟
يانغ:عندما بدأت في الانخراط في Kubernetes، كان CSI قد تم تقديمه للتو. لقد حاول تصميم واجهات مشتركة حتى يتمكن بائع التخزين من كتابة مكون إضافي وتشغيله في مجموعة من أنظمة التنسيق، والتي تضمنت Docker وMesos وKubernetes وCloud Foundry في ذلك الوقت.
كانت المجموعة الأولية من واجهات CSI أساسية للغاية، وتضمنت إنشاء وحذف وإرفاق وفصل وتركيب وإلغاء تركيب وحدات تخزين. ومع ذلك، لدعم أحمال العمل المرتبطة بالحالة، كانت هناك حاجة إلى وظائف أكثر تقدمًا. على سبيل المثال، لم تكن لقطة وحدة التخزين والاستنساخ وتوسيع وحدة التخزين والطوبولوجيا مدعومة في CSI في البداية.
ما الذي كان يجب أن يتغير؟
يانغ:كانت هناك حاجة إلى وظائف أكثر تقدمًا لـ CSI لدعم أحمال العمل ذات الحالة التي تعمل في Kubernetes بشكل أكثر فعالية.
لقطة حجمية تم تقديمه في CSI للسماح بالتقاط لقطات من المجلدات الثابتة واستخدامها كطريقة لاستعادة البيانات في حالة حدوث فقد أو تلف للبيانات. استنساخ الحجم تمت إضافة أيضًا إلى CSI والذي يمكن استخدامه لنسخ البيانات المخزنة في وحدة تخزين ثابتة لإنشاء وحدة تخزين جديدة منها.
تُعد طوبولوجيا CSI أيضًا ميزة مهمة للغاية لأحمال العمل الخاصة بقواعد البيانات الموزعة. فهي تسمح لـ Kubernetes بإجراء جدولة ذكية بحيث يتم توفير الحجم ديناميكيًا في أفضل مكان لتشغيل الجرابوبالتالي، يمكنك نشر أحمال العمل وتوسيع نطاقها عبر مجالات الفشل لتوفير قدر كبير من التوفر والتسامح مع الأخطاء.
توسيع حجم CSI تُعد ميزة أخرى مهمة لأحمال العمل التي تعتمد على الحالة ميزة تسمح لك بتوسيع الحجم إلى حجم أكبر إذا كان تطبيقك يحتاج إلى مساحة أكبر لكتابة البيانات.
هناك أيضا تتبع قدرة CSI ميزة تسمح لجدول Kubernetes بأخذ السعة في الاعتبار أثناء الجدولة.
توجد أيضًا فجوات في دعم حماية البيانات في Kubernetes. هناك بعض اللبنات الأساسية مثل لقطات وحدة التخزين التي يمكن استخدامها للنسخ الاحتياطي والاستعادة، ولكن هناك حاجة إلى المزيد لحماية أحمال العمل ذات الحالة في حالة وقوع كارثة. لقد شكلنا مجموعة عمل حماية البيانات في بداية عام 2020 أن تهدف إلى تعزيز دعم حماية البيانات في Kubernetes.
كيف انضممت إلى مشغلي Kubernetes؟
يانغ:مع توفر ميزات تخزين أكثر تقدمًا، أصبح Kubernetes منصة أكثر نضجًا لتوفير التخزين لأحمال العمل ذات الحالة، حيث تعد قواعد البيانات أحد أهم أنواع أحمال العمل.
بصفتي رئيسًا مشاركًا في CNCF TAG Storage، أتيحت لي الفرصة للتعاون مع مجتمع البيانات على Kubernetes في إعداد ورقة بيضاء حول تشغيل قواعد البيانات في Kubernetes. كما تمت مناقشته في الكتاب الأبيضتُعد المشغلات أحد أهم الأنماط المستخدمة عند تشغيل البيانات في Kubernetes.
ما الذي حدث حول المشغلين مما جعلهم ناجحين في مجال البيانات والتخزين؟
يانغ:يستفيد المشغلون من CRDs المرنة والقابلة للتوسيع. لم يتم تصميم العديد من قواعد البيانات التقليدية في الأصل لـ Kubernetes، ولكن مع المشغلين يمكن تغليف منطق الأعمال المعقد أسفل CRDs هذه. بالنسبة للمستخدمين، من السهل طلب مجموعة قاعدة بيانات من خلال تحديد مورد مخصص (CR). يعتمد منطق التحكم في المشغل على الطبيعة التصريحية لـ Kubernetes ويوفق بين الحالة الفعلية لقاعدة البيانات والحالة المطلوبة المحددة في CR، ويحاول باستمرار سد الفجوة والحفاظ على تشغيل قاعدة البيانات.
يساعد المشغلون في أتمتة عمليات اليوم الثاني مثل النسخ الاحتياطي والاستعادة والترحيل والترقية وما إلى ذلك. فهم يجعلون من السهل نقل التطبيقات عبر السحابات أو دعم السحابات الهجينة. كما أن CNCF لديها نظام بيئي غني بالعديد من الأدوات المتاحة. على سبيل المثال، Prometheus للمراقبة، وCert Manager للمصادقة، وFluentd لمعالجة السجلات، وArgo CD للتسليم المستمر التصريحي، وغير ذلك الكثير. يمكن للمشغلين استخدام أدوات الطرف الثالث هذه لتعزيز قدرات مجموعات قواعد البيانات التي تعمل في Kubernetes.
كيف ساعد هذا في دعم المزيد من الأساليب السحابية الأصلية؟ وما هي العواقب؟
يانغ:في بيئة سحابية أصلية، قد يتم إيقاف تشغيل جراب Kubernetes الذي يعمل كجزء من تطبيق قاعدة البيانات بسبب خطأ في وحدة المعالجة المركزية أو الذاكرة أو قد يتم إعادة تشغيله بسبب تعطل عقدة Kubernetes. يرتبط التخزين المؤقت ارتباطًا وثيقًا بدورة حياة الجراب بحيث يختفي مع الجراب إذا كنت تستخدم التخزين المحلي. إذا كنت تستخدم التخزين الخارجي، فهناك مشكلة مختلفة، وهي زمن الوصول الإضافي.
يمكن للمشغلين المساعدة في التخفيف من حدة هذه المشكلات من خلال توفير توافر عالٍ، والسماح للتطبيقات بالعمل بطريقة موزعة، وأتمتة النشر، وتوفير المراقبة، وإدارة دورة حياة قواعد البيانات، والسماح لقواعد البيانات بالعمل بشكل صحيح في بيئة Kubernetes.
Kubernetes أصبح الآن في عامه العاشر. ما رأيك فيه اليوم؟
يانغ:لقد حدث الكثير خلال السنوات العشر منذ ولادة Kubernetes. تم تضمين العديد من الميزات في Kubernetes لدعم أحمال عمل البيانات، كما أصبح Kubernetes أكثر نضجًا. يحتوي Kubernetes على واجهات برمجة تطبيقات إعلانية. إنه مرن وقابل للتوسيع. إنه يوفر طريقة لتلخيص البنية الأساسية الأساسية. كان المشغلون بمثابة بطاقة لعب سحرية لتوسيع حالات استخدام Kubernetes. إنه المفتاح الذي يسمح بتشغيل قواعد البيانات في Kubernetes.
ما هي المشاكل التي لا تزال قائمة حول Kubernetes عندما يتعلق الأمر بالبيانات والتخزين؟
يانغ:لا تزال عمليات اليوم الثاني تشكل تحديًا عند تشغيل البيانات على Kubernetes، ولكن يمكن التخفيف من ذلك باستخدام المشغلات. Kubernetes معقد للغاية، ويستغرق وقتًا طويلاً للتشغيل، ويتطلب الأمر الكثير من الجهد لإدارة أحمال عمل البيانات على Kubernetes، كما أن التكامل مع البيئة الحالية أمر معقد.
وبالنسبة للمشغلين، لا يزال الافتقار إلى التوحيد القياسي يمثل مشكلة. كما أن تشغيل أحمال العمل ذات الحالة في بيئة متعددة المجموعات لا يزال يشكل تحديًا لأن Kubernetes صُمم في البداية للعمل في مجموعة واحدة.
هل لديك أي حكايات أو معلومات أخرى تود مشاركتها؟
يانغ:لقد قطعت Kubernetes شوطًا طويلاً منذ نشأتها قبل 10 سنوات. المستقبل مشرق بالنسبة لـ Kubernetes في العقد المقبل وما بعده.
