تقريبا. العابرة. : الاهتمام المتزايد بـ "Kubernetes package manager" - Helm ، الذي لوحظ مؤخرًا ، سهل التفسير. التحديث الرئيسي الذي طال انتظاره لـ Helm v3 ، والذي كتبنا عنه بالفعل ، لا يزال في المرحلة النشطة - وليس فقط من التطوير ، ولكن أيضًا من الإصدارات. تم إصدار أحدث إصدار تجريبي له ، وهو الثالث على التوالي ، في أوائل سبتمبر. ومؤخرا جدا ، حدث كبير إلى حد ما (لمثل هذا المشروع المتخصص المفتوح المصدر) ، الانطباعات التي انطلق منها زواره من CloudARK ، والذي يقدم iPaaS (منصة تكامل كخدمة) لـ Kubernetes.
الصورة الأصلية مأخوذة من حساب CNCF Flickrعقدت
قمة هيلم في أمستردام الأسبوع الماضي. جمعت حوالي 150 من المتحمسين يمثلون مختلف المستخدمين ومقدمي الخدمات على Kubernetes. هنا خمس نقاط رئيسية من هذا الحدث.
1. في Helm 3.0 - أمان أفضل ودعم CRD وبعض التغييرات التي تخالف النهج المعتاد
حضر القمة بعض الأعضاء الرئيسيين في فريق تطوير هيلم الأساسي. من خطبهم وتواصلهم على الهامش ، أصبح من الواضح أن هيلم 3.0 سيكون علامة فارقة مهمة للمشروع. ربما سمع الكثير منكم أن الإصدار الثالث لن يحتوي على مكون خادم Helm.
( ملاحظة : يمكن الاطلاع على المزيد حول هذا الموضوع في هذه المقالة .) سيكون هناك ابتكارات مهمة أخرى في Helm 3.0 ، مثل عناصر التحكم الأمنية الأوثق ودعم أفضل لتعريفات الموارد المخصصة (CRDs). فيما يلي ثلاثة جوانب رئيسية أتذكرها بشكل خاص:
- في منطقة الأمان ، ستكون مجموعة الأذونات التي تم تكوينها مسبقًا للمستخدمين افتراضيًا. على عكس Tiller ، الذي حصل تلقائيًا على حقوق المسؤول للمجموعة بالكامل ، في الإصدار 3.0 من Helm ، يتعين عليك منح الامتيازات يدويًا لحسابات المستخدم (المستخدم) والخدمة (الخدمة) المصممة للعمل مع Helm. هذا التغيير يضمن اتخاذ قرارات مستنيرة من قبل المسؤولين حول أمن مجموعاتهم.
- التغيير الرئيسي الثاني هو تعزيز دعم CRD. في الإصدار الحالي من Helm ، يتم تثبيت CRD عبر الخطاف
crd-install بأنه تعليق توضيحي. ومع ذلك ، لا يستخدمه كل مطوري ومشغلي CRD. هذا يجعل مخططات Helm عرضة لأخطاء التثبيت ، حيث أن إعداد المخططات بشكل صحيح يتطلب وضع CRDs أمام قوائم الموارد المخصصة. هيلم 3.0 سيجلب دعم CRD إلى مستوى جديد. chrts الدليل الفرعي chrts في دليل crd . سيكون كافياً للمستخدم لإضافة جميع ملفات CRD YAML إلى هذا الدليل. ستقوم "هيلم" بمعالجته قبل تعيين باقي المخطط. سيضمن هذا الإجراء تثبيت CRD قبل تثبيت بيانات الموارد المخصصة. - سوف تؤثر التغييرات الرئيسية على العمل مع CLI. على سبيل المثال ، الآن أثناء تثبيت المخطط ، يتم إنشاء اسم إصدار عشوائي إذا لم يتم تحديده كمعلمة إدخال. في Helm 3.0 ، سيكون الموقف هو عكس ذلك: ستصبح المعلمة التي تحمل اسمًا إلزامية. للحفاظ على التسمية العشوائية للإصدارات ، ستحتاج إلى تحديد إشارة خاصة عند إدخال الأمر.
2. توحيد التحف الأصلية السحابية
تم تخصيص عدة جلسات لمشاكل تخزين مخططات Helm. ترأس هذه الجلسات
جوش دولتسكي ، مؤلف
متحف شارتم . قدم المشكلة والحلول الحالية وتحدث عن الاتجاهات العامة في هذا المجال. الاستنتاج الرئيسي هو أن العمل مع مختلف القطع الأثرية التي يجب عليك التعامل معها في النهج السحابي الأصلي (صور Docker ، مخططات Helm ، ملفات تخصيص Kustomize) يجب أن يكون ثابتًا.
يتم
استدعاء مشروع
ORAS - OCI Registry as Storage لضمان تخزين كل هذه القطع الأثرية في سجل واحد. بالنسبة لمستخدمي Kubernetes ، هذه بالتأكيد خطوة في الاتجاه الصحيح ، لأنها ستسمح لك بدمج مختلف القطع الأثرية في سجل واحد ، مع توفير الدعم في الوقت نفسه لأشياء مثل تقسيم السجل ، والتحكم في الوصول ، إلخ.
3. هيلم والمشغلين
تناول العديد من المتحدثين موضوع تحكم المستخدم والمشغلين في خطاباتهم. ركز
عرض CloudARK على أفضل الممارسات لإنشاء مخططات Helm للمشغلين. تحدث
فريق ريد هات عن المشغلين
ومحور المشغل .
ناقش ممثلو
Workday و
Weaveworks وجامعة Notre Dame في خطبهم نهج Kubernetes الأصلي للتفاوض المستمر بشأن الإصدارات المستندة إلى Helm في مجموعة باستخدام عملية تسمى GitOps.
( ملاحظة ترجمة : اقرأ المزيد عن GitOps هنا .)وكان الاستنتاج الرئيسي لجميع هذه العروض هو أن هيلم والمشغلين يكملون بعضهم البعض جيدًا. بينما يركز السابق (Helm) على قالب وبساطة إدارة القطع الأثرية ، يركز الأخير (المشغلون) على إدارة مهام اليوم الثاني
(أي ، في مرحلة دورة حياة النظام ، عندما يبدأ أن يؤتي ثماره لمنشئيه - تقريبًا. ) لبرامج الجهات الخارجية مثل قواعد البيانات العلائقية / غير العلائقية التي تعمل في كتلة Kubernetes.
4. قضايا إدارة مخطط هيلم
عندما يتعلق الأمر بتطبيقات المؤسسات الكبيرة ، فإن مخطط Helm واحد لا يكفي. بعض المخططات البيانية مطلوبة.
كان عرض GitLab اكتشافًا حقيقيًا بهذا المعنى. لديهم العديد من الرسوم البيانية ، في حين أن متوسط حجم المخطط كبير جدًا (عدة آلاف من الخطوط). إدارة كل هذه المخططات ليست مهمة سهلة في حد ذاتها.
كان هناك عرضان مثيران للاهتمام حول جوانب مختلفة من هذه المشكلة. في أحدها
، قدم
فريق IBM أداة داخلية تبسط عملية البحث عن مخططات Helm وفقًا لمعايير مختلفة. ركزوا على حل مشكلة مهندسي DevOps ، الذين اضطروا إلى اختيار وتثبيت الرسوم البيانية في مجموعاتهم. في دولة أخرى ، تحدث
فريق Replicated عن محاولة حل مشكلة إدارة تعديلات مخطط Helm دون إنشاء نسخ أو شوك. جوهر النهج المتبع في ذلك هو فصل مخطط Helm الأساسي ، وإنشاء مخططات Helm مخصصة من خلال استعارة فكرة التخصيص من ملفات التصحيح. في المستقبل ، يمكننا أن نشهد نشاطًا سريعًا في هذا الاتجاه ، حيث يركز العديد من مقدمي الخدمات على الجوانب المختلفة لمخططات Helm التي تؤثر على إدارتهم. على سبيل المثال ، نركز في CloudARK على مخططات Helm للمشغلين الذين يتلقون تعليقات توضيحية خاصة بالنظام
platform-as-code لتيسير اكتشاف الموارد المخصصة وجعلها أسهل في الاستخدام.
5. مجتمع مضياف
تحولت المطورين هيلم والأعضاء الرئيسيين في المجتمع إلى أن الناس ودية للغاية. كانت مفتوحة ومتاحة لأية مناقشات وأسئلة ، مثل تواريخ الإصدار ، والأفكار حول Helm و kustomize ، والأحداث المشتركة مع KubeCon ، إلخ.
تحدثوا أيضا عن عملية المشاركة في تطوير هيلم. وقال انه لا يبدو معقدا للغاية. لم يعتمد مشروع هيلم بعد عملية KEP (Kubernetes Enhancement Proposal). ومع ذلك ، قد يتغير هذا بعد اكتمال مرحلة الحضانة.
CloudARK في قمة هيلم
تم تكريس
عرضنا في القمة للمبادئ وأفضل الممارسات لإنشاء مخططات Helm للمشغلين. نحن نقدم iPaaS ، والذي يسمح لفرق DevOps ببناء مكدسات منصة Kubernetes الخاصة بهم دون أي اتصال بمزود Kubernetes أو واجهات الملكية. يتم حزم CRD / عوامل التشغيل الضرورية في شكل مخططات Helm مع التركيز بشكل خاص على توافق الموارد المخصصة من مختلف المشغلين.
استند العرض التقديمي إلى الدروس المستفادة من التطوير المستقل للعديد من المشغلين وتحليل أكثر من مائة مشغل متاح للجمهور من أجل الحصول على طبقة منصة Kubernetes Native مخصصة ، جاهزة للاستخدام المؤسسي.
أمستردام
يطل مكان المؤتمر على مناظر خلابة لإحدى القنوات العديدة في أمستردام.
استنتاج
هيلم على وشك أن يصبح مشروع CNCF رفيع المستوى. على مدى السنوات القليلة الماضية ، أصبح أكثر نضجًا ، واكتسب مجتمعًا قويًا وشعبية عالية. إذا كنت لا تستخدمه بعد ، فجربه. إنه يوفر واحدة من أسهل الطرق لتصميم وإدارة تحف Kubernetes. بالنسبة لأولئك الذين يستخدمونها بكثافة بالفعل ، يجب على Helm 3.0 تبديد العديد من المخاوف الأمنية وتقديم دعم واضح لسعة Kubernetes من خلال CRD.
PS من المترجم
يمكن العثور على انطباعات أخرى عن قمة Helm الماضية وتقاريره على Twitter باستخدام علامة
#HelmSummit .
اقرأ أيضًا في مدونتنا: