د Yandex.Cloud لپاره په Kubernetes کې د CSI ډرایور رامینځته کولو کې زموږ تجربه

موږ خوښ یو چې اعلان کوو چې فلانټ د خوشې کولو له لارې د Kubernetes لپاره د خلاصې سرچینې وسیلو کې خپله ونډه پراخه کوي د CSI ډرایور الفا نسخه (د کانټینر ذخیره کولو انٹرفیس) د Yandex.Cloud لپاره.

مګر مخکې لدې چې د پلي کولو توضیحاتو ته لاړشئ ، راځئ دې پوښتنې ته ځواب ووایو چې ولې دې ته اړتیا لیدل کیږي کله چې یاندیکس دمخه خدمت لري د Kubernetes لپاره اداره شوی خدمت.

پېژندنه

دا ولې؟

زموږ په شرکت کې ، په تولید کې د کبرنیټس کارولو له پیل څخه (یعنې د څو کلونو راهیسې) ، موږ خپل وسیله (ډیک هاؤس) رامینځته کوو ، کوم چې له مخې یې موږ پلان لرو چې ډیر ژر د خلاصې سرچینې پروژې په توګه چمتو کړو. . د دې په مرسته، موږ خپل ټول کلسترونه په مساوي ډول تنظیم او تنظیم کوو، او دا مهال د دوی له 100 څخه ډیر شتون لري، په پراخه کچه د هارډویر ترتیباتو او ټولو موجود کلاوډ خدماتو کې.

هغه کلسترونه چې د ډیک هاؤس کاروي د عملیاتو لپاره ټولې اړینې برخې لري: بیلانسونه، د مناسب چارټونو سره څارنه، میټریکونه او خبرتیاوې، ټولو ډشبورډونو ته د لاسرسي لپاره د بهرني چمتو کونکو له لارې د کارونکي تصدیق، او داسې نور. په اداره شوي حل کې د داسې "پمپ اپ" کلستر نصبولو کې هیڅ معنی نشته، ځکه چې دا اکثرا یا ناممکن وي یا د نیمایي برخو غیر فعالولو اړتیا ته الر پیدا کوي.

NB: دا زموږ تجربه ده، او دا خورا مشخصه ده. موږ په هیڅ ډول وړاندیز نه کوو چې هرڅوک باید د چمتو شوي حلونو کارولو پرځای پخپله د کبرنیټ کلسترونه ځای په ځای کړي. په هرصورت، موږ د Yandex څخه Kubernetes په چلولو کې ریښتینې تجربه نلرو او موږ به پدې مقاله کې د دې خدمت کومه ارزونه ونه کړو.

څه شی دی او د چا لپاره؟

نو، موږ لا دمخه په کوبرنیټس کې د ذخیره کولو عصري طریقې په اړه خبرې کړې دي: CSI څنګه کار کوي؟ и څنګه ټولنه راغله دې طریقې ته.

اوس مهال، ډیری لوی کلاوډ خدمت چمتو کونکو په کبرنیټس کې د دوامداره حجم په توګه د دوی کلاوډ ډیسک کارولو لپاره ډرایورونه رامینځته کړي. که عرضه کونکی داسې ډرایور ونه لري، مګر ټولې اړینې دندې د API له لارې چمتو شوي، نو هیڅ شی به تاسو پخپله د ډرایور پلي کولو مخه ونه نیسي. دا هغه څه دي چې د Yandex.Cloud سره پیښ شوي.

موږ د پرمختګ لپاره د اساس په توګه اخیستی د ډیجیټل اوشین کلاوډ لپاره د CSI ډرایور او څخه یو څو نظریات د GCP لپاره چلوونکي، ځکه چې د دې بادلونو API سره متقابل عمل (ګوګل او یانډیکس) یو شمیر ورته والی لري. په ځانګړې توګه، API او GCP، او y Yandex یو شی بیرته راستانه کړئ 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 پلگ ان پخپله د Kubernetes API سره تعامل نه کوي، مګر یوازې د gRPC تلیفونونو ته ځواب ورکوي چې د سایډ کار کانټینرونو لخوا ورته لیږل شوي. وروستی وده کوي د Kubernetes ټولنې لخوا.

زموږ په قضیه کې (CSI پلگ ان) ، د ډیسک زیاتولو عملیات داسې ښکاري:

1. موږ د gRPC تلیفون ترلاسه کوو ControllerExpandVolume;
2. موږ هڅه کوو چې په API کې ډیسک زیات کړو، مګر موږ د عملیاتو ترسره کولو ناشونیتیا په اړه یوه تېروتنه ترلاسه کوو ځکه چې ډیسک نصب شوی؛
3. موږ د ډیسک پیژندونکی په نقشه کې ذخیره کوو، کوم چې هغه ډیسکونه لري چې د زیاتوالي عملیات ترسره کولو ته اړتیا لري. لاندې، د لنډیز لپاره، موږ به دې نقشې ته ووایو volumeResizeRequired;
4. په لاسي ډول هغه پوډ لرې کړئ چې ډیسک کاروي. Kubernetes به دا بیا پیل کړي. نو د دې لپاره چې ډیسک د نصبولو وخت ونه لري (ControllerPublishVolume) مخکې له دې چې د زیاتوالي عملیاتو بشپړولو په وخت کې د نصبولو هڅه وکړو، موږ ګورو چې ورکړل شوی ډیسک لاهم دننه دی volumeResizeRequired او یوه تېروتنه راګرځوي؛
5. د CSI ډرایور هڅه کوي د بیا اندازې عملیات بیا اجرا کړي. که عملیات بریالي وي، نو بیا ډیسک لرې کړئ 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 سرور او کبلیټ لپاره؛
• د تکثیر غره (mount propagation) باید په کلستر کې فعال شي. کله چې د ډاکر کاروئ ، ډیمون باید تنظیم شي ترڅو د شریک ماونټونو ته اجازه ورکړي.

د نصبولو لپاره ټول اړین ګامونه پخپله په README کې تشریح شوی. په نصب کې د منشور څخه په کبرنیټس کې د شیانو رامینځته کول شامل دي.

د موټر چلوونکي کار کولو لپاره تاسو به لاندې ته اړتیا ولرئ:

• په منشور کې د لارښود پیژندونکی مشخص کړئ (folder-id) Yandex.Cloud (اسناد وګورئ);
• د Yandex.Cloud API سره د تعامل لپاره، د CSI ډرایور د خدماتو حساب کاروي. په ښکاره کې، راز باید تیر شي مجاز کیلي د خدمت حساب څخه. په اسنادو کې بیان شوید خدماتو حساب څنګه جوړ کړئ او کیلي ترلاسه کړئ.

ټول په ټولو کښې - هڅه وکړئ، او موږ به خوښ یو چې فیډبیک ترلاسه کړو او نوې مسلېکه تاسو له کومې ستونزې سره مخ شئ!

نور ملاتړ

د پایلې په توګه، موږ غواړو یادونه وکړو چې موږ دا CSI ډرایور په Go کې د ساتیرۍ لیکلو غوښتنلیکونو لپاره د یوې لویې لیوالتیا څخه نه، بلکې په شرکت کې د بیړنۍ اړتیا له امله پلي کړی. دا زموږ لپاره عملي نه بریښي چې خپل پلي کول وساتو ، نو که Yandex علاقه وښيي او پریکړه وکړي چې د ډرایور ملاتړ ته دوام ورکړي ، موږ به خوښ یو چې دوی ته ذخیره انتقال کړو.

سربیره پردې، Yandex شاید په خپل اداره شوي Kubernetes کلستر کې د CSI ډرایور خپل پلي کول ولري، کوم چې په خلاص سرچینه کې خوشې کیدی شي. موږ دا پراختیایی اختیار هم د مناسب په توګه ګورو - ټولنه به وکولی شي د خدماتو چمتو کونکي څخه ثابت ډرایور وکاروي ، نه د دریمې ډلې شرکت څخه.

PS

زموږ په بلاګ کې هم ولولئ:

• «د کوبرنیټس ذخیره کولو لپاره حجم پلگ ان: له Flexvolume څخه CSI ته»
• «موږ د کانټینر ذخیره کولو انٹرفیس پوهیږو (په کوبرنیټس کې او نه یوازې)»
• «ایا د Kubernetes کلستر چمتو کول اسانه او اسانه دي؟ د اډون آپریټر اعلان کول»
• «د Kubernetes پراخول او بشپړول (بیاکتنه او ویډیو راپور)".

سرچینه: www.habr.com