🥇تجربتنا في تطوير برنامج تشغيل CSI في Kubernetes لـ Yandex.Cloud

يسعدنا أن نعلن أن Flant تعمل على توسيع مساهمتها في الأدوات مفتوحة المصدر لـ Kubernetes من خلال إطلاقها نسخة ألفا من برنامج تشغيل CSI (واجهة تخزين الحاويات) لـ Yandex.Cloud.

ولكن قبل الانتقال إلى تفاصيل التنفيذ، دعنا نجيب على سؤال لماذا هناك حاجة لذلك على الإطلاق عندما يكون لدى Yandex بالفعل خدمة الخدمة المُدارة لـ Kubernetes.

مقدمة

لماذا هذا؟

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

تحتوي المجموعات التي تستخدم سطح السفينة على جميع المكونات اللازمة للتشغيل: الموازنات، والمراقبة باستخدام المخططات والمقاييس والتنبيهات الملائمة، ومصادقة المستخدم من خلال موفري خدمات خارجيين للوصول إلى جميع لوحات المعلومات، وما إلى ذلك. ليس من المنطقي تثبيت مثل هذه المجموعة "المضخّمة" في حل مُدار، لأن هذا غالبًا ما يكون مستحيلًا أو سيؤدي إلى الحاجة إلى تعطيل نصف المكونات.

NB: هذه هي تجربتنا، وهي محددة تماما. نحن لا نقترح بأي حال من الأحوال أنه يجب على الجميع نشر مجموعات Kubernetes بمفردهم بدلاً من استخدام الحلول الجاهزة. بالمناسبة، ليس لدينا خبرة حقيقية في تشغيل Kubernetes من Yandex ولن نقدم أي تقييم لهذه الخدمة في هذه المقالة.

ما هو ولمن؟

لذلك، تحدثنا بالفعل عن النهج الحديث للتخزين في Kubernetes: كيف تعمل منظمة التضامن المسيحي الدولية؟ и كيف جاء المجتمع لهذا النهج.

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

اتخذنا كأساس للتنمية برنامج تشغيل CSI لسحابة DigitalOcean واثنين من الأفكار من برامج تشغيل GCPنظرًا لأن التفاعل مع واجهة برمجة التطبيقات الخاصة بهذه السحب (Google وYandex) به عدد من أوجه التشابه. على وجه الخصوص، API و GCPو و في ياندكس إرجاع كائن Operation لتتبع حالة العمليات طويلة الأمد (على سبيل المثال، إنشاء قرص جديد). للتفاعل مع Yandex.Cloud API، استخدم Yandex.Cloud الذهاب SDK.

نتيجة العمل المنجز تم النشر على جيثب وقد يكون مفيدًا لأولئك الذين يستخدمون، لسبب ما، تثبيت Kubernetes الخاص بهم على الأجهزة الافتراضية Yandex.Cloud (ولكن ليس مجموعة مُدارة جاهزة) ويرغبون في استخدام (طلب) الأقراص من خلال CSI.

تطبيق

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

يدعم برنامج التشغيل حاليًا الوظائف التالية:

ترتيب الأقراص في جميع مناطق المجموعة وفقًا لطوبولوجيا العقد الموجودة في المجموعة؛
إزالة الأقراص المطلوبة مسبقًا؛
تغيير حجم الأقراص دون الاتصال بالإنترنت (Yandex.Cloud لا تدعم زيادة الأقراص المثبتة على الجهاز الظاهري). للحصول على معلومات حول كيفية تعديل برنامج التشغيل لجعل تغيير الحجم غير مؤلم قدر الإمكان، انظر أدناه.

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

الصعوبة الرئيسية وكيفية التغلب عليها

يعد عدم القدرة على زيادة الأقراص في الوقت الفعلي في Yandex.Cloud API بمثابة قيد يعقد عملية تغيير الحجم لـ PV (الحجم الثابت): في هذه الحالة، من الضروري إيقاف جراب التطبيق الذي يستخدم القرص، وهذا يمكن أن يسبب تطبيقات التوقف.

وفق مواصفات سي اس اي، إذا أبلغت وحدة تحكم CSI أنه يمكنها تغيير حجم الأقراص فقط "في وضع عدم الاتصال" (VolumeExpansion.OFFLINE)، فإن عملية زيادة القرص يجب أن تتم على النحو التالي:

إذا كان البرنامج المساعد لديه فقط VolumeExpansion.OFFLINE يتم حاليًا نشر إمكانية التوسعة والحجم أو توفرها على العقدة ControllerExpandVolume يجب أن يتم الاتصال به فقط بعد أي مما يلي:

البرنامج المساعد لديه وحدة تحكم PUBLISH_UNPUBLISH_VOLUME القدرة و ControllerUnpublishVolume تم استدعاؤه بنجاح.

او اخرى

البرنامج المساعد لا يحتوي على وحدة تحكم PUBLISH_UNPUBLISH_VOLUME القدرة، البرنامج المساعد لديه عقدة STAGE_UNSTAGE_VOLUME القدرة، و NodeUnstageVolume تم الانتهاء بنجاح.

او اخرى

البرنامج المساعد لا يحتوي على وحدة تحكم PUBLISH_UNPUBLISH_VOLUME القدرة، ولا عقدة STAGE_UNSTAGE_VOLUME القدرة، و NodeUnpublishVolume اكتمل بنجاح.

وهذا يعني في الأساس أنك بحاجة إلى فصل القرص عن الجهاز الظاهري قبل توسيعه.

ومع ذلك، للأسف تطبيق لا تلبي مواصفات CSI عبر السيارات الجانبية هذه المتطلبات:

في حاوية جانبية csi-attacher، والتي يجب أن تكون مسؤولة عن وجود الفجوة المطلوبة بين الحوامل، هذه الوظيفة ببساطة لم يتم تنفيذها في تغيير الحجم دون الاتصال بالإنترنت. وقد بدأ النقاش حول هذا الأمر هنا.
ما هي بالضبط الحاوية الجانبية في هذا السياق؟ لا يتفاعل المكون الإضافي CSI نفسه مع واجهة برمجة تطبيقات Kubernetes، ولكنه يستجيب فقط لاستدعاءات gRPC المرسلة إليه بواسطة الحاويات الجانبية. أحدث يجري تطويرها من قبل مجتمع Kubernetes.

في حالتنا (المكون الإضافي CSI)، تبدو عملية زيادة القرص كما يلي:

نتلقى مكالمة gRPC ControllerExpandVolume;
نحاول زيادة القرص في واجهة برمجة التطبيقات، ولكننا نتلقى خطأً حول استحالة إجراء العملية بسبب تثبيت القرص؛
نقوم بتخزين معرف القرص في الخريطة، التي تحتوي على الأقراص التي يجب إجراء عملية الزيادة عليها. أدناه، للإيجاز، سوف نسمي هذه الخريطة باسم volumeResizeRequired;
قم بإزالة الكبسولة التي تستخدم القرص يدويًا. سيقوم Kubernetes بإعادة تشغيله. بحيث لا يتوفر للقرص وقت للتثبيت (ControllerPublishVolume) قبل إكمال عملية الزيادة عند محاولة التثبيت، نتحقق من أن القرص المحدد لا يزال موجودًا volumeResizeRequired وإرجاع خطأ؛
يحاول برنامج تشغيل CSI إعادة تنفيذ عملية تغيير الحجم. إذا كانت العملية ناجحة، فقم بإزالة القرص من volumeResizeRequired;
لأن معرف القرص مفقود من volumeResizeRequired, ControllerPublishVolume يتم تمريره بنجاح، ويتم تركيب القرص، وتبدأ الكبسولة.

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

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

يمكن أن يؤدي ذلك بشكل دوري إلى تمديد عملية توسيع القرص لمدة تزيد عن 15 دقيقة، وبالتالي عدم توفر الكبسولة المقابلة.

كان الخيار الوحيد الذي سمح لنا بسهولة وبدون ألم بتقليل وقت التوقف عن العمل المحتمل هو استخدام إصدارنا من أداة تغيير الحجم الخارجية مع الحد الأقصى للمهلة في 5 ثواني:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

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

برنامج التشغيل مدعوم على الإصدار 1.15 من Kubernetes والإصدارات الأحدث. لكي يعمل السائق، يجب استيفاء المتطلبات التالية:

علم --allow-privileged تعيين على القيمة true لخادم API وkubelet؛
متضمنة --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true لخادم API وkubelet؛
انتشار جبل (انتشار جبل) يجب تمكينه على المجموعة. عند استخدام Docker، يجب تكوين البرنامج الخفي للسماح بالتثبيتات المشتركة.

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

لكي يعمل السائق، ستحتاج إلى ما يلي:

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

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

مزيد من الدعم

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

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

PS

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

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

خبرتنا في تطوير برنامج تشغيل CSI في Kubernetes لـ Yandex.Cloud