فكر مرتين قبل استخدام هيلم.

رأس بدون ضجيج. نظرة قاتمة

هيلم هو مدير حزم لشركة Kubernetes.

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

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

ما هي القيمة الحقيقية لهلم؟

ما زلت لا أستطيع الإجابة على هذا السؤال بثقة. لا يوفر Helm أي ميزات خاصة. ما الفوائد التي يجلبها Tiller (جانب الخادم)؟

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

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

الكلمات فارغة. أرني الرمز!
—لينوس تورفالدس

مستوى إضافي من التفويض والتحكم في الوصول

أتذكر شخصًا ما يقارن Tiller بـ "خادم sudo ضخم". في رأيي ، هذا هو المستوى التالي من التفويض ، والذي يتطلب في الوقت نفسه شهادات TLS إضافية ، ولكنه لا يوفر إمكانات التحكم في الوصول. لماذا لا تستخدم Kubernetes API ونموذج الأمان الحالي الذي يدعم التدقيق و RBAC؟

أداة معالجة قالب مبالغ فيها؟

والحقيقة هي أنه من أجل المعالجة والتحليل الثابت لملفات قالب Go ، يتم استخدام التكوين من ملف values.yaml ، ثم يتم استخدام بيان Kubernetes الذي تمت معالجته مع البيانات الوصفية المقابلة المخزنة في ConfigMap.

ويمكنك استخدام بعض الأوامر البسيطة:

 $ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f . 

لقد لاحظت أن المطورين عادة ما يستخدمون ملف values.yaml لكل بيئة ، أو حتى حصلوا عليه من values.yaml.tmpl . values.yaml.tmpl قبل الاستخدام.

هذا لا معنى له عند العمل مع أسرار Kubernetes ، والتي غالبًا ما يتم تشفيرها ولها عدة إصدارات في المستودع. للتغلب على هذا القيد ، ستحتاج إلى استخدام المكون الإضافي helm-secrets أو الأمر --set key=value . في أي حال ، يتم إضافة مستوى آخر من التعقيد.

هيلم كأداة لإدارة دورة حياة البنية التحتية

إنسي الأمر هذا غير ممكن ، خاصة إذا كنا نتحدث عن المكونات الرئيسية لـ Kubernetes ، مثل kube-dns ومزود CNI و autoscaler العنقودي ، إلخ. تختلف دورات حياة هذه المكونات ، ولا يتناسب Helm معها.

تُظهر تجربتي مع Helm أن هذه الأداة رائعة لعمليات النشر البسيطة على موارد Kubernetes الأساسية ، والتي يمكن تنفيذها بسهولة من الصفر وبدون عملية إصدار معقدة.

لسوء الحظ ، لا يتعامل Helm مع عمليات النشر الأكثر تعقيدًا وتكرارًا ، بما في ذلك Namespace و RBAC و NetworkPolicy و ResourceQuota و PodSecurityPolicy.

أفهم أن معجبي هيلم قد لا يحبون كلماتي ، ولكن هذا هو الواقع.

الدولة هيلم

يخزن خادم Tiller المعلومات في ملفات ConfigMap داخل Kubernetes. لا يحتاج إلى قاعدة بياناته الخاصة.

لسوء الحظ ، لا يمكن أن يتجاوز حجم ConfigMap 1 ميغابايت بسبب قيود etcd .

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

أعطال عشوائية ومعالجة الأخطاء

بالنسبة لي ، أكبر مشكلة في هيلم هي انعدام الأمن.

خطأ: فشل الترقية: لم يتم نشر "foo"

هذه ، IMHO ، هي واحدة من أكثر مشاكل هيلم المزعجة.

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

الطلب التالي لإدراج التغييرات "يعمل على إصلاح" الخطأ بإضافة علامة --force ، التي تخفي المشكلة في الواقع فقط عن طريق تشغيل الأمر helm delete & helm install —replace .

ومع ذلك ، في معظم الحالات ، سيكون عليك إجراء تنظيف كامل للإصدار.

 helm delete --purge $RELEASE_NAME 

خطأ: تعذّر إصدار foo: انتهت المهلة بانتظار الشرط

إذا كان ServiceAccount مفقودًا أو لا يسمح RBAC بإنشاء مورد معين ، فسوف تُرجع Helm رسالة الخطأ التالية:

 Error: release foo failed: timed out waiting for the condition 

للأسف ، لا يمكن رؤية السبب الجذري لهذا الخطأ:

 kubectl -n foo get events --sort-by='{.lastTimestamp}' 

 Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found 

تفشل من فراغ

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

يدير helm init الفلاح بنسخة واحدة ، وليس في تكوين HA

لا يعني Tiller بشكل افتراضي توفرًا كبيرًا ، ولا يزال طلب تمكين التغييرات حسب المرجع مفتوحًا.

في يوم من الأيام سيؤدي إلى التوقف ...

حلم 3؟ مشغلي؟ المستقبل؟

سيضيف الإصدار التالي من Helm بعض الميزات الواعدة:

• بنية خدمة واحدة بدون فصل بين العميل والخادم. لا مزيد من الحارث.
• المدمج في محرك البرمجة النصية لوا ؛
• سير عمل DevOps بناءً على طلبات التضمين ومشروع Helm Controller الجديد.

لمزيد من المعلومات ، انظر مقترحات مشروع Helm 3 .

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

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

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

افهم هذا: هذه المقالة هي رأيي الشخصي ، الذي توصلت إليه عند إنشاء منصة سحابية مختلطة لعمليات النشر المستندة إلى Kubernetes.