تازو جي تسلسل ۾ Yandex.Cloud لاءِ اسان هن ڪلائوڊ لاءِ هڪ ٻيو اوپن سورس پروجيڪٽ شايع ڪري رهيا آهيون - . CCM گهربل آهي نه رڳو ڪلستر لاء، پر پڻ CSI ڊرائيور پاڻ لاء. ان جي مقصد جي باري ۾ تفصيل ۽ ڪجهه لاڳو ڪرڻ جون خاصيتون ڪٽ هيٺ آهن.
تعارف
ائين ڇو آهي؟
اهي مقصد جيڪي اسان کي Yandex.Cloud لاءِ CCM تيار ڪرڻ جي ترغيب ڏين ٿا مڪمل طور تي انهن سان ٺهڪندڙ آهن جيڪي اڳ ۾ ئي بيان ڪيل آهن CSI ڊرائيور. اسان مختلف ڪلائوڊ فراهم ڪندڙن کان ڪيترائي ڪبرنيٽس ڪلستر برقرار رکون ٿا، جن لاءِ اسان ھڪڙو اوزار استعمال ڪندا آھيون. اهو ڪيترن ئي سهولتن کي لاڳو ڪري ٿو "بائي پاس" انهن مهيا ڪندڙن جي منظم حلن کي. ها، اسان وٽ ھڪڙو خاص ڪيس ۽ ضرورتون آھن، پر انھن جي ڪري پيدا ڪيل ترقي ٻين صارفين لاء مفيد ٿي سگھي ٿي.
اصل ۾ CCM ڇا آهي؟
عام طور تي، اسان ڪلستر لاء اسان جي چوڌاري ماحول تيار ڪندا آهيون ٻاهران - مثال طور، Terraform استعمال ڪندي. پر ڪڏهن ڪڏهن اسان جي چوڌاري بادل ماحول کي منظم ڪرڻ جي ضرورت آهي ڪلستر کان. اهو امڪان مهيا ڪيو ويو آهي، ۽ اهو ئي آهي جيڪو لاڳو ٿئي ٿو .
خاص طور تي، ڪلائوڊ ڪنٽرولر مئنيجر مهيا ڪري ٿو پنج مکيه قسم جي رابطي جا:
- مثال - ڪبرنيٽس ۾ نوڊ اعتراض جي وچ ۾ 1: 1 تعلق لاڳو ڪري ٿو (
Node) ۽ ڪلائوڊ فراهم ڪندڙ ۾ هڪ مجازي مشين. ان لاءِ اسان:- فيلڊ ۾ ڀريو
spec.providerIDاعتراض ۾Node. مثال طور، OpenStack CCM لاءِ ھن فيلڊ کي ھيٺ ڏنل شڪل آھي:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. توھان ڏسي سگھوٿا ڪلائوڊ فراهم ڪندڙ جو نالو ۽ سرور جو منفرد UUID (OpenStack ۾ ورچوئل مشين) اعتراض جي؛ - مڪمل ڪرڻ
nodeInfoاعتراض ۾Nodeمجازي مشين بابت ڄاڻ. مثال طور، اسان AWS ۾ مثال جو قسم بيان ڪريون ٿا؛ - اسان ڪلائوڊ ۾ هڪ ورچوئل مشين جي موجودگي چيڪ ڪريون ٿا. مثال طور، جيڪڏهن هڪ اعتراض
Nodeهڪ رياست ۾ ويوNotReady، توهان چيڪ ڪري سگهو ٿا ته ڇا ورچوئل مشين ڪلائوڊ فراهم ڪندڙ ۾ موجود آهيproviderID. جيڪڏهن اهو موجود ناهي، اعتراض کي ختم ڪريوNode، جيڪو ٻي صورت ۾ هميشه لاءِ ڪلستر ۾ رهندو؛
- فيلڊ ۾ ڀريو
- زونز - اعتراض لاء ناڪامي ڊومين کي سيٽ ڪري ٿو
Node، انهي ڪري ته شيڊيولر پوڊ لاءِ نوڊ چونڊي سگهي ٿو ڪلائوڊ فراهم ڪندڙ ۾ علائقن ۽ زونن جي مطابق؛ - لوڊ بيلنسر - جڏهن هڪ اعتراض ٺاهي
Serviceقسم سانLoadBalancerهڪ قسم جو بيلنس ٺاهي ٿو جيڪو ٻاهران ٽرئفڪ کي ڪلستر نوڊس ڏانهن سڌو رستو ڏيکاريندو. مثال طور، Yandex.Cloud ۾ توهان استعمال ڪري سگهو ٿاNetworkLoadBalancerиTargetGroupانهن مقصدن لاء؛ - رستو - نوڊس جي وچ ۾ نيٽ ورڪ ٺاهي ٿو، ڇاڪاڻ ته Kubernetes جي ضرورتن مطابق، هر پوڊ کي پنهنجي IP پتي هجڻ گهرجي ۽ ڪنهن ٻئي پوڊ تائين پهچڻ جي قابل هوندو. انهن مقصدن لاءِ، توهان هڪ اوورلي نيٽ ورڪ استعمال ڪري سگهو ٿا (VXLAN، GENEVE) يا سڌو سنئون ڪلائوڊ فراهم ڪندڙ جي ورچوئل نيٽ ورڪ ۾ هڪ روٽنگ ٽيبل سيٽ ڪريو:
- جلد - PVC ۽ SC استعمال ڪندي PV جي متحرڪ ترتيب جي اجازت ڏئي ٿي. شروعات ۾، اها ڪارڪردگي CCM جو حصو هئي، پر ان جي وڏي پيچيدگي جي ڪري ان کي هڪ الڳ پروجيڪٽ، ڪنٽينر اسٽوريج انٽرفيس (CSI) ڏانهن منتقل ڪيو ويو. اسان هڪ ڀيرو کان وڌيڪ CSI بابت ڳالهايو آهي ۽، جيئن اڳ ۾ ئي ذڪر ڪيو ويو آهي، جيتوڻيڪ CSI ڊرائيور.
اڳي، سڀ ڪوڊ ڪلائوڊ سان لهه وچڙ ۾ واقع هئا ڪبرنيٽس پروجيڪٽ جي مکيه گٽ مخزن ۾ k8s.io/kubernetes/pkg/cloudprovider/providers، پر انهن هڪ وڏي ڪوڊ بيس سان ڪم ڪرڻ جي تڪليف جي ڪري هن کي ڇڏڻ جو فيصلو ڪيو. سڀني پراڻن عملن کي منتقل ڪيو ويو آهي . وڌيڪ مدد ۽ ترقي جي سهولت لاء، سڀني گڏيل حصن کي پڻ منتقل ڪيو ويو .
جيئن ته CSI سان، ڪيترائي وڏا بادل فراهم ڪندڙ اڳ ۾ ئي ٺاهيا آهن انهن جي سي سي ايمز کي ڪبرنيٽس تي بادل کڻڻ لاء. جيڪڏهن فراهم ڪندڙ وٽ CCM نه آهي، پر سڀئي ضروري افعال API ذريعي دستياب آهن، ته پوء توهان CCM پاڻ لاڳو ڪري سگهو ٿا.
سي سي ايم جي پنهنجي عمل کي لکڻ لاء، اهو لاڳو ڪرڻ ڪافي آهي .
И .
عمل
هي ڪيئن آيو
اسان ترقي شروع ڪيو (يا بلڪه، اڃا به استعمال) سان Yandex.Cloud لاء هڪ سال اڳ.
بهرحال، هن عمل ۾ اسان غائب هئاسين:
- JWT IAM ٽوڪن ذريعي تصديق؛
- خدمت سنڀاليندڙ سپورٽ.
ليکڪ سان متفق (ڊليسن) ٽيليگرام ۾، اسان yandex-Cloud-controller-manager کي فورڪ ڪيو ۽ غائب ٿيل افعال شامل ڪيو.
مکيه خاصيتون
في الحال، سي سي ايم هيٺين انٽرفيس کي سپورٽ ڪري ٿو:
- مثال;
- زونز;
- لوڊ بيلنسر.
مستقبل ۾، جڏهن Yandex.Cloud ترقي يافته VPC صلاحيتن سان ڪم ڪرڻ شروع ڪندو، اسان هڪ انٽرفيس شامل ڪنداسين رستا.
LoadBalanacer بنيادي چئلينج طور
شروعات ۾، اسان ڪوشش ڪئي، ٻين سي سي ايم جي عملن وانگر، جوڙو ٺاهڻ لاء 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-apisserver، kube-controller-manager، kube-scheduler ۽ سڀ kubelets لاءِ.
تنصيب لاءِ سڀ ضروري قدم پاڻ ۾ بيان ڪيا ويا آهن . تنصيب منشور مان ڪبرنيٽس ۾ شيون ٺاهڻ لاءِ هيٺ اچي ٿي.
CCM استعمال ڪرڻ لاءِ توھان کي پڻ ضرورت پوندي:
- ظاهر ۾ ڊاريڪٽري جي سڃاڻپ ڪندڙ (
folder-id) Yandex.Cloud؛ - Yandex.Cloud API سان رابطي لاءِ سروس اڪائونٽ. منشور ۾
Secretضروري آهي سروس اڪائونٽ مان. دستاويز ۾ , ڪيئن ٺاهيو هڪ خدمت اڪائونٽ ۽ چابيون حاصل ڪرڻ لاء.
اسان کي توهان جي راء حاصل ڪرڻ لاء خوش ٿيندو ۽ جيڪڏهن توهان ڪنهن پريشاني سان منهن ڪيو!
نتيجو
اسان گذريل ٻن هفتن کان پنجن ڪبرنيٽس ڪلسٽرز ۾ لاڳو ڪيل سي سي ايم استعمال ڪري رهيا آهيون ۽ ايندڙ مهيني ۾ انهن جو تعداد 20 تائين وڌائڻ جو منصوبو ٺاهيو. اسان في الحال وڏي ۽ نازڪ K8s تنصيب لاءِ CCM استعمال ڪرڻ جي سفارش نٿا ڪريون.
جيئن ته CSI جي صورت ۾، اسان کي خوشي ٿيندي جيڪڏهن Yandex ڊولپرز هن منصوبي جي ترقي ۽ حمايت تي عمل ڪن ٿا - اسان انهن جي درخواست تي مخزن کي منتقل ڪرڻ لاء تيار آهيون انهي ڪم سان معاملو ڪرڻ لاء جيڪي اسان لاء وڌيڪ لاڳاپيل آهن.
پي ايس
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com