Kustomize مقابل Helm: ما الفرق؟

عندما يتعلق الأمر بإدارة ونشر تطبيقات Kubernetes، تبرز أداتان باستمرار: Kustomize وHelm. يعمل كلاهما على تبسيط تعقيد عمليات نشر Kubernetes، ولكنهما يتبعان نهجين مختلفين بشكل أساسي لحل نفس التحدي.

Helm هو مدير حزم لـ Kubernetes والذي يقوم بتجميع كل ما هو مطلوب للتطبيق في حزمة واحدة قابلة لإعادة الاستخدام تسمى مخطط Helm. تتبع أداة Kustomize، وهي أداة Kubernetes أصلية، نهجًا تعريفيًا باستخدام التصحيحات والتراكبات لتعديل التكوينات الأساسية التي تتطلب استخدام لغات النمذجة.

إن الاختيار بين هذه الأدوات ليس مجرد تفضيل تقني، بل يؤثر بشكل مباشر على إنتاجية فريق التطوير والتكاليف التشغيلية والقدرة على توسيع نطاق التطبيقات بشكل موثوق. تكتشف العديد من المؤسسات قيمة كبيرة في استخدام كلتا الأداتين معًا، ولكن تحديد وقت وسبب اختيار كل نهج هو أمر ضروري لبناء استراتيجية نشر Kubernetes فعالة وقابلة للتوسع.

قبل استكشاف Kustomize وHelm، من المفيد فهم النقل بالحاويات، التي تشكل الأساس لتطبيقات السحابة الأصلية الحديثة.

يعمل النقل بالحاويات على تجميع التطبيقات بكل ما يلزم لتشغيلها -الكود والمكتبات والتكوين- في وحدات خفيفة الوزن وقابلة للحمل تُسمَّى الحاويات، والتي تعمل عادةً على أنظمة تعتمد على Linux. تتيح هذه العملية للبرامج العمل بشكل متسق عبر بيئات مختلفة، بدءًا من أجهزة الكمبيوتر المحمول للمطورين وحتى البنية الأساسية السحابية للإنتاج.

يقوم Kubernetes، والمعروف أيضًا باسم k8s أو kube، بتنظيم الحاويات (عادةً المستندة إلى Docker ) على نطاق واسع من خلال أتمتة النشر وتوسيع النطاق وإدارة الموارد عبر فئات من الأجهزة.

وفقًا لاستبيان أجرته Cloud Native Computing Foundation (CNCF) في عام 2024، وصل اعتماد السحابة الأصلية إلى أعلى مستوى له على الإطلاق بنسبة 89% بين المؤسسات التي شملها الاستبيان، و93% من المؤسسات تستخدم أو تجرب أو تقيم Kubernetes.¹

بالتزامن مع انتقال المؤسسات من التطبيقات البسيطة إلى البنى المعقدة متعددة الخدمات، تصبح ملفات التكوين المطلوبة لإدارة عمليات نشر Kubernetes معقدة بشكل متزايد. قد يتطلب التطبيق النموذجي للمؤسسة عشرات من ملفات التكوين، يحتاج كل منها إلى التخصيص لبيئات مختلفة - التطوير والمراحل والإنتاج.

 يخلق هذا التعقيد العديد من تحديات الأعمال:

• صعوبة الحفاظ على الاتساق عبر البيئات

• نفقات تشغيلية أعلى

• غياب أتمتة النشر، ما يؤدي إلى أخطاء يدوية.

• وقت أطول لطرح الميزات الجديدة في السوق

تم إنشاء كل من Kustomize وHelm لمعالجة هذه التحديات، لكنهما يتَّبعان نهجًا مختلفًا تمامًا. دخل Helm السوق أولًا عندما طرحته شركة Deis (التي استحوذت عليها لاحقًا Microsoft) كواحد من أوائل الأدوات المصممة لتبسيط إدارة تطبيقات Kubernetes. واكتسب المشروع مزيدًا من المصداقية عندما تبرعت به Deis إلى CNCF عام 2018، وحصل على حالة التخرج الكاملة من CNCF في عام 2020.

في المقابل، سلكت Kubernetes مسارًا مختلفًا بدمج Kustomize مباشرةً في واجهة سطر الأوامر (CLI) الخاصة بـ kubectl مع إصدار Kubernetes 1.14 عام 2019.

يستخدم Kustomize نهج إدارة التكوين التصريحي. بدلاً من كتابة نصوص توضح كيفية تحقيق حالة معينة، يقوم فريق عمليات التطوير والفرق الأخرى بوصف الشكل الذي يريدون أن يبدو عليه التكوين النهائي. 

تستخدم الأداة منهجية "الأساس والتراكب". تحتفظ الفرق بتكوين أساسي قياسي يلتقط الخصائص الأساسية لتطبيقاتهم. بعد ذلك، لكل بيئة أو متغير، يقومون بإنشاء تراكبات تحدد فقط الاختلافات المطلوبة لهذا السياق المحدد.

ضع في اعتبارك تكوينًا أساسيًا يحدد تطبيق ويب بمتطلبات موارد قياسية وإعداد شبكة أساسي. قد يؤدي تراكب التطوير إلى تقليل حدود المورد والنسخ المتماثلة لتوفير التكاليف، بينما قد يؤدي تراكب الإنتاج إلى زيادة إعدادات الأمان وإضافة عناصر المراقبة. يقوم Kustomize بدمج هذه التكوينات لإنتاج بيانات Kubernetes النهائية للنشر (ملفات YAML أو JSON) التي تصف الحالة المطلوبة لموارد Kubernetes.

يعمل Kustomize مباشرةً مع ملفات بيانات YAML الأصلية (مثل deployment.yaml) التي تحتوي على حقول Kubernetes القياسية مثل apiVersion. يُلغي هذا النهج الحاجة إلى لغة نمذجة، مما يسهل على الفرق تبني استخدامها دون تعلم المزيد من أساسيات البرمجة التي تتجاوز تكوينات Kustomize YAML القياسية. ونتيجة لذلك، يمكن للفرق تنفيذ إدارة تكوين متطورة بسرعة أثناء العمل باستخدام أساسيات Kubernetes YAML المألوفة التي يعرفونها بالفعل.

يُعَد Helm مدير الحزم الأكثر شيوعًا في سوق Kubernetes، حيث يعمل بشكل أساسي كمتجر تطبيقات لتطبيقات Kubernetes، ما يُتيح إدارة التطبيقات المعبأة مسبقًا وتثبيتها بسهولة. ووفقًا لاستطلاعات CNCF الأخيرة، يتصدر Helm باعتباره مدير حزمة Kubernetes المفضل، مع اعتماد 75% بين المؤسسات التي تُدير Kubernetes.‏²

يقوم Helm بتجميع التطبيقات في ما يُعرف باسم "مخططات Helm"، وهي مجموعات من موارد Kubernetes المهيأة مسبقًا، يمكن للفرق تثبيتها وتحديثها وإدارتها كوحدة واحدة. يحتوي كل مخطط على ملفات تكوين (مثل chart.yaml) ويستخدم قوالب Go لتمكين الإعداد الديناميكي استنادًا إلى القيم المُدخلة.

تكمن ميزة Helm في محرك النمذجة وقدرات إدارة الحزم. بدلاً من الاحتفاظ بإصدارات متعددة من التكوينات المماثلة، يمكّن Helm الفرق من إنشاء مخططات بعناصر نائبة واستخدام ملفات قيم منفصلة (مثل values.yaml) لتعبئة هذه العناصر النائبة أثناء النشر. يمكن للفرق استخدام helm لمعاينة التكوين النهائي المعروض قبل تطبيقه على المجموعة.  

بالإضافة إلى النمذجة، يوفر Helm ميزات شاملة لإدارة دورة الحياة، بما في ذلك القدرة على التراجع عن عمليات النشر وإدارة الإصدارات وتتبع سجل النشر. تجعل هذه القدرات من Helm عنصرًا ذا قيمة عالية للمؤسسات التي تدير محافظ التطبيقات المعقدة حيث تكون وظائف التنسيق والاستعادة ضرورية.

على سبيل المثال، يمكن لشركة في مجال التجارة الإلكترونية استخدام مخطط واحد لمتجرها عبر الإنترنت ولكن تخصيصه لبيئات مختلفة - عدد أقل من الخوادم للاختبار، والمزيد من الخوادم للإنتاج - دون إنشاء ملفات تكوين منفصلة.

لنشر هذه المخططات، تستخدم الفرق أمر helm install الذي يطبِّق تلقائيًا جميع الموارد على مجموعة Kubernetes المستهدفة عبر واجهة برمجة تطبيقات Kubernetes ‏(API). يتولى Helm إدارة الإصدارات والتبعية تلقائيًا، ما يضمن عمليات نشر متسقة وموثوقًا بها.

يعتمد الاختيار بين Kustomize وHelm على تحديات النشر وأهداف العمل على نحوٍ خاص. عادةً ما تحقق المؤسسات التي تقوم بتخصيص التطبيق نفسه لبيئات مختلفة أقصى فائدة ممكنة من Kustomize. يجد أولئك الذين يديرون تطبيقات متعددة أو يحتاجون إلى ضوابط نشر متطورة أن Helm أكثر ملاءمة.

يقدِّم القسم التالي مزيدًا من التفاصيل حول أفضل الأوقات لاستخدام كل حل.

تحتاج معظم المجموعة إلى نشر التطبيق نفسه عبر بيئات التطوير والمراحل والإنتاج مع وجود اختلافات طفيفة ولكن مهمة. يتفوق Kustomize في هذا السيناريو من خلال السماح للفرق بالحفاظ على مصدر واحد للحقيقة أثناء تطبيق تعديلات خاصة بالبيئة.

قد تتطلب بيئات التطوير تقليل حدود الموارد لتوفير التكاليف، في حين تحتاج بيئات الإنتاج إلى إعدادات أمان معززة، وخرائط تكوين مختلفة، وعناصر مراقبة. يُتيح Kustomize للمؤسسات تحديد هذه الفروقات دون الحاجة إلى تكرار ملفات التكوين بالكامل.

غالبا ما تتطلب حالات النشر المختلفة سياسات أمان مختلفة أو تدابير امتثال. يسمح Kustomize للفرق بوضع هذه المتطلبات على التكوينات الأساسية دون إنشاء مجموعات تكوين منفصلة تماماً. تثبت هذه القدرة قيمتها للمؤسسات العاملة في مناطق أو صناعات متعددة ذات متطلبات تنظيمية مختلفة.

عند طرح تغييرات التكوين عبر محفظة التطبيقات الكبيرة، يمكّن Kustomize الفرق من إجراء تعديلات تدريجية دون تعطيل بنية التكوين بالكامل. يقلل هذا النهج من المخاطر ويجعل من السهل تحديد وإصلاح المشكلات مثل التكوينات الخاطئة أو فشل النشر.

تتمثل إحدى مزايا Helm الأساسية في قدراته المتعلقة بالحِزَم، والتي تفيد بشكل خاص المؤسسات التي تبني منصات أو تسعى إلى توحيد عمليات نشر التطبيق عبر الفرق.

يمكن للفرق إنشاء مخططات قابلة لإعادة الاستخدام تمثِّل أفضل الممارسات والمعايير المؤسسية، ثم توزيعها على مستوى المؤسسة.

إن التطبيقات التي تتطلب تنسيقاً متطوراً للنشر، مثل عمليات النشر متعددة الخطوات، وإدارة التبعية، وقدرات الاستعادة، مناسبة تماماً لميزات إدارة الإصدار في Helm. إذا حدث خطأ ما ، يستطيع Helm العودة على الفور إلى إصدار العمل السابق، مما يقلل من التأثير على المستخدمين.

عند دمج تطبيقات مفتوحة المصدر الشائعة أو حلول البائعين، يوفر مستودع المخططات الشامل الخاص بـ Helm (مستودع المخططات) حزمًا جاهزة مسبقًا يمكنها تقليل وقت التنفيذ بشكل كبير.

بدلًا من إنشاء تكوينات من الصفر، يمكن للفرق الاستفادة من المخططات التي يحتفظ بها المجتمع لقواعد البيانات ومراقبة مسارات التكامل المستمر أو التسليم المستمر (CI/CD) وغيرها من مكونات البنية التحتية لتكنولوجيا المعلومات القياسية.

غالبًا ما تستخدم منصات البرمجيات كخدمة (SaaS) Helm لإدارة عمليات نشر التطبيقات الخاصة بالعميل، ونشر نفس التطبيق عدة مرات بتكوينات مختلفة في مساحات أسماء منفصلة. يوفر هذا النهج العزل والتخصيص اللازمين للبِنى متعددة المستأجرين.

يقدم Kustomize العديد من الفوائد لإدارة تكوين Kubernetes، بما في ذلك:

تختار المؤسسات Helm للحصول على فوائد مثل هذه.

بدلاً من النظر إلى Kustomize وHelm كحلول متنافسة، تحقق العديد من المؤسسات قيمة كبيرة من استخدام كلتا الأداتين معًا. يستخدم هذا النهج الهجين نقاط القوة في كل أداة مع التخفيف من قيودها.

فيما يلي بعض حالات الاستخدام الشائعة:

• النشر الأوَّلي وتخصيص البيئة

• تطبيقات الجهات الخارجية ذات التكوينات المخصصة

• البيئات متعددة الفرق

يتضمن النمط النموذجي للاستخدام المشترك تنفيذ Helm لمن أجل إعداد الحزم والنشر الأولي للتطبيق، يليه استخدام Kustomize لتطبيق التخصيصات الخاصة بالبيئات المختلفة. يوفر هذا النهج إمكانية الاستفادة من ميزات إدارة الحزم والقدرات المتعلقة بالإصدارات في Helm إلى جانب الاستفادة من البساطة والشفافية التي يوفرها Kustomize لإدارة التكوين المستمرة.

على سبيل المثال، قد تستخدم مؤسسة ما أحد مخططات Helm لنشر تطبيق خدمات مصغرة مع جميع تبعياته. والخطوة التالية هي استخدام تراكبات Kustomize لإضافة سياسات أمان للإنتاج أو تكوين قواعد دخول Kubernetes مختلفة لتحديد المراحل.

غالبًا ما تستخدم المؤسسات Helm لنشر التطبيقات التابعة لجهات خارجية من مخزن مخططاتها الشامل، بينما يُستخدم Kustomize للتطبيقات المخصصة حيث تريد المزيد من التحكم المباشر في إدارة التكوين.

يمكّن هذا المزيج الفرق من استخدام المخططات التي يحتفظ بها المجتمع للأدوات الشائعة - مثل أنظمة المراقبة أو قوائم انتظار الرسائل - مع الحفاظ على التحكم الكامل في تطبيقاتهم الخاصة.

في المؤسسات الكبرى التي تضم فرق تطوير متعددة، غالبًا ما تُنشئ فرق المنصات مخططات Helm قياسية تحتوي على أفضل الممارسات المؤسسية ومتطلبات الامتثال. تعمل هذه المخططات مع أدوات البنية التحتية كرمز (IaC) مثل Terraform لإدارة مسار النشر الكامل.

تستخدم فرق التطوير الفردية بعد ذلك Kustomize لتخصيص هذه المخططات لتطبيقاتها وبيئاتها الخاصة دون تعديل المخططات الأساسية. يُنشئ هذا النهج فصلًا واضحًا يندمج بسلاسة مع أدوات GitOps مثل ArgoCD لدعم مهام سير عمل النشر المؤتمتة.

تتطلب الإدارة الفعالة لتكوين Kubernetes استراتيجية مرنة تتكيف مع احتياجات التطبيق المتطور.

يساعد فهم الاختلافات بين Helm وKustomize - ومعرفة كيفية دمجهما بفعالية - في تقليل التعقيد والحفاظ على الاتساق. يؤدي هذا المزيج الاستراتيجي في النهاية إلى بيئات Kubernetes أكثر قابلية للصيانة وقابلية للتوسع.