Yandex.Cloud لاءِ Kubernetes ۾ CSI ڊرائيور ٺاهڻ ۾ اسان جو تجربو

اسان کي اهو اعلان ڪندي خوشي ٿي رهي آهي ته فلانٽ جاري ڪري Kubernetes لاءِ اوپن سورس ٽولز ۾ پنهنجو حصو وڌائي رهيو آهي. CSI ڊرائيور جو الفا ورزن (ڪنٽينر اسٽوريج انٽرفيس) Yandex.Cloud لاءِ.

پر عمل درآمد جي تفصيلن تي وڃڻ کان اڳ، اچو ته سوال جو جواب ڏيو ڇو ته اهو سڀ ڪجهه ضروري آهي جڏهن Yandex اڳ ۾ ئي هڪ خدمت آهي. Kubernetes لاءِ منظم ڪيل خدمت.

تعارف

ائين ڇو آهي؟

اسان جي ڪمپني جي اندر، پيداوار ۾ ڪبرنيٽس استعمال ڪرڻ جي شروعات کان وٺي (يعني ڪيترن ئي سالن کان)، اسان پنهنجو پنهنجو اوزار (ڊيڪ هائوس) ٺاهي رهيا آهيون، جنهن جي ذريعي، اسان جلد ئي هڪ اوپن سورس پروجيڪٽ جي طور تي دستياب ڪرڻ جو منصوبو پڻ ڪريون ٿا. . ان جي مدد سان، اسان هڪجهڙائي سان اسان جي سڀني ڪلسٽرن کي ترتيب ۽ ترتيب ڏيون ٿا، ۽ هن وقت انهن مان 100 کان وڌيڪ آهن، هارڊويئر ترتيبن جي وسيع قسم تي ۽ سڀني دستياب ڪلائوڊ سروسز ۾.

ڪلستر جيڪي ڊيڪ هاؤس استعمال ڪندا آهن انهن ۾ آپريشن لاءِ تمام ضروري جزا آهن: بيلنسرز، مانيٽرنگ سان آسان چارٽس، ميٽرڪس ۽ الرٽ، صارف جي تصديق سڀني ڊيش بورڊز تائين پهچ لاءِ خارجي فراهم ڪندڙن ذريعي، وغيره. منظم حل ۾ اهڙي "پمپ اپ" ڪلستر کي نصب ڪرڻ جو ڪو به مقصد ناهي، ڇاڪاڻ ته اهو اڪثر ڪري ناممڪن آهي يا اڌ حصن کي غير فعال ڪرڻ جي ضرورت آهي.

NB: هي اسان جو تجربو آهي، ۽ اهو ڪافي مخصوص آهي. اسان ڪنهن به طريقي سان اهو مشورو نه ڏيون ٿا ته هرڪو تيار ڪيل حل استعمال ڪرڻ جي بدران پنهنجو پاڻ تي ڪبرنيٽس ڪلستر کي ترتيب ڏيڻ گهرجي. رستي ۾، اسان وٽ Yandex کان Kubernetes کي هلائڻ ۾ ڪو به حقيقي تجربو نه آهي ۽ اسان هن مضمون ۾ هن خدمت جي ڪا به تشخيص نه ڏينداسين.

اهو ڇا آهي ۽ ڪنهن لاء؟

تنهن ڪري، اسان اڳ ۾ ئي Kubernetes ۾ اسٽوريج جي جديد طريقي بابت ڳالهايو آهي: CSI ڪيئن ڪم ڪندو آهي؟ и ڪميونٽي ڪيئن آئي هن طريقي ڏانهن.

في الحال، ڪيترن ئي وڏن ڪلائوڊ سروس فراهم ڪندڙ ڊرائيورز ٺاهيا آهن انهن جي ڪلائوڊ ڊسڪ کي ڪبرنيٽس ۾ مستقل حجم طور استعمال ڪرڻ لاءِ. جيڪڏهن فراهم ڪندڙ وٽ اهڙي ڊرائيور نه آهي، پر سڀئي ضروري افعال API ذريعي مهيا ڪيا ويا آهن، پوء ڪجھ به توهان کي ڊرائيور کي لاڳو ڪرڻ کان روڪي نه ٿو. اھو اھو آھي جيڪو Yandex.Cloud سان ٿيو.

اسان ترقي جي بنياد تي ورتو ڊجيٽل اوشن ڪلائوڊ لاءِ CSI ڊرائيور ۽ مان ڪجھ خيالات GCP لاء ڊرائيور، ڇاڪاڻ ته انهن بادل جي API سان رابطي ۾ (گوگل ۽ Yandex) ڪيتريون ئي هڪجهڙائيون آهن. خاص طور تي، API ۽ جي سي پي، ۽ ي ياندڪس هڪ اعتراض واپس Operation ڊگھي هلندڙ عملن جي حالت کي ٽريڪ ڪرڻ لاء (مثال طور، نئين ڊسڪ ٺاهڻ). Yandex.Cloud API سان رابطو ڪرڻ لاء، استعمال ڪريو Yandex.Cloud Go SDK.

ڪيل ڪم جو نتيجو GitHub تي شايع ٿيل ۽ انهن لاءِ ڪارائتو ٿي سگهي ٿو جيڪي، ڪنهن سبب جي ڪري، Yandex.Cloud ورچوئل مشينن تي پنهنجون Kubernetes تنصيب استعمال ڪن ٿا (پر تيار ٿيل منظم ڪيل ڪلستر نه) ۽ CSI ذريعي ڊسڪ (آرڊر) استعمال ڪرڻ چاهيندا.

عمل

مکيه خاصيتون

في الحال ڊرائيور هيٺين ڪمن کي سپورٽ ڪري ٿو:

• ڪلستر ۾ نوڊس جي ٽوپولوجي جي مطابق ڪلستر جي سڀني علائقن ۾ ڊسڪ ترتيب ڏيڻ؛
• اڳوڻي حڪم ڪيل ڊسڪ کي هٽائڻ؛
• ڊسڪ لاءِ آف لائن ريسائز (Yandex.Cloud حمايت نه ڪريو ڊسڪ کي وڌايو جيڪي ورچوئل مشين تي نصب ٿيل آهن). معلومات لاءِ ته ڪيئن ڊرائيور کي تبديل ڪرڻو پيو ته جيئن ريزيزنگ کي ممڪن طور تي بي درد بڻائي، هيٺ ڏسو.

مستقبل ۾، اسان ڊسڪ سنيپ شاٽ ٺاهڻ ۽ حذف ڪرڻ لاءِ سپورٽ لاڳو ڪرڻ جو منصوبو ڪريون ٿا.

بنيادي مشڪل ۽ ان کي ڪيئن ختم ڪرڻ

Yandex.Cloud API ۾ حقيقي وقت ۾ ڊسڪ کي وڌائڻ جي صلاحيت جي کوٽ هڪ حد آهي جيڪا PV (مسلسل حجم) لاء ريزائز آپريشن کي پيچيده ڪري ٿي: انهي صورت ۾، اهو ضروري آهي ته ايپليڪيشن پوڊ جيڪو ڊسڪ استعمال ڪري ٿو، بند ڪيو وڃي. ۽ اهو سبب ڪري سگهي ٿو ڊائون لوڊ ايپليڪيشنون.

جي مطابق CSI وضاحتون، جيڪڏهن 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 پلگ ان پاڻ ڪبرنيٽس API سان رابطو نٿو ڪري، پر صرف سائڊ ڪار ڪنٽينرز طرفان موڪليل gRPC ڪالن جو جواب ڏئي ٿو. تازو ترقي ڪري رهيا آهن Kubernetes ڪميونٽي طرفان.

اسان جي صورت ۾ (CSI پلگ ان)، ڊسڪ کي وڌائڻ جو عمل هن طرح نظر اچي ٿو:

1. اسان هڪ gRPC ڪال وصول ڪندا آهيون ControllerExpandVolume;
2. اسان API ۾ ڊسڪ کي وڌائڻ جي ڪوشش ڪري رهيا آهيون، پر اسان کي آپريشن ڪرڻ جي ناممڪن بابت غلطي ملي ٿي ڇو ته ڊسڪ نصب ٿيل آهي؛
3. اسان ڊسڪ جي سڃاڻپ ڪندڙ کي نقشي ۾ ذخيرو ڪندا آهيون، جنهن ۾ اهي ڊسڪ شامل آهن جن لاءِ آپريشن کي وڌائڻ جي ضرورت آهي. هيٺ، اختصار لاءِ، اسان هن نقشي کي سڏينداسين volumeResizeRequired;
4. دستي طور پوڊ کي هٽايو جيڪو ڊسڪ استعمال ڪري رهيو آهي. Kubernetes ان کي ٻيهر شروع ڪندو. انهي ڪري ته ڊسڪ کي نصب ڪرڻ جو وقت نه آهي (ControllerPublishVolume) وڌائڻ واري آپريشن کي مڪمل ڪرڻ کان اڳ جڏهن مائونٽ ڪرڻ جي ڪوشش ڪئي وڃي، اسان چيڪ ڪريون ٿا ته ڏنل ڊسڪ اڃا اندر آهي volumeResizeRequired ۽ هڪ غلطي واپس؛
5. سي ايس آئي ڊرائيور ڪوشش ڪري ٿو ٻيهر عمل ڪرڻ واري عمل کي ٻيهر ڪرڻ جي. جيڪڏهن آپريشن ڪامياب ٿي ويو، پوء ڊسڪ کي هٽائي ڇڏيو volumeResizeRequired;
6. ڇاڪاڻ ته مان ڊسڪ ID غائب آهي 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)

اسان ان کي ضروري نه سمجهيو ته فوري طور تي بحث شروع ڪيو وڃي ۽ خارجي-رائزر کي پيچ ڪيو وڃي، ڇاڪاڻ ته ڊسڪ جي آف لائن ريزائز هڪ اڇلائي آهي جيڪا جلد ئي سڀني ڪلائوڊ فراهم ڪندڙن کان غائب ٿي ويندي.

ڪيئن استعمال ڪرڻ شروع ڪرڻ لاء؟

ڊرائيور کي سپورٽ ڪيو ويو آهي Kubernetes ورزن 1.15 ۽ وڌيڪ. ڊرائيور کي ڪم ڪرڻ لاء، هيٺين گهرجن کي پورو ڪرڻ گهرجي:

• پرچم --allow-privileged قدر تي مقرر true API سرور ۽ ڪوبيليٽ لاءِ؛
• شامل --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API سرور ۽ ڪوبيليٽ لاءِ؛
• جبل جي پکيڙ (جبل جي تبليغ) ڪلستر تي فعال ٿيڻ گھرجي. جڏهن ڊاکر استعمال ڪندي، ڊيمن کي ترتيب ڏيڻ گهرجي ته شيئر مائونٽ جي اجازت ڏيڻ لاء.

انسٽاليشن لاء سڀ ضروري قدم پاڻ README ۾ بيان ڪيل. تنصيب شامل آهي ڪبرنيٽس ۾ شيون ٺاهي منشور مان.

ڊرائيور کي ڪم ڪرڻ لاءِ توھان کي ھيٺين شين جي ضرورت پوندي:

• منشور ۾ ڊاريڪٽري جي سڃاڻپ ڪندڙ بيان ڪريو (folder-id) Yandex.Cloud (دستاويز ڏسو);
• Yandex.Cloud API سان رابطو ڪرڻ لاء، CSI ڊرائيور هڪ خدمت اڪائونٽ استعمال ڪري ٿو. ظاهر ۾، راز پاس ٿيڻ گهرجي اختيار ڪيل چابيون سروس اڪائونٽ مان. دستاويز ۾ بيان ڪيل, ڪيئن ٺاهيو هڪ خدمت اڪائونٽ ۽ چابيون حاصل ڪرڻ لاء.

سڀ ڪجهه - ڪوشش ڪر، ۽ اسان کي راءِ حاصل ڪرڻ ۾ خوشي ٿيندي ۽ نوان مسئلاجيڪڏهن توهان ڪنهن پريشاني سان منهن ڪيو!

وڌيڪ حمايت

نتيجي طور، اسان اهو نوٽ ڪرڻ چاهيون ٿا ته اسان هن CSI ڊرائيور تي عمل ڪيو، گو ۾ لکڻ جي ايپليڪيشنن کي مزو ڏيڻ جي وڏي خواهش کان ٻاهر نه، پر ڪمپني جي اندر هڪ تڪڙي ضرورت جي ڪري. اهو اسان لاء عملي نه ٿو لڳي ته اسان جي پنهنجي عمل کي برقرار رکون، تنهنڪري جيڪڏهن Yandex دلچسپي ڏيکاري ٿو ۽ ڊرائيور جي حمايت جاري رکڻ جو فيصلو ڪري ٿو، اسان انهن کي مخزن کي منتقل ڪرڻ ۾ خوش ٿينداسين.

ان کان علاوه، Yandex شايد CSI ڊرائيور جي پنهنجي منظم ڪيل ڪبرنيٽس ڪلستر ۾ لاڳو ٿئي ٿي، جيڪا اوپن سورس ۾ جاري ٿي سگهي ٿي. اسان هن ڊولپمينٽ آپشن کي به سازگار طور ڏسندا آهيون - ڪميونٽي هڪ خدمت فراهم ڪندڙ کان ثابت ڊرائيور استعمال ڪرڻ جي قابل هوندو، ۽ ٽئين پارٽي جي ڪمپني کان نه.

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «ڪبرنيٽس اسٽوريج لاءِ حجم پلگ ان: Flexvolume کان CSI تائين"؛
• «اسان سمجھون ٿا ڪنٽينر اسٽوريج انٽرفيس (ڪيبرنيٽس ۾ ۽ نه رڳو)"؛
• «ڇا اهو آسان ۽ آسان آهي هڪ Kubernetes ڪلستر تيار ڪرڻ؟ اضافو آپريٽر جو اعلان"؛
• «ڪبرنيٽس کي وڌائڻ ۽ مڪمل ڪرڻ (جائزو ۽ وڊيو رپورٽ)».

جو ذريعو: www.habr.com