مشكلة kubectl apply الخام

نادرًا ما يتسع تطبيق Kubernetes واحد داخل ملف واحد. غالبًا ما تحتاجون إلى Deployment وService وConfigMap وغير ذلك، بحيث يكون كل منها في ملف YAML خاص به.

باستخدام Kubernetes الخام، تشغّلون kubectl apply على كل manifest. ثلاثة ملفات تعني ثلاثة أوامر يجب تذكرها وتشغيلها بالترتيب.

يمكنكم تطبيق مجلد كامل دفعة واحدة. هذا مفيد، لكنه لا يزال يتعامل مع كل ملف باعتباره كائنًا منفصلًا وغير مرتبط بالآخر، من دون هوية مشتركة. 📁

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

بعد إجراء بضعة تعديلات، تختلف بيئتا التطوير والإنتاج بهدوء. هذا الاختلاف الصامت هو المكان الذي تختبئ فيه الأخطاء المربكة التي يصعب إعادة إنتاجها. 🐛

لا تملك ملفات manifest الخام إصدارًا مشتركًا. لا يمكنكم الإشارة إلى رقم واحد وتحديد مجموعة الملفات التي تعمل حاليًا بالضبط.

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

يعني النشر السيئ أنكم ستبحثون بسرعة في سجل Git عن ملف YAML القديم. لا يوجد زر للتراجع بخطوة واحدة باستخدام kubectl العادي.

تُعاد كتابة التسميات والأسماء نفسها في ملفات متعددة. وقد يؤدي خطأ مطبعي واحد في selector إلى توقف Service عن العثور على Pods من دون تنبيه واضح.

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

نريد تثبيت التطبيق وإدارته بإصداراته وضبطه وإزالته باعتباره وحدة واحدة، وبأمر واحد. هذه الفجوة هي بالضبط ما يملؤه Helm. 🎯

يوزّع kubectl apply الخام التطبيق على ملفات كثيرة من دون إدارة للإصدارات، مع اختلافات يسهل حدوثها وتنظيف يدوي. هذا هو السبب في وجود Helm. ✅