Yandex.Cloud کے لیے Kubernetes CCM (کلاؤڈ کنٹرولر مینیجر) کا تعارف

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

تعارف

یہ کیوں ہے؟

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

CCM بالکل کیا ہے؟

عام طور پر، ہم اپنے ارد گرد کے ماحول کو کلسٹر کے لیے تیار کرتے ہیں۔ باہر سے - مثال کے طور پر، Terraform کا استعمال کرتے ہوئے. لیکن کبھی کبھی ہمارے ارد گرد بادل کے ماحول کو منظم کرنے کی ضرورت ہوتی ہے کلسٹر سے. یہ امکان فراہم کیا جاتا ہے، اور یہ وہی ہے جو لاگو کیا جاتا ہے ٹییلسی.

خاص طور پر، کلاؤڈ کنٹرولر مینیجر تعامل کی پانچ اہم اقسام فراہم کرتا ہے:

1. مثال - Kubernetes میں نوڈ آبجیکٹ کے درمیان 1: 1 تعلق کو نافذ کرتا ہے (Node) اور کلاؤڈ فراہم کنندہ میں ایک ورچوئل مشین۔ اس کے لیے ہم:
   • میدان میں بھریں spec.providerID اعتراض میں Node. مثال کے طور پر، OpenStack CCM کے لیے اس فیلڈ میں درج ذیل فارمیٹ ہے: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. آپ کلاؤڈ فراہم کنندہ کا نام اور سرور کا منفرد UUID دیکھ سکتے ہیں (اوپن اسٹیک میں ورچوئل مشین) آبجیکٹ کے؛
   • تکمیل nodeInfo اعتراض میں Node ورچوئل مشین کے بارے میں معلومات۔ مثال کے طور پر، ہم AWS میں مثال کی قسم بتاتے ہیں۔
   • ہم کلاؤڈ میں ورچوئل مشین کی موجودگی کو چیک کرتے ہیں۔ مثال کے طور پر، اگر کوئی اعتراض Node ایک حالت میں چلا گیا NotReady، آپ دیکھ سکتے ہیں کہ آیا ورچوئل مشین کلاؤڈ فراہم کنندہ میں بالکل موجود ہے۔ providerID. اگر یہ وہاں نہیں ہے تو، اعتراض کو حذف کریں Node, جو دوسری صورت میں ہمیشہ کے لیے کلسٹر میں رہے گا؛
2. زونز - آبجیکٹ کے لیے ناکامی کا ڈومین سیٹ کرتا ہے۔ Node، تاکہ شیڈیولر کلاؤڈ فراہم کنندہ میں علاقوں اور زون کے مطابق پوڈ کے لیے نوڈ منتخب کر سکے۔
3. لوڈ بیلنسر - کسی چیز کو بناتے وقت Service قسم کے ساتھ LoadBalancer ایک قسم کا بیلنس بناتا ہے جو باہر سے ٹریفک کو کلسٹر نوڈس کی طرف لے جائے گا۔ مثال کے طور پر، Yandex.Cloud میں آپ استعمال کر سکتے ہیں۔ NetworkLoadBalancer и TargetGroup ان مقاصد کے لیے؛
4. روٹ - نوڈس کے درمیان ایک نیٹ ورک بناتا ہے، کیونکہ Kubernetes کی ضروریات کے مطابق، ہر پوڈ کا اپنا IP پتہ ہونا چاہیے اور وہ کسی دوسرے پوڈ تک پہنچنے کے قابل ہونا چاہیے۔ ان مقاصد کے لیے، آپ اوورلے نیٹ ورک (VXLAN، GENEVE) استعمال کر سکتے ہیں یا کلاؤڈ فراہم کنندہ کے ورچوئل نیٹ ورک میں براہ راست روٹنگ ٹیبل سیٹ کر سکتے ہیں:

   

5. حجم - PVC اور SC کا استعمال کرتے ہوئے PV کی متحرک ترتیب کی اجازت دیتا ہے۔ ابتدائی طور پر، یہ فعالیت CCM کا حصہ تھی، لیکن اس کی بڑی پیچیدگی کی وجہ سے اسے ایک الگ پروجیکٹ، کنٹینر سٹوریج انٹرفیس (CSI) میں منتقل کر دیا گیا تھا۔ ہم نے ایک سے زیادہ بار CSI کے بارے میں بات کی ہے۔ писали اور، جیسا کہ پہلے ہی ذکر کیا گیا ہے، یہاں تک کہ جاری کیا CSI ڈرائیور۔

اس سے پہلے، کلاؤڈ کے ساتھ تعامل کرنے والے تمام کوڈ کبرنیٹس پروجیکٹ کے مرکزی گٹ ریپوزٹری میں موجود تھے۔ k8s.io/kubernetes/pkg/cloudprovider/providers، لیکن انہوں نے ایک بڑے کوڈ بیس کے ساتھ کام کرنے کی تکلیف کی وجہ سے اسے ترک کرنے کا فیصلہ کیا۔ تمام پرانے نفاذ کو منتقل کر دیا گیا ہے۔ علیحدہ ذخیرہ. مزید تعاون اور ترقی کی سہولت کے لیے، تمام مشترکہ اجزاء کو بھی منتقل کر دیا گیا۔ علیحدہ ذخیرہ.

جیسا کہ CSI کے ساتھ، بہت سے بڑے کلاؤڈ فراہم کنندگان نے پہلے ہی اپنے CCMs کو Kubernetes پر بادلوں کا فائدہ اٹھانے کے لیے ڈیزائن کیا ہے۔ اگر سپلائر کے پاس CCM نہیں ہے، لیکن تمام ضروری افعال API کے ذریعے دستیاب ہیں، تو آپ خود CCM کو لاگو کر سکتے ہیں۔

CCM کے اپنے نفاذ کو لکھنے کے لئے، یہ لاگو کرنے کے لئے کافی ہے مطلوبہ گو انٹرفیس.

И یہ وہی ہے جو ہمیں ملا.

Реализация

آپ اس تک کیسے پہنچے؟

ہم نے ترقی (یا اس کے بجائے استعمال بھی) شروع کی۔ تیار(!) CCM Yandex.Cloud کے لیے ایک سال پہلے۔

تاہم، اس نفاذ میں ہم غائب تھے:

• JWT IAM ٹوکن کے ذریعے تصدیق؛
• سروس کنٹرولر سپورٹ۔

مصنف کے ساتھ اتفاق میں (dlisin) ٹیلیگرام میں، ہم نے yandex-cloud-controller-manager کو فورک کیا اور غائب فنکشنز کو شامل کیا۔

اہم خصوصیات

فی الحال، CCM درج ذیل انٹرفیس کو سپورٹ کرتا ہے:

• مثال;
• زونز;
• لوڈ بیلنسر.

مستقبل میں، جب Yandex.Cloud اعلی درجے کی VPC صلاحیتوں کے ساتھ کام کرنا شروع کرے گا، ہم ایک انٹرفیس شامل کریں گے۔ روٹس.

اہم چیلنج کے طور پر لوڈ بیلانسر

ابتدائی طور پر، ہم نے دوسرے CCM نفاذ کی طرح، ایک جوڑا بنانے کی کوشش کی۔ LoadBalancer и TargetGroup ہر شخص کے لئے Service قسم کے ساتھ LoadBalancer. تاہم، Yandex.Cloud نے ایک دلچسپ حد دریافت کی: آپ استعمال نہیں کر سکتے TargetGroups ایک دوسرے کو ملانے کے ساتھ Targets (جوڑا SubnetID - IpAddress).

لہذا، تخلیق کردہ CCM کے اندر، ایک کنٹرولر شروع کیا جاتا ہے، جو، جب اشیاء تبدیل ہوتا ہے Node ہر ورچوئل مشین پر تمام انٹرفیس کے بارے میں معلومات اکٹھا کرتا ہے، ان کو ان کے مخصوص سے تعلق کے مطابق گروپ کرتا ہے۔ NetworkIDکی طرف سے تخلیق کرتا ہے TargetGroup پر NetworkID، اور مطابقت کو بھی مانیٹر کرتا ہے۔ اس کے بعد، جب ایک اعتراض پیدا ہوتا ہے Service قسم کے ساتھ LoadBalanacer ہم صرف پہلے سے تیار کردہ منسلک کرتے ہیں۔ TargetGroup نئے کو NetworkLoadBalanacerمیں

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

CCM Kubernetes ورژن 1.15 اور اس سے زیادہ کو سپورٹ کرتا ہے۔ ایک جھرمٹ میں، اس کے کام کرنے کے لیے، اس کے لیے پرچم کی ضرورت ہوتی ہے۔ --cloud-provider=external مقرر کیا گیا تھا true kube-apiserver، kube-controller-manager، kube-scheduler اور تمام kubelets کے لیے۔

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

CCM استعمال کرنے کے لیے آپ کو بھی ضرورت ہو گی:

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

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

کے نتائج

ہم گزشتہ دو ہفتوں سے پانچ Kubernetes کلسٹرز میں لاگو CCM استعمال کر رہے ہیں اور آنے والے مہینے میں ان کی تعداد 20 تک بڑھانے کا ارادہ رکھتے ہیں۔ ہم فی الحال بڑی اور اہم K8s تنصیبات کے لیے CCM استعمال کرنے کی سفارش نہیں کرتے ہیں۔

جیسا کہ CSI کے معاملے میں، ہمیں خوشی ہو گی اگر Yandex کے ڈویلپرز اس پراجیکٹ کی ترقی اور تعاون کو قبول کرتے ہیں - ہم ان کی درخواست پر ذخیرہ کو منتقل کرنے کے لیے تیار ہیں تاکہ ان کاموں سے نمٹنے کے لیے جو ہمارے لیے زیادہ متعلقہ ہوں۔

PS

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

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

ماخذ: www.habr.com