Gure esperientzia Yandex.Cloud-erako Kubernetes-en CSI kontrolatzailea garatzen

Atsegin handiz iragartzen dugu Flant-ek Kubernetesentzako kode irekiko tresnetarako bere ekarpena zabaltzen ari dela kaleratuz. CSI kontrolatzailearen alfa bertsioa (Container Storage Interface) Yandex.Cloud-erako.

Baina ezarpenaren xehetasunetara joan aurretik, erantzun diezaiogun galderari zergatik behar den hori Yandex-ek dagoeneko zerbitzu bat duenean. Kubernetesentzako Kudeatutako Zerbitzua.

Sarrera

Zergatik da hau?

Gure enpresaren barruan, Kubernetes ekoizpenean erabiltzen hasi zenetik (hau da, hainbat urte daramatzagu), gure tresna propioa garatzen ari gara (deckhouse), eta, bide batez, laster Kode irekiko proiektu gisa ere eskuragarri jartzeko asmoa dugu. . Haren laguntzarekin, gure kluster guztiak modu uniformean konfiguratzen eta konfiguratzen ditugu, eta gaur egun dagoeneko 100 baino gehiago daude, hardware konfigurazio ugaritan eta hodeiko zerbitzu eskuragarri guztietan.

Deckhouse erabiltzen duten klusterrek funtzionamendurako beharrezkoak diren osagai guztiak dituzte: orekatzaileak, grafiko erosoekin monitorizatzea, metrika eta alertak, erabiltzaileen autentifikazioa kanpoko hornitzaileen bidez aginte-panel guztietara sartzeko, eta abar. Ez du balio kudeatutako soluzio batean halako kluster "pumped up" bat instalatzeak, askotan ezinezkoa baita edo osagaien erdia desgaitu beharra ekarriko baitu.

NB: Hau da gure esperientzia, eta nahiko zehatza da. Ez dugu inola ere iradokitzen bakoitzak Kubernetes klusterrak bere kabuz inplementatu behar dituenik, prest egindako irtenbideak erabili beharrean. Bide batez, ez dugu Yandexetik Kubernetes funtzionatzeko benetako esperientziarik eta ez dugu zerbitzu honen inguruko baloraziorik emango artikulu honetan.

Zer da eta norentzat?

Beraz, Kubernetesen biltegiratzeko ikuspegi modernoari buruz hitz egin dugu dagoeneko: nola funtzionatzen du CSIk? и komunitatea nola etorri zen planteamendu honi.

Gaur egun, hodeiko zerbitzu hornitzaile handi askok beren hodeiko diskoak Kubernetesen Bolumen iraunkor gisa erabiltzeko kontrolatzaileak garatu dituzte. Hornitzaileak ez badu horrelako kontrolatzailerik, baina beharrezko funtzio guztiak APIaren bidez ematen badira, ezerk ez zaitu eragozten kontrolatzailea zuk zeuk inplementatzea. Hau da Yandex.Cloud-ekin gertatu dena.

Garapenerako oinarritzat hartu genuen DigitalOcean hodeirako CSI kontrolatzailea eta ideia pare bat GCPrako kontrolatzaileak, hodei hauen APIarekin (Google eta Yandex) elkarreraginak antzekotasun ugari dituelako. Bereziki, API eta GCP, eta orduetan Yandex objektu bat itzuli Operation Iraupen luzeko eragiketen egoeraren jarraipena egiteko (adibidez, disko berri bat sortzea). Yandex.Cloud APIarekin elkarreragiteko, erabili Yandex.Cloud Go SDK.

Egindako lanaren emaitza GitHub-en argitaratua eta erabilgarria izan daiteke, arrazoiren bategatik, Yandex.Cloud makina birtualetan Kubernetes instalazio propioa erabiltzen dutenentzat (baina ez prest egindako kudeatutako kluster batean) eta CSI bidez diskoak (eskatu) erabili nahi dituztenentzat.

Inplementazioa

Funtsezko ezaugarriak

Gaur egun, gidariak funtzio hauek onartzen ditu:

• Klustereko zona guztietan diskoak ordenatzea klusterreko nodoen topologiaren arabera;
• Aurretik agindutako diskoak kentzea;
• Lineaz kanpoko tamaina aldatu diskoetarako (Yandex.Cloud ez onartzen makina birtualean muntatzen diren diskoak handituz). Gidaria nola aldatu behar izan zen tamaina aldatzeko ahalik eta minik ez izateko, ikus behean.

Etorkizunean, diskoaren argazkiak sortzeko eta ezabatzeko laguntza ezartzeko asmoa dugu.

Zailtasun nagusia eta nola gainditu

Yandex.Cloud APIan diskoak denbora errealean handitzeko gaitasunik eza PV-rako (Persistent Bolumen) tamaina aldatzeko eragiketa zailtzen duen muga da: kasu honetan, beharrezkoa da diskoa erabiltzen duen aplikazio-podea geldiaraztea, eta honek geldialdi-denbora aplikazioak eragin ditzake.

Arabera CSI zehaztapenak, CSI kontrolatzaileak esaten badu diskoak "linez kanpo" soilik tamaina alda ditzakeela (VolumeExpansion.OFFLINE), orduan diskoa handitzeko prozesua honela joan beharko litzateke:

Pluginak bakarrik badu VolumeExpansion.OFFLINE hedapen-gaitasuna eta bolumena gaur egun nodo batean argitaratu edo eskuragarri daude ControllerExpandVolume Hauen ondoren BAKARRIK deitu behar da:

• Pluginak kontrolagailua du PUBLISH_UNPUBLISH_VOLUME gaitasuna eta ControllerUnpublishVolume arrakastaz deitu da.

EDO, BESTELA

• Pluginak EZ du kontrolagailurik PUBLISH_UNPUBLISH_VOLUME gaitasuna, pluginak nodoa du STAGE_UNSTAGE_VOLUME gaitasuna, eta NodeUnstageVolume arrakastaz burutu da.

EDO, BESTELA

• Pluginak EZ du kontrolagailurik PUBLISH_UNPUBLISH_VOLUME gaitasuna, ezta nodoa ere STAGE_UNSTAGE_VOLUME gaitasuna, eta NodeUnpublishVolume arrakastaz osatu da.

Horrek esan nahi du, funtsean, diskoa makina birtualetik kendu behar duzula zabaldu aurretik.

Hala ere, zoritxarrez ezartzea sidecar bidez CSI zehaztapenak ez ditu baldintza hauek betetzen:

• Alboko edukiontzi batean csi-attacher, muntaien arteko behar den hutsunearen presentziaz arduratu beharko litzatekeena, funtzionalitate hau ez da inplementatzen lineaz kanpoko tamainan. Horren inguruko eztabaida abiatu zen Hemen.
• Zer da zehazki sidecar edukiontzi bat testuinguru honetan? CSI pluginak berak ez du Kubernetes APIarekin elkarreragiten, baizik eta sidecar edukiontziek bidalitako gRPC deiei soilik erantzuten die. Azkena garatzen ari dira Kubernetes komunitatearen eskutik.

Gure kasuan (CSI plugina), diskoa handitzeko eragiketak honelako itxura du:

1. gRPC dei bat jasotzen dugu ControllerExpandVolume;
2. APIan diskoa handitzen saiatzen ari gara, baina diskoa muntatuta dagoelako eragiketa egiteko ezintasunari buruzko errore bat jasotzen dugu;
3. Disko-identifikatzailea mapan gordetzen dugu, handitze-eragiketa egin behar den diskoak biltzen dituena. Jarraian, laburtzeko, honela deituko diogu mapa honi volumeResizeRequired;
4. Kendu eskuz diskoa erabiltzen ari den poda. Kubernetes-ek berrabiaraziko du. Diskoak muntatzeko denborarik ez izan dezan (ControllerPublishVolume) igoera eragiketa amaitu aurretik muntatzen saiatzean, emandako diskoa oraindik sartuta dagoela egiaztatuko dugu volumeResizeRequired eta errore bat itzuli;
5. CSI kontrolatzailea tamaina aldatzeko eragiketa berriro exekutatzen saiatzen da. Eragiketa arrakastatsua izan bada, kendu diskoa volumeResizeRequired;
6. Zeren Disko IDa falta da volumeResizeRequired, ControllerPublishVolume arrakastaz pasatzen da, diskoa muntatzen da, poda abiarazten da.

Dena nahiko sinplea dirudi, baina beti bezala akatsak daude. Diskoak handitzen ditu kanpoko-dimentsionatzailea, funtzionamenduan akatsen bat gertatuz gero ilara bat erabiltzen du 1000 segundora arte denbora-muga denboraren hazkunde esponentzialarekin:

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)},
  )
}

Honek aldian-aldian diskoa hedatzeko eragiketa 15 minutu baino gehiago luzatzea eragin dezake eta, beraz, dagokion poda erabilgarri ez egotea.

Balizko geldialdi-denbora murrizteko erraz eta minik gabe utzi zigun aukera bakarra kanpoko-dimentsionatzailearen bertsioa erabiltzea izan zen, gehienezko denbora-muga batekin. 5 segundotan:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

Ez genuen beharrezkotzat jo eztabaida bat abiaraztea eta kanpoko-dimentsionatzailea adabakitzea, lineaz kanpoko diskoen tamaina aldatzea laster hodeiko hornitzaile guztietatik desagertuko den atzerakada delako.

Nola hasi erabiltzen?

Gidaria Kubernetes 1.15 bertsioan eta bertsio berriagoetan onartzen da. Gidariak lan egiteko, baldintza hauek bete behar dira:

• bandera --allow-privileged balioan ezarri true API zerbitzarirako eta kubeleterako;
• Barne --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API zerbitzarirako eta kubeleterako;
• Mendiaren hedapena (mendiaren hedapena) klusterrean gaituta egon behar da. Docker erabiltzean, deabrua konfiguratu behar da muntaketa partekatuak baimentzeko.

Instalazioa bera egiteko beharrezko urrats guztiak README-n deskribatuta. Instalazioak Kubernetesen objektuak sortzea dakar manifestetatik.

Gidariak lan egiteko honako hauek beharko dituzu:

• Zehaztu direktorio-identifikatzailea manifestuan (folder-id) Yandex.Cloud (ikusi dokumentazioa);
• Yandex.Cloud APIarekin elkarreragiteko, CSI kontrolatzaileak zerbitzu-kontu bat erabiltzen du. Manifestuan, Secret pasa behar da baimendutako giltzak zerbitzu-kontutik. Dokumentazioan deskribatu, nola sortu zerbitzu-kontua eta giltzak nola lortu.

Dena kontuan hartuta - saiatu, eta pozik jasoko dugu iritzia eta gai berriakarazorik aurkitzen baduzu!

Laguntza gehiago

Ondorioz, adierazi nahi dugu CSI kontrolatzaile hau ez Go-n aplikazioak idazten ondo pasatzeko gogo handiagatik ezarri dugula, baizik eta enpresa barruan premiazko beharragatik. Ez zaigu praktikoa iruditzen gure inplementazioa mantentzea, beraz, Yandex-ek interesa erakusten badu eta gidariari laguntzen jarraitzea erabakitzen badu, pozik eramango dugu biltegia haiei.

Horrez gain, Yandex-ek ziurrenik CSI kontrolatzailearen inplementazio propioa du Kubernetes kudeatzen duen klusterrean, kode irekian kaleratu daitekeena. Garapen-aukera hau ere mesedegarri ikusten dugu: komunitateak zerbitzu-hornitzaile baten gidari frogatua erabili ahal izango du, eta ez hirugarrenen konpainia batena.

PS

Irakurri ere gure blogean:

• «Kubernetes biltegiratzeko bolumen-pluginak: Flexvolume-tik CSIra»;
• «Edukiontzien Biltegiratze Interfazea ulertzen dugu (Kubernetes-en eta ez bakarrik)»;
• «Erraza eta erosoa al da Kubernetes kluster bat prestatzea? Eragile gehigarria iragartzen du»;
• «Kubernetes zabaltzea eta osatzea (berrikuspena eta bideo-txostena)'.

Iturria: www.habr.com