في هذا البودكاست، نلقي نظرة على ميزات التخزين المتوقعة في Kubernetes 1.31 مع سيرجي برونين، مدير منتجات المجموعة في بيركونا، والتي تقوم بتطوير منتجات مفتوحة المصدر لقواعد البيانات SQL وNoSQL.
برونين يتحدث عن من المتوقع أن تتضمن النسخة 1.31 من هذا الأسبوع وظيفة تخزين، ولكن أيضًا ما يراه كبعض الفجوات من حيث التخزين لقواعد البيانات وبشكل عام لـ التخزين في Kubernetesكما يناقش أيضًا ثغرات الامتثال والأمان التي يعتقد أنها لا تزال بحاجة إلى المعالجة في Kubernetes.
كيف تلخص الإضافات القادمة إلى Kubernetes والتي تهم الأشخاص الذين يتعاملون مع تخزين البيانات؟
سيرجي برونين: لا أعتقد أن هناك الكثير من التحسينات المتعلقة بالتخزين لأن الإصدار 1.31 كان يركز بشكل كبير على إزالة جزء كبير من التعليمات البرمجية القديمة. الأمر أشبه بإزالة 1.5 مليون سطر من التعليمات البرمجية من قاعدة التعليمات البرمجية الأساسية، ولكن تم إنشاء قاعدة التعليمات البرمجية هذه في الغالب للإصدارات القديمة واجهات تخزين الحاويات (CSIs) التي أنشأها العديد من موفري الخدمات السحابية، ثم انتقلوا إلى بنية المكونات الإضافية. كان هذا هو التركيز الرئيسي لهذا الإصدار.
هناك بعض التحسينات في التخزين. أعتقد أن أكبر هذه التحسينات وأكثرها إثارة للاهتمام بالنسبة لي هي فئة سمات وحدة التخزين. فهي تسمح للمستخدمين بتعديل وحدات التخزين الموجودة أثناء التنقل، كما لو كنت تريد تغيير عدد عمليات الإدخال والإخراج في الثانية من حيث الحجم – كما تعلم، لديك على Amazon وحدات تخزين EBS ولديها IOPS. في السابق، للقيام بذلك في Kubernetes، كنت تقوم بإنشاء فئة تخزين جديدة ثم ترحيل تطبيقك إلى وحدة التخزين الجديدة هذه.
كانت العملية صعبة للغاية. في الوقت الحالي، من خلال Kubernetes، يمكنك فقط تغيير IOPS لهذا المجلد المحدد وهذا كل شيء، ولكن هذه الميزة كانت في مرحلة تجريبية، والآن في الإصدار 1.31 تنتقل إلى مرحلة تجريبية، لذا فهي تقترب من الإصدار العام أو الإصدار المستقر.
هذه إحدى سمات التخزين الرئيسية التي تتغير. هل هناك سمات أخرى في الإصدار 1.31؟
هناك بعض الإضافات لحالة وحدة التخزين الدائمة. في الإصدار 1.31، تمت إضافة حالة جديدة “حالة وقت انتقال المرحلة الأخيرة” إلى مجلدات ثابتة.
يتيح لك هذا قياس الوقت بين الحالات المختلفة لوحدة التخزين الدائمة. يمكن أن تكون في حالة انتظار، أو في حالة دخول، أو في حالة خطأ، وما إلى ذلك. والآن، مع إضافة حالة وقت انتقال المرحلة الأخيرة هذه، يمكن لمسؤولي المجموعات المختلفة الاستفادة منها لقياس أهداف مستوى الخدمة المختلفة وما إلى ذلك بسهولة أكبر.
مرة أخرى، لا يعد هذا تحسنًا كبيرًا، لكنه بالتأكيد شيء كان المجتمع ينتظره منذ فترة طويلة. وخاصة مسؤولي المجموعات، لأن وحدات التخزين الدائمة تنضج في بيئة Kubernetes، ولا يوجد شيء تتوقعه من اليوم الأول. والآن تمت إضافته، لذا فهو أمر جيد.
هل هناك أي إضافات أخرى ترغب في تجميعها مع هذه؟
لدي بعض منها، ولكنها ليست رئيسية حقًا وليست في GA، لذا لا أعتقد أنه من الجدير ذكرها.
ما هي التحديات المتبقية في Kubernetes برأيك بالنسبة للأشخاص الذين يريدون إدارة التخزين؟
أعتقد أن إحدى المشكلات التي أراها تكمن في مجال التوسع والتخزين الآليين. تاريخيًا، تم تصميم Kubernetes كأداة لإزالة العمل الشاق عن المسؤولين، وبالنسبة لموارد الحوسبة المختلفة مثل وحدة المعالجة المركزية أو ذاكرة الوصول العشوائي، فمن السهل جدًا تنفيذ التوسع الآلي لها.
إذا لاحظت أنك وصلت إلى حد معين، فيمكنك إما إضافة المزيد من العقد إلى الصورة أو يمكنك إجراء التوسع الرأسي عن طريق إضافة المزيد من موارد وحدة المعالجة المركزية أو ذاكرة الوصول العشوائي إلى الحاوية.
ولكن بالنسبة للتخزين، فإن هذا ليس هو الحال حقًا. في حين أنه إذا نظرت إلى معظم موفري السحابة – أعني موفري السحابة العامة مثل Amazon RDS أو Aurora [databases]على سبيل المثال – لديهم توسع تخزين آلي من اليوم الأول، ومن المدهش حقًا بالنسبة لي أنه لا يوجد شيء من هذا القبيل في Kubernetes حتى الآن.
هناك بعض الحلول المخصصة التي طورتها الشركات، ولكنها إما محدودة للغاية أو لم تعد تحظى بالصيانة. الأمر أشبه بـ “مرحبًا، لقد أنشأت دليل مفهوم. الآن، أيها المجتمع، اذهب واكتشفه!”
وبالنسبة لي كمطور لمختلف [Kubernetes] مشغلو قواعد البيانات، أريد بالتأكيد توفير نفس مستوى تجربة المستخدم لمستخدمي في Kubernetes، لأنهم يفكرون أحيانًا، “حسنًا، إذا انتقلت من Aurora اللطيفة هذه من Amazon إلى المشغلين، ما هي التنازلات التي سأقدمها؟” هذا هو أحد تلك التنازلات.
هل هناك أي تطورات في Kubernetes تتجه نحو هذا، أم أنه لا يوجد شيء على الإطلاق؟
هناك دائمًا بعض الأنشطة الجارية في مجالات مختلفة في Kubernetes، ولكن لسوء الحظ، لا توجد سوى مناقشات حتى الآن. لم أر أي سطر واحد من التعليمات البرمجية تم إنشاؤه لذلك.
أيضًا، لست متأكدًا بنسبة 100% من أنه يجب أن يتم تشغيله بواسطة مجتمع Kubernetes، أو يمكن أن يكون شيئًا ما في نظام CNCF البيئي، مثل مشروع كيدا، على سبيل المثال.
Keda هي تقنية Kubernetes Event-driven Autoscaling. وقد احتضنتها CNCF من حاضنة سحابية أصلية، وهم يقومون بتوسيع الحوسبة بنجاح كبير. لذا، أعتقد، لماذا لا نضيف مساحة تخزين؟ لقد ناقشنا الأمر معهم منذ بعض الوقت، لكن لم يتم إحراز أي تقدم حتى الآن.
هل هناك أي مجالات رئيسية أخرى تعتقد أنها لم يتم حلها بعد في Kubernetes فيما يتعلق بالتخزين؟
أعتقد أن التوحيد القياسي الشامل لكيفية تفاعل المشغلين المختلفين مع التخزين من شأنه أن يساعد بالتأكيد. ولكن مرة أخرى، لا أعتقد أن هذا شيء يجب على مجتمع Kubernetes حله. يجب أن يكون مجتمعًا أوسع، يشمل مجموعات مصلحة مختلفة، لأنه مرة أخرى، إذا نظرت إلى كيفية تفاعل مشغلي Kubernetes المختلفين أو كيفية تفاعل مشاريع Kubernetes المختلفة مع التخزين، فإن بعضها يستخدم مجموعات حالة، والأغلبية منها، بعضها ينشئ عمليات نشر ويركب مجموعات PVC.
لذا، من وجهة نظر تقنية، الأمر مختلف تمامًا، والسبب في ذلك هو التكنولوجيا الأساسية التي تعتمد عليها قوة هذا التطبيق، مثل أنه يمكن أن يكون قاعدة بيانات MySQL أو قاعدة بيانات MongoDB، وبالنسبة لهما قد ترغب في اللعب بالتخزين بطريقة مختلفة قليلاً.
ولكن النتيجة النهائية التي يجب أن تحصل عليها هي الاستقرار فقط. يجب أن يكون التخزين متاحًا طوال الوقت، ويجب أن تكون بياناتك متسقة ويجب أن تكون قادرًا على بث الثقة لدى المستخدمين في أنه إذا قمت بتشغيل شيء متعلق بالتخزين في Kubernetes، فسوف يعمل ببساطة. إنه ليس سحرًا.
بعد العمل في هذا المجال لبعض الوقت، ما زلت أشعر بأننا لم نصل إلى هذه النقطة التي يمكن للشركات والمؤسسات أن تقول فيها بثقة: “أوه، نعم، تشغيل قواعد البيانات في Kubernetes هو الحل الأمثل لنا. نعتقد أن هذا هو الطريق إلى الأمام”. لا يزال هناك الكثير من الأسئلة [like] ما مدى استقرارها، وما مدى قوة الحلول وما هي التنازلات التي ستقدمها؟
هل لا يزال يُعتقد أن التخزين في Kubernetes معقد للغاية؟ هل هذا ما تقوله؟
نعم، حسنًا، أود أن أقول إنه منذ حوالي ثلاث أو أربع سنوات كان تشغيل قواعد البيانات في Kubernetes أمرًا جديدًا. في حين أن بعض المؤسسات الضخمة قد تكون شجاعة بما يكفي لتشغيل قواعد البيانات في K8s [Kubernetes]والآن نرى أن التخزين الإجمالي في Kubernetes وOperators والأدوات الأخرى داخل نظام CNCF البيئي، أصبحوا ناضجين لدعم التخزين في Kubernetes.
لكن هذا يؤدي إلى حقيقة مفادها أنه بمجرد أن تبدأ الشركات في البحث في البيانات على Kubernetes فإنها تريد تطبيق عملية التفكير الحالية [about] كيف ينبغي أن تبدو قواعد البيانات. لذا، فهم يقومون بتشغيل شيء ما على أجهزة افتراضية اليوم ولديهم تكامل LDAP ومستويات تشفير مختلفة ومعايير وما إلى ذلك ويحاولون عرضها على قواعد البيانات على Kubernetes، والتي ليست موجودة بعد.
لا تزال هناك بعض الوظائف المفقودة والتي قد تعتقد الشركات أنها يجب أن تكون موجودة منذ اليوم الأول. لماذا لا تكون موجودة؟ لكننا نصل إلى هناك ببطء. نحن نلحق بالركب ببطء وأعتقد أننا غطينا جوانب الاستقرار والأداء، لذا في الوقت الحالي لا أرى أي مشكلات لأي شخص لديه اتفاقيات مستوى الخدمة أو مع وقت التشغيل إذا قاموا بتشغيل قواعد البيانات الخاصة بهم في K8s
ولكن فيما يتعلق بالأمن والامتثال، هناك بالتأكيد بعض الثغرات أو ربما حتى بعض الميزات الصعبة مثل تلك التي وصفتها فيما يتعلق بالتوسع الخارجي. [It’s] لا يزال غير موجود [and] قد يتوقع البعض أن يكون ذلك موجودًا على الفور. لذا نعم، أعتقد أننا نتحسن عامًا بعد عام ولكن لا يزال هناك الكثير من العمل الذي يتعين القيام به.
فما هي الفجوات التي تعتقد أنها موجودة فيما يتعلق بالامتثال والأمن؟
تشفير البيانات غير النشطة لقواعد البيانات. قد تجده متاحًا لبعض المستخدمين. أما بالنسبة لبعض المستخدمين مثل PostgreSQL، فهو لا يزال مجرد رغبة. فهو غير متاح ضمن الإصدار المجتمعي من PostgreSQL. [It’s] فقط في بعض أنواع المؤسسات مثل EnterpriseDB، على سبيل المثال، لديهم هذه الميزة. لقد قاموا بتقسيمها، وما إلى ذلك
الأمر مشابه للنسخ الاحتياطية. مثل كيفية التعامل مع استمرارية العمل بشكل عام. هل تقوم بتشفير النسخ الاحتياطية الخاصة بك، وكيف يتم تخزينها وما إلى ذلك. لقد قامت معظم شركات التشغيل بحل هذه المشكلة بالفعل، ولكن على سبيل المثال، أشياء مثل استرداد الكوارث حيث تريد تشغيل قاعدة البيانات الخاصة بك عبر مراكز بيانات مختلفة والحصول على فشل تلقائي ضمن اتفاقيات مستوى الخدمة الخاصة بك؛ حسنًا، لم يتم حل هذه المشكلة بعد.
