بعد
المشغل شل ، نقدم أخيه الأكبر -
الملحق الملحق . هذا هو مشروع مفتوح المصدر يستخدم لتثبيت مكونات النظام في نظام Kubernetes ، والذي يمكن تسميته كلمة شائعة - الوظائف الإضافية.
لماذا أي إضافات على الإطلاق؟
ليس سراً أن Kubernetes ليس منتجًا نهائيًا الكل في واحد ، وستكون هناك حاجة إلى إضافات مختلفة لبناء مجموعة "للبالغين". سيساعد الملحق الإضافي في تثبيت هذه الوظائف الإضافية وتكوينها وتحديثها.
تم الكشف عن الحاجة إلى مكونات إضافية في المجموعة في
تقرير أعده الزملاء
دريوشا . باختصار ، فإن الموقف مع Kubernetes في الوقت الحالي هو أنه بالنسبة للتثبيت البسيط ، يمكنك "الالتفاف" مع المكونات الموجودة خارج الصندوق ، للمطورين والاختبار ، يمكنك إضافة Ingress ، ولكن للتثبيت الكامل ، الذي يمكنك قوله "إن الإنتاج جاهز" ، تحتاج إلى إضافة أكثر من عشرة إضافات مختلفة: شيء للمراقبة ، شيء للسجلات ، لا تنسى الدخول ومدير الشهادات ، حدد مجموعات من العقد ، أضف سياسات الشبكة ، الموسم مع إعدادات sysctl و pod autoscaler ...
ما هي تفاصيل العمل معهم؟
كما تبين الممارسة ، فإن القضية لا تقتصر على تثبيت واحد. للعمل المريح مع الكتلة ، ستحتاج الوظائف الإضافية إلى التحديث وتعطيلها (محذوفة من الكتلة) ، وسوف تحتاج إلى اختبار شيء قبل تثبيته في كتلة الإنتاج.
لذلك ربما Ansible يكفي هنا؟ ربما. لكن
الإضافات الكاملة في الحالة العامة لا تعيش بدون إعدادات . قد تختلف هذه الإعدادات وفقًا لخيار الكتلة (aws ، gce ، اللازوردية ، المعدن العاري ، do ، ...). لا يمكن تعيين بعض الإعدادات مسبقًا - يجب الحصول عليها من الكتلة. والكتلة ليست ثابتة: بالنسبة لبعض الإعدادات ، سيتعين عليك اتباع التغييرات. وهنا Ansible مفقود بالفعل: نحن بحاجة إلى برنامج يعيش في مجموعة ، أي مشغل Kubernetes.
سيقول أولئك الذين جربوا
مشغل shell في العملية أن مهام تثبيت وتحديث الوظائف الإضافية وإعدادات التتبع يمكن حلها بالكامل بمساعدة
الخطافات لمشغل shell. يمكنك كتابة البرنامج النصي الذي سيتم
kubectl apply ومراقبته ، على سبيل المثال ، ConfigMap ، حيث سيتم تخزين الإعدادات. هذا هو تقريبا ما يتم تنفيذه في الملحق المشغل.
كيف يتم تنظيم هذا في مشغل الملحق؟
خلق حل جديد ، انطلقنا من المبادئ التالية:
- يجب أن يدعم برنامج التثبيت الإضافي تكوين templating والتكويني . نحن لا نفعل البرامج النصية السحرية التي تثبت الوظائف الإضافية. يستخدم الملحق الإضافي Helm لتثبيت الوظائف الإضافية. لتثبيت ، تحتاج إلى إنشاء مخطط وإبراز القيم التي سيتم استخدامها لتكوين.
- يمكن إنشاء الإعدادات أثناء التثبيت ، ويمكن الحصول عليها من الكتلة ، أو تلقي التحديثات عن طريق مراقبة موارد الكتلة. يمكن تنفيذ هذه العمليات باستخدام السنانير.
- يمكن تخزين الإعدادات في كتلة . لتخزين الإعدادات في الكتلة ، يتم إنشاء ConfigMap / addon-operator ويقوم Addon-operator بمراقبة تغييرات ConfigMap هذه. يتيح Addon-operator الوصول إلى إعدادات الخطافات باستخدام اصطلاحات بسيطة.
- إضافة يعتمد على الإعدادات . إذا كانت الإعدادات قد تغيرت ، فعندئذ يقوم مشغل Addon بإخراج مخطط Helm بقيم جديدة. اتحاد مخطط Helm ، والقيم الخاصة به والسنانير التي أطلقنا عليها اسم الوحدة (انظر أدناه لمزيد من التفاصيل).
- التدريج . لا البرامج النصية الإفراج السحرية. تشبه آلية التحديث تطبيقًا عاديًا - جمع الوظائف الإضافية ومشغل الوظيفة الإضافية في صورة واختبارها وطرحها.
- السيطرة على النتيجة . الملحق يمكن أن تعطي مقاييس بروميثيوس.
ما هو الملحق في المشغل الملحق؟
إضافة يمكن اعتبار كل شيء يضيف وظائف جديدة إلى الكتلة. على سبيل المثال ، يعد تثبيت Ingress مثالًا رائعًا للوظيفة الإضافية. يمكن أن يكون أي مشغل أو جهاز تحكم مع CRD الخاص به: مشغل بروميثيوس ، مدير شهادات ، مدير تحكم kube ، إلخ. أو شيء صغير ، ولكن عملية التبسيط - على سبيل المثال ، ناسخة سرية ، نسخ أسرار التسجيل إلى مساحات أسماء جديدة ، أو موالف sysctl ، تكوين معلمات sysctl على عقد جديدة.
يوفر الملحق الإضافي عدة مفاهيم لتنفيذ الوظائف الإضافية:
- يتم استخدام مخطط Helm لتثبيت البرامج المختلفة في الكتلة - على سبيل المثال ، Prometheus ، Grafana ، nginx-ingress. إذا كان المكون المطلوب يحتوي على مخطط Helm ، فسيكون تثبيته باستخدام مشغل Addon بسيطًا جدًا.
- تخزين القيم . تحتوي مخططات Helm عادةً على العديد من الإعدادات المختلفة التي يمكن أن تتغير بمرور الوقت. يدعم الملحق الإضافي تخزين هذه الإعدادات وهو قادر على مراقبة تغييراتهم من أجل إعادة تعيين مخطط Helm بقيم جديدة.
- السنانير عبارة عن ملفات قابلة للتنفيذ يتم تشغيلها في مشغل Addon على الأحداث والتي تصل إلى مخزن القيم. يمكن للخطاف مراقبة التغييرات في الكتلة وتحديث القيم في مخزن القيم. أي بمساعدة الخطافات ، يمكنك إجراء اكتشاف لجمع القيم من الكتلة عند بدء التشغيل أو وفقًا لجدول زمني ، أو اكتشاف مستمر ، من خلال جمع القيم من الكتلة عن طريق التغييرات في الكتلة.
- الوحدة النمطية هي اتحاد لمخطط Helm وتخزين القيم والسنانير. يمكن تشغيل الوحدات وإيقافها. تعطيل الوحدة النمطية هو إزالة كافة إصدارات مخطط Helm. يمكن للوحدات النمطية تشغيل نفسها بشكل حيوي ، على سبيل المثال ، إذا تم تضمين جميع الوحدات التي يحتاجها أو إذا اكتشف الاكتشاف المعلمات اللازمة في الخطافات - يتم ذلك باستخدام برنامج نصي مساعد ممكّن.
- السنانير العالمية هذه هي السنانير "من تلقاء نفسها" ، فهي ليست مدرجة في الوحدات النمطية ولديها إمكانية الوصول إلى تخزين القيم العالمية ، والقيم المتاحة لجميع السنانير في الوحدات النمطية.
كيف تعمل هذه الأجزاء معًا؟ النظر في الصورة من الوثائق:
سيناريوه العمل:
- يتم تشغيل ربط عمومي بواسطة حدث - على سبيل المثال ، عندما يتغير مورد في كتلة. هذا الخطاف يعالج التغييرات ويكتب القيم الجديدة لتخزين القيم العامة. يلاحظ المشغل الإضافي أن وحدة التخزين العالمية قد تغيرت وتطلق جميع الوحدات. تحدد كل وحدة ، باستخدام الخطافات الخاصة بها ، ما إذا كان يجب تشغيلها وتحديث مخزن القيم الخاص بها. إذا تم تمكين الوحدة النمطية ، فسيبدأ مشغل Addon تثبيت مخطط Helm. في هذه الحالة ، يمكن الوصول إلى قيم Helm-chart من قيم وحدة التخزين ومن وحدة التخزين العالمية.
- السيناريو الثاني أبسط: يتم تشغيل ربط وحدة نمطية بواسطة حدث ، وتغيير القيم في تخزين قيم الوحدة النمطية. يلاحظ هذا الملحق الإضافي ويطلق مخطط Helm بقيم محدثة.
يمكن تنفيذ الوظيفة الإضافية كـ ربط واحد أو مخطط Helm واحد أو
حتى عدة وحدات تابعة - وهذا يعتمد على مدى تعقيد المكون المثبت في الكتلة وعلى المستوى المرغوب من مرونة التكوين. على سبيل المثال ، في المستودع (
/ الأمثلة ) توجد وظيفة إضافية لموالف sysctl ، والتي يتم تنفيذها كوحدة نمطية بسيطة مع خطاف ومخطط Helm ، واستخدام تخزين القيم ، مما يجعل من الممكن إضافة إعدادات من خلال تحرير ConfigMap.
تحديث التسليم
بضع كلمات حول تنظيم تحديثات المكونات التي يثبتها مشغل Addon.
لتشغيل Addon-operator في كتلة ، تحتاج
إلى جمع صورة مع إضافات في شكل ملفات رسم الخطاف والرأس ، وإضافة الملف الثنائي
addon-operator الوظيفة الإضافية وكل ما هو مطلوب
kubectl :
bash ،
kubectl ،
kubectl ،
python ، إلخ. علاوة على ذلك ، يمكن نشر هذه الصورة على الكتلة كتطبيق منتظم ، وعلى الأرجح سترغب في تنظيم هذا أو نظام العلامات هذا. إذا كان هناك عدد قليل من المجموعات ، فقد يكون النهج نفسه كما هو الحال مع التطبيقات مناسبًا: إصدار جديد ، إصدار جديد ، عبر كافة المجموعات وتصحيح الصورة الخاصة بـ Pods. ومع ذلك ، في حالة ظهور عدد ملحوظ من المجموعات ، كان مفهوم التجديد الذاتي من القناة أكثر ملاءمة لنا.
لقد رتبت مثل هذا:
- القناة هي في الأساس معرف يمكن أن يحدده أي شخص (على سبيل المثال ، dev / stage / ea / مستقرة).
- اسم القناة هو علامة الصورة. عندما تحتاج إلى نشر تحديثات للقناة ، يتم تجميع صورة جديدة ووضع علامة باسم القناة.
- عند ظهور صورة جديدة في السجل ، تتم إعادة تشغيل مشغل Addon ويبدأ بالصورة الجديدة.
هذه ليست أفضل الممارسات ، كما هو موضح في
وثائق Kubernetes . لا ينصح بهذا ، لكننا نتحدث عن
تطبيق منتظم يعيش في كتلة واحدة . في حالة Addon-operator ، يكون التطبيق عبارة عن الكثير من عمليات النشر المنتشرة عبر مجموعات ، والتحديث الذاتي مفيد للغاية ويبسط الحياة.
تساعد القنوات
في الاختبار : إذا كان هناك كتلة مساعدة ، فيمكنك تهيئتها على قناة
stage ونقل التحديثات إليها قبل
ea قنوات
stable وآمنة. إذا حدث خطأ في الكتلة على قناة
ea ، فيمكنك تبديلها إلى حالة
stable أثناء إجراء بحث عن المشكلة في هذه المجموعة. إذا تم سحب المجموعة من الدعم النشط ،
freeze-2019-03-20 "المجمدة" - على سبيل المثال ،
freeze-2019-03-20 .
بالإضافة إلى تحديث الخطافات ومخططات Helm ، قد تحتاج إلى
تحديث مكون تابع لجهة خارجية . على سبيل المثال ، لاحظت وجود خطأ في مصدر العقدة الشرطية وحتى تعرفت على كيفية تصحيحها. ثم فتحنا العلاقات العامة وننتظر إصدارًا جديدًا يمر بجميع المجموعات ويزيد من نسخة الصورة. حتى لا تنتظر إلى أجل غير مسمى ، يمكنك جمع مصدر العقدة والتحول إليها قبل قبول العلاقات العامة.
بشكل عام ، يمكن القيام بذلك بدون Addon-operator ، ولكن مع Addon-operator ستكون الوحدة الخاصة بتثبيت مصدر العقدة مرئية في مستودع واحد ، يمكنك الاحتفاظ Dockerfile لبناء صورتك هناك ، يصبح من السهل على جميع المشاركين في العملية فهم ذلك يحدث ... وإذا كان هناك العديد من المجموعات ، فسيصبح من السهل اختبار العلاقات العامة الخاصة بك وطرح نسخة جديدة!
تعمل هذه المنظمة لتحديثات المكونات بنجاح معنا ، ولكن يمكنك تنفيذ أي مخطط مناسب آخر ، لأنه
في هذه الحالة ، يعد Addon-operator ملفًا ثنائيًا بسيطًا .
استنتاج
تسمح لك المبادئ المطبقة في مشغل Addon ببناء عملية شفافة لإنشاء واختبار وتثبيت وتحديث الوظائف الإضافية في مجموعة ، على غرار عمليات تطوير التطبيقات العادية.
يمكن تحميل الوظائف الإضافية لعامل التشغيل الإضافي بتنسيق الوحدات (خطافات Helm-chart + hooks) للجمهور. نحن ، شركة Flant ، نخطط لوضع إنجازاتنا خلال فصل الصيف في شكل مثل هذه الإضافات. انضم إلى التطوير على GitHub (
shell-operator ،
addon-operator ) ، حاول أن تجعل الإضافة بناءً على
أمثلة ووثائق ، وانتظر الأخبار على Habré وعلى
قناتنا على YouTube !
محدث (14 يونيو) : إذا كان لديك زملاء ناطقون باللغة الإنجليزية قد يكونون مهتمين بمشغل الوظيفة الإضافية ، فسيكون الإعلان المقابل متاحًا لهم على مدونتنا على "متوسط" .PS
اقرأ أيضًا في مدونتنا: