Tunakuletea Kubernetes CCM (Meneja wa Kidhibiti cha Wingu) ya Yandex.Cloud

Katika muendelezo wa hivi karibuni Utoaji wa dereva wa CSI kwa Yandex.Cloud tunachapisha mradi mwingine wa Open Source kwa wingu hili - Meneja wa Kidhibiti cha Wingu. CCM inahitajika sio tu kwa nguzo kwa ujumla, lakini pia kwa dereva wa CSI yenyewe. Maelezo kuhusu madhumuni yake na baadhi ya vipengele vya utekelezaji viko chini ya kata.

Utangulizi

Kwa nini hii?

Nia zilizotusukuma kukuza CCM kwa Yandex.Cloud zinaendana kabisa na zile ambazo tayari zimeelezewa ndani tangazo Madereva ya CSI. Tunadumisha makundi mengi ya Kubernetes kutoka kwa watoa huduma mbalimbali wa mtandao, ambayo sisi hutumia zana moja. Inatumia manufaa mengi "kukwepa" suluhu zinazosimamiwa za watoa huduma hawa. Ndiyo, tuna kesi na mahitaji maalum, lakini maendeleo yaliyoundwa kwa sababu yao yanaweza kuwa na manufaa kwa watumiaji wengine.

CCM ni nini hasa?

Kwa kawaida, tunatayarisha mazingira yanayotuzunguka kwa nguzo kutoka nje - kwa mfano, kwa kutumia Terraform. Lakini wakati mwingine kuna haja ya kusimamia mazingira ya wingu karibu nasi kutoka kwa nguzo. Uwezekano huu umetolewa, na ndio unaotekelezwa TLC.

Hasa, Kidhibiti cha Kidhibiti cha Wingu hutoa aina tano kuu za mwingiliano:

1. Mifano - hutumia uhusiano wa 1: 1 kati ya kitu cha nodi huko Kubernetes (Node) na mashine pepe katika mtoaji wa wingu. Kwa hili sisi:
   • kujaza shambani spec.providerID katika kitu Node. Kwa mfano, kwa OpenStack CCM uwanja huu una umbizo lifuatalo: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Unaweza kuona jina la mtoa huduma wa wingu na UUID ya kipekee ya seva (mashine halisi katika OpenStack) ya kitu;
   • kamilisha nodeInfo katika kitu Node habari kuhusu mashine virtual. Kwa mfano, tunataja aina ya mfano katika AWS;
   • Tunaangalia uwepo wa mashine ya kawaida kwenye wingu. Kwa mfano, ikiwa kitu Node akaenda katika hali NotReady, unaweza kuangalia kama mashine pepe iko kabisa katika mtoaji wa huduma ya wingu kwa providerID. Ikiwa haipo, futa kitu Node, ambayo vinginevyo ingebaki kwenye nguzo milele;
2. Kanda - huweka kikoa cha kushindwa kwa kitu Node, ili mpangaji aweze kuchagua node kwa Pod kulingana na mikoa na kanda katika mtoaji wa wingu;
3. LoadBalancer - wakati wa kuunda kitu Service na aina LoadBalancer huunda aina ya kusawazisha ambayo itaelekeza trafiki kutoka nje hadi nodi za nguzo. Kwa mfano, katika Yandex.Cloud unaweza kutumia NetworkLoadBalancer и TargetGroup kwa madhumuni haya;
4. Njia - hujenga mtandao kati ya nodi, kwa sababu Kulingana na mahitaji ya Kubernetes, kila ganda lazima liwe na anwani yake ya IP na liweze kufikia ganda lingine lolote. Kwa madhumuni haya, unaweza kutumia mtandao unaowekelea (VXLAN, GENEVE) au kuweka jedwali la kuelekeza moja kwa moja kwenye mtandao pepe wa mtoa huduma wa wingu:

   

5. Kiasi - Inaruhusu kuagiza kwa nguvu kwa PV kwa kutumia PVC na SC. Hapo awali, utendaji huu ulikuwa sehemu ya CCM, lakini kutokana na ugumu wake mkubwa ulihamishiwa kwenye mradi tofauti, Kiolesura cha Kuhifadhi Kontena (CSI). Tumezungumza kuhusu CSI zaidi ya mara moja писали na, kama ilivyotajwa tayari, hata iliyotolewa Dereva wa CSI.

Hapo awali, msimbo wote unaoingiliana na wingu ulikuwa kwenye hazina kuu ya Git ya mradi wa Kubernetes. k8s.io/kubernetes/pkg/cloudprovider/providers, lakini waliamua kuachana na hii kwa sababu ya usumbufu wa kufanya kazi na msingi mkubwa wa nambari. Utekelezaji wote wa zamani umehamishwa hadi hifadhi tofauti. Kwa urahisi wa usaidizi zaidi na maendeleo, vipengele vyote vya kawaida pia vilihamishwa hifadhi tofauti.

Kama ilivyo kwa CSI, watoa huduma wengi wakubwa wa wingu tayari wameunda CCM zao ili kuongeza wingu kwenye Kubernetes. Ikiwa muuzaji hana CCM, lakini kazi zote muhimu zinapatikana kupitia API, basi unaweza kutekeleza CCM mwenyewe.

Kuandika utekelezaji wako wa CCM, inatosha kutekeleza violesura vya Go vinavyohitajika.

И hii ndio tuliyo nayo.

Utekelezaji

Umefikaje hapa

Tulianza maendeleo (au tuseme, hata kutumia) na tayari(!) CCM kwa Yandex.Cloud mwaka mmoja uliopita.

Walakini, katika utekelezaji huu tulikosa:

• uthibitishaji kupitia ishara ya JWT IAM;
• Usaidizi wa kidhibiti cha huduma.

Kwa makubaliano na mwandishi (dlisin) katika Telegramu, tuligawanya yandex-cloud-controller-manager na kuongeza vipengele vilivyokosekana.

Vipengele muhimu

Kwa sasa, CCM inaunga mkono violesura vifuatavyo:

• Mifano;
• Kanda;
• LoadBalancer.

Katika siku zijazo, wakati Yandex.Cloud inapoanza kufanya kazi na uwezo wa juu wa VPC, tutaongeza kiolesura njia.

LoadBalanacer kama changamoto kuu

Hapo awali, tulijaribu, kama utekelezaji mwingine wa CCM, kuunda jozi LoadBalancer и TargetGroup kwa kila Service na aina LoadBalancer. Hata hivyo, Yandex.Cloud iligundua kizuizi kimoja cha kuvutia: huwezi kutumia TargetGroups pamoja na kukatiza Targets (jozi SubnetID - IpAddress).

Kwa hiyo, ndani ya CCM iliyoundwa, kidhibiti kinazinduliwa, ambacho, wakati vitu vinabadilika Node hukusanya taarifa kuhusu violesura vyote kwenye kila mashine pepe, huvipanga kulingana na mali zao za fulani NetworkID, inaunda na TargetGroup juu ya NetworkID, na pia hufuatilia umuhimu. Baadaye, wakati wa kuunda kitu Service na aina LoadBalanacer sisi tu ambatisha iliyoundwa kabla TargetGroup mpya NetworkLoadBalanacer'am.

Jinsi ya kuanza kutumia?

CCM inaunga mkono toleo la Kubernetes 1.15 na matoleo mapya zaidi. Katika nguzo, ili ifanye kazi, inahitaji bendera --cloud-provider=external iliwekwa true kwa kube-apiserver, kube-controller-manager, kube-scheduler na kubelets zote.

Hatua zote muhimu kwa ajili ya ufungaji yenyewe zimeelezwa ndani README. Usakinishaji huanzia hadi kuunda vitu katika Kubernetes kutoka kwa maonyesho.

Ili kutumia CCM utahitaji pia:

• zinaonyesha katika dhihirisho la kitambulisho cha saraka (folder-id) Yandex.Cloud;
• akaunti ya huduma kwa kuingiliana na Yandex.Cloud API. Katika ilani Secret inahitajika kuhamisha funguo zilizoidhinishwa kutoka kwa akaunti ya huduma. Katika nyaraka ilivyoelezwa, jinsi ya kuunda akaunti ya huduma na kupata funguo.

Tutafurahi kupokea maoni yako na masuala mapyaukikutana na matatizo yoyote!

Matokeo ya

Tumekuwa tukitumia CCM iliyotekelezwa katika makundi matano ya Kubernetes katika kipindi cha wiki mbili zilizopita na tunapanga kupanua idadi yao hadi 20 katika mwezi ujao. Kwa sasa hatupendekezi kutumia CCM kwa mitambo mikubwa na muhimu ya K8s.

Kama ilivyo kwa CSI, tutafurahi ikiwa watengenezaji wa Yandex watachukua maendeleo na usaidizi wa mradi huu - tuko tayari kuhamisha hazina kwa ombi lao ili kushughulikia kazi ambazo ni muhimu zaidi kwetu.

PS

Soma pia kwenye blogi yetu:

• «Uzoefu wetu katika kutengeneza kiendesha CSI katika Kubernetes kwa Yandex.Cloud";
• «Je, ni rahisi na rahisi kuandaa nguzo ya Kubernetes? Inatangaza kiendeshaji cha kuongeza";
• «Kupanua na kukamilisha Kubernetes (hakiki na ripoti ya video)'.

Chanzo: mapenzi.com