موږ خوښ یو چې اعلان کوو چې فلانټ د خوشې کولو له لارې د Kubernetes لپاره د خلاصې سرچینې وسیلو کې خپله ونډه پراخه کوي
مګر مخکې لدې چې د پلي کولو توضیحاتو ته لاړشئ ، راځئ دې پوښتنې ته ځواب ووایو چې ولې دې ته اړتیا لیدل کیږي کله چې یاندیکس دمخه خدمت لري
پېژندنه
دا ولې؟
زموږ په شرکت کې ، په تولید کې د کبرنیټس کارولو له پیل څخه (یعنې د څو کلونو راهیسې) ، موږ خپل وسیله (ډیک هاؤس) رامینځته کوو ، کوم چې له مخې یې موږ پلان لرو چې ډیر ژر د خلاصې سرچینې پروژې په توګه چمتو کړو. . د دې په مرسته، موږ خپل ټول کلسترونه په مساوي ډول تنظیم او تنظیم کوو، او دا مهال د دوی له 100 څخه ډیر شتون لري، په پراخه کچه د هارډویر ترتیباتو او ټولو موجود کلاوډ خدماتو کې.
هغه کلسترونه چې د ډیک هاؤس کاروي د عملیاتو لپاره ټولې اړینې برخې لري: بیلانسونه، د مناسب چارټونو سره څارنه، میټریکونه او خبرتیاوې، ټولو ډشبورډونو ته د لاسرسي لپاره د بهرني چمتو کونکو له لارې د کارونکي تصدیق، او داسې نور. په اداره شوي حل کې د داسې "پمپ اپ" کلستر نصبولو کې هیڅ معنی نشته، ځکه چې دا اکثرا یا ناممکن وي یا د نیمایي برخو غیر فعالولو اړتیا ته الر پیدا کوي.
NB: دا زموږ تجربه ده، او دا خورا مشخصه ده. موږ په هیڅ ډول وړاندیز نه کوو چې هرڅوک باید د چمتو شوي حلونو کارولو پرځای پخپله د کبرنیټ کلسترونه ځای په ځای کړي. په هرصورت، موږ د Yandex څخه Kubernetes په چلولو کې ریښتینې تجربه نلرو او موږ به پدې مقاله کې د دې خدمت کومه ارزونه ونه کړو.
څه شی دی او د چا لپاره؟
نو، موږ لا دمخه په کوبرنیټس کې د ذخیره کولو عصري طریقې په اړه خبرې کړې دي:
اوس مهال، ډیری لوی کلاوډ خدمت چمتو کونکو په کبرنیټس کې د دوامداره حجم په توګه د دوی کلاوډ ډیسک کارولو لپاره ډرایورونه رامینځته کړي. که عرضه کونکی داسې ډرایور ونه لري، مګر ټولې اړینې دندې د API له لارې چمتو شوي، نو هیڅ شی به تاسو پخپله د ډرایور پلي کولو مخه ونه نیسي. دا هغه څه دي چې د Yandex.Cloud سره پیښ شوي.
موږ د پرمختګ لپاره د اساس په توګه اخیستی Operation
د اوږدې مودې عملیاتو حالت تعقیب کړئ (د بیلګې په توګه، د نوي ډیسک جوړول). د Yandex.Cloud API سره د تعامل لپاره، وکاروئ
د ترسره شوي کار پایله
پلي کول
کلیدي ب .ې
اوس مهال ډرایور د لاندې کارونو ملاتړ کوي:
- د کلستر په ټولو زونونو کې د کلستر د نوډونو د ټوپولوژي مطابق د ډیسکونو ترتیب کول؛
- مخکې امر شوي ډیسکونه لرې کول؛
- د ډیسکونو لپاره آفلاین اندازه کول (Yandex.Cloud
ملاتړ مه کوئ د ډیسکونو زیاتول چې په مجازی ماشین کې ایښودل شوي دي). د دې په اړه د معلوماتو لپاره چې څنګه ډرایور باید بدلون ومومي ترڅو د امکان تر حده بې درده اندازه کولو لپاره، لاندې وګورئ.
په راتلونکي کې، موږ پلان لرو چې د ډیسک سنیپ شاټونو رامینځته کولو او حذف کولو لپاره ملاتړ پلي کړو.
اصلي مشکل او څنګه یې له منځه یوسو
په Yandex.Cloud API کې په ریښتیني وخت کې د ډیسکونو د زیاتولو وړتیا نشتوالی یو محدودیت دی چې د PV (دوامداره حجم) لپاره د بیا اندازې عملیات پیچلي کوي: پدې حالت کې ، دا اړینه ده چې د غوښتنلیک پوډ چې ډیسک کاروي ودرول شي ، او دا کولی شي د بند وخت غوښتنلیکونو لامل شي.
د 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 پلگ ان) ، د ډیسک زیاتولو عملیات داسې ښکاري:
- موږ د gRPC تلیفون ترلاسه کوو
ControllerExpandVolume
; - موږ هڅه کوو چې په API کې ډیسک زیات کړو، مګر موږ د عملیاتو ترسره کولو ناشونیتیا په اړه یوه تېروتنه ترلاسه کوو ځکه چې ډیسک نصب شوی؛
- موږ د ډیسک پیژندونکی په نقشه کې ذخیره کوو، کوم چې هغه ډیسکونه لري چې د زیاتوالي عملیات ترسره کولو ته اړتیا لري. لاندې، د لنډیز لپاره، موږ به دې نقشې ته ووایو
volumeResizeRequired
; - په لاسي ډول هغه پوډ لرې کړئ چې ډیسک کاروي. Kubernetes به دا بیا پیل کړي. نو د دې لپاره چې ډیسک د نصبولو وخت ونه لري (
ControllerPublishVolume
) مخکې له دې چې د زیاتوالي عملیاتو بشپړولو په وخت کې د نصبولو هڅه وکړو، موږ ګورو چې ورکړل شوی ډیسک لاهم دننه دیvolumeResizeRequired
او یوه تېروتنه راګرځوي؛ - د CSI ډرایور هڅه کوي د بیا اندازې عملیات بیا اجرا کړي. که عملیات بریالي وي، نو بیا ډیسک لرې کړئ
volumeResizeRequired
; - ځکه د ډیسک ID له دې څخه ورک دی
volumeResizeRequired
,ControllerPublishVolume
په بریالیتوب سره تیریږي، ډیسک نصب شوی، پوډ پیل کیږي.
هرڅه خورا ساده ښکاري، مګر د تل په څیر نیمګړتیاوې شتون لري. ډیسکونه پراخوي
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+ دقیقو لپاره وغځوي او پدې توګه اړونده پوډ شتون نلري.
یوازینی اختیار چې په اسانۍ او بې درده توګه موږ ته اجازه راکوي چې د احتمالي ځنډ وخت کم کړو زموږ د بهرني ریسائزر نسخه کارول د اعظمي حد حد سره
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 ) باید په کلستر کې فعال شي. کله چې د ډاکر کاروئ ، ډیمون باید تنظیم شي ترڅو د شریک ماونټونو ته اجازه ورکړي.
د نصبولو لپاره ټول اړین ګامونه پخپله
د موټر چلوونکي کار کولو لپاره تاسو به لاندې ته اړتیا ولرئ:
- په منشور کې د لارښود پیژندونکی مشخص کړئ (
folder-id
) Yandex.Cloud (اسناد وګورئ ); - د Yandex.Cloud API سره د تعامل لپاره، د CSI ډرایور د خدماتو حساب کاروي. په ښکاره کې، راز باید تیر شي
مجاز کیلي د خدمت حساب څخه. په اسنادو کېبیان شوی د خدماتو حساب څنګه جوړ کړئ او کیلي ترلاسه کړئ.
ټول په ټولو کښې -
نور ملاتړ
د پایلې په توګه، موږ غواړو یادونه وکړو چې موږ دا CSI ډرایور په Go کې د ساتیرۍ لیکلو غوښتنلیکونو لپاره د یوې لویې لیوالتیا څخه نه، بلکې په شرکت کې د بیړنۍ اړتیا له امله پلي کړی. دا زموږ لپاره عملي نه بریښي چې خپل پلي کول وساتو ، نو که Yandex علاقه وښيي او پریکړه وکړي چې د ډرایور ملاتړ ته دوام ورکړي ، موږ به خوښ یو چې دوی ته ذخیره انتقال کړو.
سربیره پردې، Yandex شاید په خپل اداره شوي Kubernetes کلستر کې د CSI ډرایور خپل پلي کول ولري، کوم چې په خلاص سرچینه کې خوشې کیدی شي. موږ دا پراختیایی اختیار هم د مناسب په توګه ګورو - ټولنه به وکولی شي د خدماتو چمتو کونکي څخه ثابت ډرایور وکاروي ، نه د دریمې ډلې شرکت څخه.
PS
زموږ په بلاګ کې هم ولولئ:
- «
د کوبرنیټس ذخیره کولو لپاره حجم پلگ ان: له Flexvolume څخه CSI ته » - «
موږ د کانټینر ذخیره کولو انٹرفیس پوهیږو (په کوبرنیټس کې او نه یوازې) » - «
ایا د Kubernetes کلستر چمتو کول اسانه او اسانه دي؟ د اډون آپریټر اعلان کول » - «
د Kubernetes پراخول او بشپړول (بیاکتنه او ویډیو راپور) ".
سرچینه: www.habr.com