Ներկայացնում ենք Kubernetes CCM-ը (Cloud Controller Manager) Yandex.Cloud-ի համար

Ի շարունակություն վերջին CSI վարորդի թողարկում Yandex.Cloud-ի համար մենք հրապարակում ենք մեկ այլ բաց կոդով նախագիծ այս ամպի համար. Cloud Controller Manager. CCM-ը պահանջվում է ոչ միայն կլաստերի համար որպես ամբողջություն, այլ նաև ինքնին CSI դրայվերի համար: Մանրամասները դրա նպատակի և իրականացման որոշ առանձնահատկությունների մասին են:

Ներածություն

Ինչու սա?

Այն շարժառիթները, որոնք մեզ դրդեցին մշակել CCM Yandex.Cloud-ի համար, լիովին համընկնում են արդեն նկարագրվածների հետ. հայտարարություն CSI վարորդներ. Մենք պահպանում ենք բազմաթիվ Kubernetes կլաստերներ տարբեր ամպային մատակարարներից, որոնց համար մենք օգտագործում ենք մեկ գործիք: Այն իրականացնում է բազմաթիվ հարմարություններ՝ «շրջանցելով» այս մատակարարների կառավարվող լուծումները: Այո, մենք ունենք բավականին կոնկրետ դեպք և կարիքներ, սակայն դրանց պատճառով ստեղծված զարգացումները կարող են օգտակար լինել այլ օգտատերերի համար։

Ի՞նչ է կոնկրետ CCM-ը:

Որպես կանոն, մենք պատրաստում ենք մեզ շրջապատող միջավայրը կլաստերի համար դրսից - օրինակ, օգտագործելով Terraform-ը: Բայց երբեմն անհրաժեշտություն է առաջանում կառավարել մեր շրջապատող ամպային միջավայրը կլաստերից. Այդ հնարավորությունն ապահովված է, և հենց դա էլ իրականացվում է TLC.

Մասնավորապես, Cloud Controller Manager-ը ապահովում է փոխգործակցության հինգ հիմնական տեսակ.

1. Դեպքեր – իրականացնում է 1:1 հարաբերություն հանգույցի օբյեկտի միջև Kubernetes-ում (Node) և վիրտուալ մեքենա ամպային մատակարարում: Դրա համար մենք.
   • լրացրեք դաշտը spec.providerID օբյեկտի մեջ Node. Օրինակ, OpenStack CCM-ի համար այս դաշտն ունի հետևյալ ձևաչափը. openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Դուք կարող եք տեսնել ամպային մատակարարի անունը և օբյեկտի սերվերի եզակի UUID (վիրտուալ մեքենա OpenStack-ում);
   • լրացնում nodeInfo օբյեկտի մեջ Node տեղեկատվություն վիրտուալ մեքենայի մասին: Օրինակ, մենք նշում ենք օրինակի տեսակը AWS-ում;
   • Մենք ստուգում ենք ամպի մեջ վիրտուալ մեքենայի առկայությունը: Օրինակ, եթե օբյեկտ Node մտավ մի վիճակ NotReady, կարող եք ստուգել, ​​թե արդյոք վիրտուալ մեքենան ընդհանրապես գոյություն ունի ամպային մատակարարում providerID. Եթե ​​այն չկա, ջնջեք օբյեկտը Node, որը հակառակ դեպքում հավերժ կմնար կլաստերում;
2. գոտիներ – սահմանում է օբյեկտի ձախողման տիրույթը Node, որպեսզի ժամանակացույցը կարողանա ընտրել հանգույց Pod-ի համար՝ ըստ ամպի մատակարարի տարածաշրջանների և գոտիների.
3. LoadBalancer - օբյեկտ ստեղծելիս Service տեսակի հետ LoadBalancer ստեղծում է մի տեսակ հավասարակշռող, որը դրսից երթևեկությունը կուղղորդի դեպի կլաստերային հանգույցներ: Օրինակ, Yandex.Cloud-ում կարող եք օգտագործել NetworkLoadBalancer и TargetGroup այս նպատակների համար;
4. Ուղի – կառուցում է ցանց հանգույցների միջև, քանի որ Ըստ Kubernetes-ի պահանջների՝ յուրաքանչյուր pod պետք է ունենա իր IP հասցեն և կարողանա հասնել ցանկացած այլ pod. Այս նպատակների համար դուք կարող եք օգտագործել ծածկույթի ցանց (VXLAN, GENEVE) կամ սահմանել երթուղային աղյուսակ անմիջապես ամպային մատակարարի վիրտուալ ցանցում.

   

5. ծավալ – Թույլ է տալիս PV-ի դինամիկ պատվիրումը PVC և SC օգտագործմամբ: Սկզբում այս ֆունկցիոնալությունը CCM-ի մի մասն էր, բայց իր մեծ բարդության պատճառով այն տեղափոխվեց առանձին նախագիծ՝ Container Storage Interface (CSI): Մենք մեկ անգամ չէ, որ խոսել ենք ՔՀԻ-ի մասին писали և, ինչպես արդեն նշվեց, նույնիսկ ազատ է արձակվել CSI վարորդ.

Նախկինում ամպի հետ փոխազդող բոլոր ծածկագրերը գտնվում էին Kubernetes նախագծի հիմնական Git պահոցում. k8s.io/kubernetes/pkg/cloudprovider/providers, բայց նրանք որոշեցին հրաժարվել դրանից՝ մեծ կոդի բազայի հետ աշխատելու անհարմարության պատճառով։ Բոլոր հին իրականացումները տեղափոխվել են առանձին պահոց. Հետագա աջակցության և զարգացման հարմարության համար բոլոր ընդհանուր բաղադրիչները նույնպես տեղափոխվել են առանձին պահոց.

Ինչպես CSI-ի դեպքում, շատ խոշոր ամպային պրովայդերներ արդեն նախագծել են իրենց CCM-ները Kubernetes-ում ամպերը օգտագործելու համար: Եթե ​​մատակարարը չունի CCM, բայց բոլոր անհրաժեշտ գործառույթները հասանելի են API-ի միջոցով, ապա դուք կարող եք ինքներդ իրականացնել CCM:

CCM-ի ձեր սեփական ներդրումը գրելու համար բավական է իրականացնել պահանջվող Go միջերեսներ.

И սա այն է, ինչ մենք ստացել ենք.

Իրականացման

Ինչպե՞ս հասաք սրան

Մենք սկսել ենք զարգացումը (ավելի ճիշտ, նույնիսկ օգտագործել) հետ պատրաստ (!) CCM Yandex.Cloud-ի համար մեկ տարի առաջ:

Այնուամենայնիվ, այս իրականացման մեջ մենք բացակայում էինք.

• նույնականացում JWT IAM նշանի միջոցով;
• Ծառայության վերահսկիչի աջակցություն:

Հեղինակի հետ համաձայնությամբ (դլիսին) Telegram-ում մենք ջոկեցինք yandex-cloud-controller-manager-ը և ավելացրինք բացակայող գործառույթները:

Հիմնական հատկանիշները

Ներկայումս CCM-ն աջակցում է հետևյալ միջերեսներին.

• Դեպքեր;
• գոտիներ;
• LoadBalancer.

Ապագայում, երբ Yandex.Cloud-ը սկսի աշխատել VPC առաջադեմ հնարավորություններով, մենք կավելացնենք ինտերֆեյս երթուղիներ.

LoadBalanacer-ը որպես հիմնական մարտահրավեր

Սկզբում մենք փորձեցինք, ինչպես 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 պետք է փոխանցել լիազորված բանալիները ծառայության հաշվից: Փաստաթղթերում նկարագրված է, ինչպես ստեղծել ծառայության հաշիվ և ստանալ բանալիներ:

Մենք ուրախ կլինենք ստանալ ձեր կարծիքը և նոր հարցերեթե որևէ խնդրի հանդիպեք!

Արդյունքները

Մենք վերջին երկու շաբաթվա ընթացքում օգտագործում ենք CCM-ը հինգ Kubernetes կլաստերներում և նախատեսում ենք առաջիկա ամսվա ընթացքում ընդլայնել դրանց թիվը մինչև 20: Ներկայումս մենք խորհուրդ չենք տալիս օգտագործել CCM խոշոր և կարևոր K8-ների տեղադրման համար:

Ինչպես CSI-ի դեպքում, մենք ուրախ կլինենք, եթե Yandex-ի ծրագրավորողները ստանձնեն այս նախագծի մշակումն ու աջակցությունը. մենք պատրաստ ենք փոխանցել պահեստը նրանց խնդրանքով, որպեսզի զբաղվենք մեզ համար ավելի համապատասխան առաջադրանքներով:

PS

Կարդացեք նաև մեր բլոգում.

• «Yandex.Cloud-ի համար Kubernetes-ում CSI դրայվեր մշակելու մեր փորձը";
• «Հե՞շտ և հարմար է Kubernetes-ի կլաստեր պատրաստելը: Հայտարարում է հավելում-օպերատոր";
• «Kubernetes-ի ընդլայնում և լրացում (ակնարկ և վիդեո զեկույց).

Source: www.habr.com