تقديم Kubernetes CCM (مدير وحدة التحكم السحابية) لـ Yandex.Cloud

استمرارا لما حدث مؤخرا إصدار برنامج تشغيل CSI بالنسبة لـ Yandex.Cloud، نقوم بنشر مشروع آخر مفتوح المصدر لهذه السحابة - مدير وحدة التحكم السحابية. CCM مطلوب ليس فقط للمجموعة ككل، ولكن أيضًا لبرنامج تشغيل CSI نفسه. التفاصيل حول الغرض منه وبعض ميزات التنفيذ قيد الخفض.

مقدمة

لماذا هذا؟

الدوافع التي دفعتنا إلى تطوير CCM لـ Yandex.Cloud تتطابق تمامًا مع تلك الموضحة بالفعل في إعلان برامج تشغيل منظمة التضامن المسيحي الدولية. نحن نحتفظ بالعديد من مجموعات Kubernetes من موفري الخدمات السحابية المختلفين، والتي نستخدم من أجلها أداة واحدة. إنها تنفذ العديد من وسائل الراحة "لتجاوز" الحلول المُدارة لهؤلاء المزودين. نعم، لدينا حالة واحتياجات محددة إلى حد ما، ولكن التطورات التي تم إنشاؤها بسببها قد تكون مفيدة للمستخدمين الآخرين.

ما هو بالضبط CCM؟

عادة، نقوم بإعداد البيئة المحيطة بنا للكتلة من الخارج - على سبيل المثال، باستخدام Terraform. لكن في بعض الأحيان تكون هناك حاجة لإدارة البيئة السحابية من حولنا من الكتلة. هذه الإمكانية مقدمة، وهي التي يتم تنفيذها CCM.

على وجه التحديد، يوفر Cloud Controller Manager خمسة أنواع رئيسية من التفاعل:

1. الحالات - تنفيذ علاقة 1:1 بين كائن العقدة في Kubernetes (Node) وجهاز افتراضي في موفر السحابة. لهذا نحن:
   • املأ الحقل spec.providerID في الكائن Node. على سبيل المثال، بالنسبة لـ OpenStack CCM، يكون لهذا الحقل التنسيق التالي: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. يمكنك رؤية اسم موفر السحابة وUUID الفريد للخادم (الجهاز الظاهري في OpenStack) للكائن؛
   • إطراء nodeInfo في الكائن Node معلومات حول الجهاز الظاهري. على سبيل المثال، نحدد نوع المثيل في AWS؛
   • نتحقق من وجود جهاز افتراضي في السحابة. على سبيل المثال، إذا كان الكائن Node ذهب إلى حالة NotReady، يمكنك التحقق مما إذا كان الجهاز الظاهري موجودًا على الإطلاق في موفر السحابة من خلال providerID. إذا لم يكن هناك، حذف الكائن Node، والتي لولا ذلك لبقيت في المجموعة إلى الأبد؛
2. مناطق - يعين مجال الفشل للكائن Node، بحيث يمكن للمجدول تحديد عقدة للكبسولة وفقًا للمناطق والمناطق الموجودة في موفر السحابة؛
3. LoadBalancer - عند إنشاء كائن Service مع النوع LoadBalancer ينشئ نوعًا من الموازن الذي يوجه حركة المرور من الخارج إلى عقد المجموعة. على سبيل المثال، في Yandex.Cloud يمكنك استخدامه NetworkLoadBalancer и TargetGroup لهذه الأغراض؛
4. طريق - يبني شبكة بين العقد، لأن وفقًا لمتطلبات Kubernetes، يجب أن يكون لكل حجرة عنوان IP خاص بها وأن تكون قادرة على الوصول إلى أي حجرة أخرى. لهذه الأغراض، يمكنك استخدام شبكة متراكبة (VXLAN، GENEVE) أو تعيين جدول توجيه مباشرة في الشبكة الافتراضية لموفر السحابة:

   

5. الصوت – يسمح بالترتيب الديناميكي للطاقة الكهروضوئية باستخدام PVC وSC. في البداية، كانت هذه الوظيفة جزءًا من CCM، ولكن نظرًا لتعقيدها الكبير، تم نقلها إلى مشروع منفصل، واجهة تخزين الحاويات (CSI). لقد تحدثنا عن CSI أكثر من مرة писали وكما سبق ذكره، حتى صدر سائق منظمة التضامن المسيحي الدولية.

في السابق، كانت جميع التعليمات البرمجية التي تتفاعل مع السحابة موجودة في مستودع Git الرئيسي لمشروع Kubernetes على k8s.io/kubernetes/pkg/cloudprovider/providers، لكنهم قرروا التخلي عن هذا بسبب إزعاج العمل مع قاعدة رموز كبيرة. تم نقل كافة التطبيقات القديمة إلى مستودع منفصل. ولتسهيل الحصول على مزيد من الدعم والتطوير، تم أيضًا نقل جميع المكونات المشتركة إلى مستودع منفصل.

كما هو الحال مع CSI، قام العديد من موفري الخدمات السحابية الكبار بتصميم CCMs الخاصة بهم بالفعل للاستفادة من السحابات في Kubernetes. إذا لم يكن المورد لديه CCM، ولكن جميع الوظائف الضرورية متاحة عبر واجهة برمجة التطبيقات (API)، فيمكنك تنفيذ CCM بنفسك.

لكتابة تطبيق CCM الخاص بك، يكفي التنفيذ واجهات Go المطلوبة.

И وهذا هو ما حصلنا عليه.

تطبيق

كيف أتيت إلى هذا

لقد بدأنا التطوير (أو بالأحرى حتى الاستخدام) مع جاهز(!) CCM لـ Yandex.Cloud قبل عام.

ومع ذلك، في هذا التنفيذ كنا في عداد المفقودين:

• المصادقة عبر رمز JWT IAM؛
• دعم وحدة تحكم الخدمة.

بالاتفاق مع المؤلف (دلسين) في Telegram، قمنا بتكوين yandex-cloud-controller-manager وأضفنا الوظائف المفقودة.

الميزات الرئيسية

حاليًا، يدعم CCM الواجهات التالية:

• الحالات;
• مناطق;
• LoadBalancer.

في المستقبل، عندما يبدأ Yandex.Cloud العمل مع إمكانيات VPC المتقدمة، سنضيف واجهة طرق.

LoadBalancer باعتباره التحدي الرئيسي

في البداية، حاولنا، مثل تطبيقات CCM الأخرى، إنشاء زوج من LoadBalancer и TargetGroup لكل Service مع النوع LoadBalancer. ومع ذلك، اكتشف Yandex.Cloud قيدًا واحدًا مثيرًا للاهتمام: لا يمكنك استخدامه TargetGroups مع التقاطع Targets (زوج SubnetID - IpAddress).

لذلك، داخل CCM الذي تم إنشاؤه، يتم تشغيل وحدة التحكم، والتي، عندما تتغير الكائنات Node يجمع معلومات حول جميع الواجهات الموجودة على كل جهاز افتراضي، ويجمعها وفقًا لانتمائها إلى جهاز معين NetworkID، ينشئ بواسطة TargetGroup في NetworkID، ويراقب أيضًا مدى ملاءمتها. وبعد ذلك، عند إنشاء كائن Service مع النوع LoadBalanacer نحن ببساطة نعلق تم إنشاؤها مسبقا TargetGroup إلى New NetworkLoadBalanacer'أكون.

كيف تبدأ في استخدامه؟

يدعم CCM الإصدار 1.15 من Kubernetes والإصدارات الأحدث. في المجموعة، لكي تعمل، يتطلب الأمر وضع العلم --cloud-provider=external تم تعيينه على true لـ kube-apserver، وkube-controller-manager، وkube-scheduler، وجميع kubelets.

تم توضيح جميع الخطوات اللازمة للتثبيت نفسه في README. يتلخص التثبيت في إنشاء كائنات في Kubernetes من البيانات.

لاستخدام CCM ستحتاج أيضًا إلى:

• تحديد في البيان معرف الدليل (folder-id) Yandex.Cloud؛
• حساب الخدمة للتفاعل مع Yandex.Cloud API. في البيان Secret يجب نقل المفاتيح المعتمدة من حساب الخدمة في الوثائق وصفهاكيفية إنشاء حساب الخدمة والحصول على المفاتيح.

سنكون سعداء لتلقي ملاحظاتك و قضايا جديدةإذا واجهت أي مشاكل!

نتائج

لقد استخدمنا CCM المطبق في خمس مجموعات Kubernetes على مدار الأسبوعين الماضيين ونخطط لزيادة عددها إلى 20 في الشهر المقبل. لا نوصي حاليًا باستخدام CCM لعمليات تثبيت K8 الكبيرة والحرجة.

كما هو الحال مع CSI، سنكون سعداء إذا تولى مطورو Yandex تطوير ودعم هذا المشروع - فنحن على استعداد لنقل المستودع بناءً على طلبهم للتعامل مع المهام الأكثر صلة بنا.

PS

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

• «خبرتنا في تطوير برنامج تشغيل CSI في Kubernetes لـ Yandex.Cloud"؛
• «هل من السهل والمريح تحضير مجموعة Kubernetes؟ الإعلان عن عامل إضافي"؛
• «توسيع واستكمال Kubernetes (نظرة عامة وتقرير فيديو)".

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