🥇هل من السهل والمريح إعداد مجموعة Kubernetes؟ الإعلان عن عامل إضافي

بعد مشغل القشرة نقدم أخيه الأكبر - عامل إضافي. هذا مشروع مفتوح المصدر يُستخدم لتثبيت مكونات النظام في مجموعة Kubernetes، والتي يمكن تسميتها بالوظائف الإضافية.

لماذا أي إضافات على الإطلاق؟

ليس سرا أن Kubernetes ليس منتجا متكاملا جاهزا، ولبناء مجموعة "للبالغين"، ستحتاج إلى إضافات مختلفة. سيساعدك مشغل الوظائف الإضافية على تثبيت هذه الوظائف الإضافية وتكوينها والحفاظ عليها محدثة.

تم الكشف عن الحاجة إلى مكونات إضافية في المجموعة في نقل الزملاء دريوشا. باختصار، الوضع مع Kubernetes في الوقت الحالي هو أنه من أجل تثبيت "تشغيل" بسيط، يمكنك القيام بالمكونات خارج الصندوق، وبالنسبة للمطورين والاختبار، يمكنك إضافة Ingress، ولكن للتثبيت الكامل، والذي حوله يمكنك أن تقول "إنتاجك جاهز"، وتحتاج إلى إضافة عشرات الإضافات المختلفة: شيء للمراقبة، شيء للتسجيل، لا تنس الدخول ومدير الشهادات، حدد مجموعات العقد، أضف سياسات الشبكة، الموسم مع إعدادات sysctl و pod autoscaler ...

ما هي تفاصيل العمل معهم؟

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

لذا، ربما سيكون Ansible كافيًا هنا؟ ربما. لكن بشكل عام، الوظائف الإضافية الكاملة لا تعيش بدون إعدادات. قد تختلف هذه الإعدادات وفقًا لمتغير المجموعة (aws، gce، azure، bare-metal، do، ...). لا يمكن تحديد بعض الإعدادات مسبقًا، بل يجب الحصول عليها من المجموعة. والمجموعة ليست ثابتة: بالنسبة لبعض الإعدادات، سيتعين عليك مراقبة التغييرات. وهنا Ansible مفقود بالفعل: أنت بحاجة إلى برنامج يعيش في مجموعة، أي. مشغل كوبرنيتيس.

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

كيف يتم تنظيم هذا في مشغل الملحق؟

عند إنشاء حل جديد، انطلقنا من المبادئ التالية:

يجب أن يدعم مثبت الوظيفة الإضافية التشكيل والتكوين التعريفي. نحن لا نصنع نصوصًا سحرية تقوم بتثبيت الوظائف الإضافية. يستخدم مشغل Addon Helm لتثبيت الوظائف الإضافية. للتثبيت، تحتاج إلى إنشاء مخطط وتحديد القيم التي سيتم استخدامها للتكوين.
يمكن أن تكون الإعدادات توليد على التثبيت، يستطيعون الحصول على من الكتلةأو تلقي التحديثاتومراقبة موارد المجموعة. يمكن تنفيذ هذه العمليات باستخدام الخطافات.
يمكن أن تكون الإعدادات تخزين في الكتلة. لتخزين الإعدادات في المجموعة، يتم إنشاء ConfigMap/مشغل الوظيفة الإضافية ويراقب مشغل الوظيفة الإضافية التغييرات التي تطرأ على ConfigMap. يتيح عامل الوظيفة الإضافية للخطافات الوصول إلى الإعدادات باستخدام اصطلاحات بسيطة.
الإضافة تعتمد على الإعدادات. إذا تغيرت الإعدادات، فسيقوم عامل التشغيل الإضافي بطرح مخطط Helm بقيم جديدة. قمنا بتسمية مجموعة مخططات Helm وقيمها ووحدة الخطاف (انظر أدناه لمزيد من التفاصيل).
التدريج. لا توجد نصوص تحرير سحرية. تشبه آلية التحديث التطبيق العادي - قم بجمع الوظائف الإضافية ومشغلي الوظائف الإضافية في صورة ووضع علامة عليها ثم طرحها.
السيطرة على النتيجة. يمكن لمشغل الوظيفة الإضافية توفير مقاييس لـ Prometheus.

ما هو الحشو في المشغل الإضافي؟

يمكن اعتبار الإضافة أي شيء يضيف وظائف جديدة إلى المجموعة. على سبيل المثال، يعد تثبيت Ingress مثالاً رائعًا للوظيفة الإضافية. يمكن أن يكون هذا أي مشغل أو وحدة تحكم لها CRD خاص بها: مشغل prometheus، أو cert-manager، أو kube-controller-manager، وما إلى ذلك. أو شيء صغير، ولكن أسهل في الاستخدام - على سبيل المثال، ناسخة سرية، والتي تنسخ أسرار التسجيل إلى مساحات أسماء جديدة، أو موالف sysctl، الذي يقوم بتكوين معلمات sysctl على العقد الجديدة.

لتنفيذ الوظائف الإضافية، يوفر Addon-operator عدة مفاهيم:

مخطط الخوذة يستخدم لتثبيت برامج مختلفة في المجموعة - على سبيل المثال، Prometheus، Grafana، nginx-ingress. إذا كان المكون المطلوب يحتوي على مخطط Helm، فسيكون تثبيته باستخدام Addon-operator أمرًا بسيطًا للغاية.
تخزين القيم. تحتوي مخططات الدفة عادةً على العديد من الإعدادات المختلفة التي يمكن أن تتغير بمرور الوقت. يدعم Addon-operator تخزين هذه الإعدادات ويمكنه مراقبة تغييراتها من أجل إعادة تثبيت مخطط Helm بقيم جديدة.
خطافات هي ملفات قابلة للتنفيذ يقوم عامل الوظيفة الإضافية بتشغيلها في الأحداث والتي تصل إلى مخزن القيم. يمكن للخطاف مراقبة التغييرات في المجموعة وتحديث القيم في مخزن القيم. أولئك. باستخدام الخطافات، يمكنك إجراء اكتشاف لجمع القيم من المجموعة عند بدء التشغيل أو وفقًا لجدول زمني، أو يمكنك القيام بالاكتشاف المستمر، وجمع القيم من المجموعة بناءً على التغييرات في المجموعة.
وحدة عبارة عن مزيج من مخطط Helm ومخزن القيم والخطافات. يمكن تمكين الوحدات أو تعطيلها. يعني تعطيل الوحدة حذف كافة إصدارات مخطط Helm. يمكن للوحدات تمكين نفسها ديناميكيًا، على سبيل المثال، إذا تم تمكين جميع الوحدات التي تحتاجها أو إذا وجد الاكتشاف المعلمات الضرورية في الخطافات - ويتم ذلك باستخدام برنامج نصي مساعد ممكّن.
السنانير العالمية. هذه خطافات "بذاتها"، ولم يتم تضمينها في الوحدات النمطية ولديها إمكانية الوصول إلى مخزن القيم العالمية، والتي تكون قيمها متاحة لجميع الخطافات في الوحدات النمطية.

كيف تعمل هذه الأجزاء معًا؟ دعونا نلقي نظرة على الصورة من الوثائق:

هناك سيناريوهان للعمل:

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

يمكن تنفيذ الإضافة كخطاف واحد، أو كمخطط هيلم واحد، أو حتى مع العديد من الوحدات التابعة - يعتمد هذا على مدى تعقيد المكون الذي يتم تثبيته في المجموعة وعلى المستوى المطلوب من مرونة التكوين. على سبيل المثال، في المستودع (/أمثلة) هناك وظيفة إضافية sysctl-tuner، والتي يتم تنفيذها كوحدة بسيطة مع خطاف ومخطط Helm، واستخدام مخزن القيم، مما يجعل من الممكن إضافة الإعدادات عن طريق تحرير ConfigMap.

تسليم التحديثات

بضع كلمات حول تنظيم تحديثات المكونات التي يقوم Addon-operator بتثبيتها.

لتشغيل Addon-operator في المجموعة، تحتاج بناء صورة مع الإضافات في شكل ملفات الرسم البياني هوك وهيلم، قم بإضافة ملف ثنائي addon-operator وكل ما تحتاجه للخطافات: bash, kubectl, jq, python إلخ. بعد ذلك، يمكن نشر هذه الصورة إلى المجموعة كتطبيق عادي، وعلى الأرجح سوف ترغب في تنظيم نظام وضع علامات واحد أو آخر. إذا كان هناك عدد قليل من المجموعات، فقد يكون نفس النهج المتبع مع التطبيقات مناسبًا: إصدار جديد، إصدار جديد، انتقل إلى جميع المجموعات وقم بتصحيح صورة القرون. ومع ذلك، في حالة الطرح لعدد كبير من المجموعات، كان مفهوم التحديث الذاتي من القناة أكثر ملاءمة لنا.

وإليك كيف نفعل ذلك:

القناة هي في الأساس معرف يمكن تعيينه على أي شيء (على سبيل المثال، dev/stage/ea/stable).
اسم القناة هو علامة الصورة. عندما تحتاج إلى نشر التحديثات على قناة ما، يتم تجميع صورة جديدة ووضع علامة عليها باسم القناة.
عندما تظهر صورة جديدة في السجل، تتم إعادة تشغيل Addon-operator وتشغيله بالصورة الجديدة.

هذه ليست أفضل الممارسات، كما هو مكتوب في وثائق Kubernetes. لا ينصح بذلك، لكننا نتحدث عنه تطبيق منتظم يعيش في نفس المجموعة. في حالة مشغل Addon، فإن التطبيق عبارة عن العديد من عمليات النشر المنتشرة عبر المجموعات، والتحديث الذاتي يساعد كثيرًا ويجعل الحياة أسهل.

القنوات تساعد و في الاختبار: إذا كان هناك مجموعة مساعدة، يمكنك تكوينه على القناة stage وقم بإدخال التحديثات فيه قبل طرحه على القنوات ea и stable. إذا كان مع كتلة على القناة ea حدث خطأ، يمكنك التبديل إليه stable، بينما يتم التحقيق في مشكلة هذه المجموعة. إذا تم إخراج المجموعة من الدعم النشط، فإنها تتحول إلى قناتها "المجمدة" - على سبيل المثال، freeze-2019-03-20.

بالإضافة إلى تحديث الخطافات ومخططات Helm، قد تحتاج إلى التحديث ومكون الطرف الثالث. على سبيل المثال، لاحظت وجود خطأ في مُصدِّر العقدة الشرطية وتوصلت إلى كيفية تصحيحه. بعد ذلك، قمت بفتح ملف PR وانتظر الإصدار الجديد لتصفح جميع المجموعات وزيادة إصدار الصورة. لكي لا تنتظر إلى أجل غير مسمى، يمكنك إنشاء مُصدر العقدة الخاص بك والتحول إليه قبل قبول العلاقات العامة.

بشكل عام، يمكن القيام بذلك بدون مشغل Addon، ولكن باستخدام Addon-operator، ستكون الوحدة النمطية لتثبيت Node-exporter مرئية في مستودع واحد، ويمكن الاحتفاظ بملف Dockerfile الخاص ببناء صورتك هناك، ويصبح الأمر أسهل لجميع المشاركين في العملية لفهم ما يحدث... وإذا كان هناك عدة مجموعات، يصبح من الأسهل اختبار العلاقات العامة الخاصة بك وطرح إصدار جديد!

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

اختتام

تتيح لك المبادئ المطبقة في Addon-operator إنشاء عملية شفافة لإنشاء الوظائف الإضافية واختبارها وتثبيتها وتحديثها في مجموعة، على غرار عمليات تطوير التطبيقات العادية.

يمكن إتاحة الوظائف الإضافية لمشغل الوظيفة الإضافية بتنسيق الوحدة النمطية (مخطط الخوذة + الخطافات) للعامة. نحن، شركة فلانت، نخطط لنشر تطوراتنا في شكل مثل هذه الإضافات خلال فصل الصيف. انضم إلى التطوير على GitHub (مشغل القشرة, عامل إضافي) ، حاول إجراء الإضافة الخاصة بك بناءً على ذلك أمثلة и توثيق، انتظر الأخبار عن حبري وعلى موقعنا قناة يوتيوب!

PS

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

هل من السهل والمريح تحضير مجموعة Kubernetes؟ الإعلان عن عامل إضافي