Yandex.Cloud کے لیے Kubernetes میں CSI ڈرائیور تیار کرنے کا ہمارا تجربہ

ہمیں یہ اعلان کرتے ہوئے خوشی ہو رہی ہے کہ فلانٹ کبرنیٹس کے لیے اوپن سورس ٹولز میں اپنا تعاون بڑھا رہا ہے۔ CSI ڈرائیور کا الفا ورژن (کنٹینر سٹوریج انٹرفیس) Yandex.Cloud کے لیے۔

لیکن عمل درآمد کی تفصیلات پر جانے سے پہلے، آئیے اس سوال کا جواب دیں کہ جب Yandex کے پاس پہلے سے ہی ایک سروس موجود ہے تو اس کی ضرورت کیوں ہے؟ Kubernetes کے لیے منظم سروس.

تعارف

یہ کیوں ہے؟

ہماری کمپنی کے اندر، پیداوار میں Kubernetes کے استعمال کے آغاز سے ہی (یعنی اب کئی سالوں سے)، ہم اپنا ٹول (ڈیک ہاؤس) تیار کر رہے ہیں، جسے، ویسے، ہم جلد ہی ایک اوپن سورس پروجیکٹ کے طور پر بھی دستیاب کرنے کا ارادہ رکھتے ہیں۔ . اس کی مدد سے، ہم اپنے تمام کلسٹرز کو یکساں طور پر ترتیب اور ترتیب دیتے ہیں، اور فی الحال ان میں سے 100 سے زیادہ پہلے سے ہی موجود ہیں، ہارڈ ویئر کنفیگریشن کی وسیع اقسام اور تمام دستیاب کلاؤڈ سروسز میں۔

ڈیک ہاؤس استعمال کرنے والے کلسٹروں میں آپریشن کے لیے ضروری تمام اجزاء ہوتے ہیں: بیلنسرز، آسان چارٹس کے ساتھ نگرانی، میٹرکس اور الرٹس، تمام ڈیش بورڈز تک رسائی کے لیے بیرونی فراہم کنندگان کے ذریعے صارف کی تصدیق، وغیرہ۔ منظم حل میں اس طرح کے "پمپ اپ" کلسٹر کو انسٹال کرنے کا کوئی فائدہ نہیں ہے، کیونکہ یہ اکثر یا تو ناممکن ہوتا ہے یا آدھے اجزاء کو غیر فعال کرنے کی ضرورت کا باعث بنتا ہے۔

NB: یہ ہمارا تجربہ ہے، اور یہ کافی مخصوص ہے۔ ہم کسی بھی طرح سے یہ تجویز نہیں کر رہے ہیں کہ ہر کسی کو تیار شدہ حل استعمال کرنے کے بجائے اپنے طور پر Kubernetes کلسٹرز کو تعینات کرنا چاہیے۔ ویسے، ہمیں Yandex سے Kubernetes کو چلانے کا کوئی حقیقی تجربہ نہیں ہے اور ہم اس مضمون میں اس سروس کا کوئی اندازہ نہیں دیں گے۔

یہ کیا ہے اور کس کے لیے ہے؟

لہذا، ہم نے پہلے ہی Kubernetes میں ذخیرہ کرنے کے جدید نقطہ نظر کے بارے میں بات کی ہے: CSI کیسے کام کرتا ہے؟ и کمیونٹی کیسے آئی اس نقطہ نظر کو.

فی الحال، بہت سے بڑے کلاؤڈ سروس فراہم کنندگان نے اپنی کلاؤڈ ڈسک کو کوبرنیٹس میں مستقل حجم کے طور پر استعمال کرنے کے لیے ڈرائیور تیار کیے ہیں۔ اگر سپلائر کے پاس ایسا ڈرائیور نہیں ہے، لیکن تمام ضروری افعال API کے ذریعے فراہم کیے گئے ہیں، تو پھر آپ کو خود ڈرائیور کو نافذ کرنے سے کوئی چیز نہیں روک سکتی۔ Yandex.Cloud کے ساتھ ایسا ہی ہوا۔

ہم نے ترقی کی بنیاد کے طور پر لیا DigitalOcean کلاؤڈ کے لیے CSI ڈرائیور اور سے خیالات کے ایک جوڑے جی سی پی کے لیے ڈرائیورچونکہ ان بادلوں کے API کے ساتھ تعامل (Google اور Yandex) میں متعدد مماثلتیں ہیں۔ خاص طور پر، API اور GCP، اور پر 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)

ہم نے فوری طور پر بحث شروع کرنا اور بیرونی ریسائزر کو پیچ کرنا ضروری نہیں سمجھا، کیونکہ ڈسکوں کا آف لائن سائز تبدیل کرنا ایک تھرو بیک ہے جو جلد ہی تمام کلاؤڈ فراہم کنندگان سے غائب ہو جائے گا۔

اس کا استعمال کیسے شروع کیا جائے؟

ڈرائیور کوبرنیٹس ورژن 1.15 اور اس سے زیادہ پر تعاون یافتہ ہے۔ ڈرائیور کے کام کرنے کے لیے، درج ذیل تقاضوں کو پورا کرنا ضروری ہے:

• پرچم --allow-privileged قدر پر سیٹ کریں۔ true API سرور اور کیوبلیٹ کے لیے؛
• شامل --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API سرور اور کیوبلیٹ کے لیے؛
• پہاڑی پھیلاؤ (ماؤنٹ تبلیغ) کلسٹر پر فعال ہونا ضروری ہے۔ ڈوکر استعمال کرتے وقت، ڈیمون کو مشترکہ ماؤنٹس کی اجازت دینے کے لیے کنفیگر کیا جانا چاہیے۔

تنصیب کے لیے تمام ضروری اقدامات README میں بیان کیا گیا ہے۔. انسٹالیشن میں مینی فیسٹ سے Kubernetes میں اشیاء بنانا شامل ہے۔

ڈرائیور کے کام کرنے کے لیے آپ کو درج ذیل چیزوں کی ضرورت ہوگی:

• مینی فیسٹ میں ڈائریکٹری شناخت کنندہ کی وضاحت کریں (folder-id) Yandex.Cloud (دستاویزات دیکھیں);
• Yandex.Cloud API کے ساتھ تعامل کرنے کے لیے، CSI ڈرائیور سروس اکاؤنٹ استعمال کرتا ہے۔ منشور میں، راز کا پاس ہونا ضروری ہے۔ مجاز چابیاں سروس اکاؤنٹ سے دستاویزات میں بیان کیا، سروس اکاؤنٹ بنانے اور چابیاں حاصل کرنے کا طریقہ۔

حاکم کل - کوشش کریں، اور ہمیں تاثرات حاصل کرنے میں خوشی ہوگی اور نئے مسائلاگر آپ کو کوئی مسئلہ درپیش ہے!

مزید سپورٹ

نتیجے کے طور پر، ہم یہ نوٹ کرنا چاہیں گے کہ ہم نے اس CSI ڈرائیور کو گو میں مزے سے لکھنے کی ایپلی کیشنز حاصل کرنے کی خواہش کے تحت نہیں، بلکہ کمپنی کے اندر ایک فوری ضرورت کی وجہ سے لاگو کیا۔ ہمارے اپنے عمل کو برقرار رکھنا ہمارے لیے عملی نہیں لگتا ہے، لہذا اگر Yandex دلچسپی ظاہر کرتا ہے اور ڈرائیور کی حمایت جاری رکھنے کا فیصلہ کرتا ہے، تو ہمیں ذخیرہ ان کو منتقل کرنے میں خوشی ہوگی۔

اس کے علاوہ، Yandex کے پاس اپنے زیر انتظام Kubernetes کلسٹر میں CSI ڈرائیور کا اپنا نفاذ ہے، جسے اوپن سورس میں جاری کیا جا سکتا ہے۔ ہم ترقی کے اس آپشن کو سازگار کے طور پر بھی دیکھتے ہیں - کمیونٹی سروس فراہم کرنے والے سے ثابت شدہ ڈرائیور استعمال کر سکے گی، نہ کہ کسی تیسرے فریق کی کمپنی سے۔

PS

ہمارے بلاگ پر بھی پڑھیں:

• «Kubernetes اسٹوریج کے لیے والیوم پلگ ان: Flexvolume سے CSI تک؛ "
• «ہم کنٹینر اسٹوریج انٹرفیس کو سمجھتے ہیں (کوبرنیٹس میں اور نہ صرف)؛ "
• «کیا Kubernetes کلسٹر تیار کرنا آسان اور آسان ہے؟ ایڈون آپریٹر کا اعلان کرنا؛ "
• «Kubernetes کی توسیع اور تکمیل (جائزہ اور ویڈیو رپورٹ)'.

ماخذ: www.habr.com