ProHoster > Eksperienca jonë në zhvillimin e drejtuesit të CSI në Kubernetes për Yandex.Cloud

Eksperienca jonë në zhvillimin e drejtuesit të CSI në Kubernetes për Yandex.Cloud

Eksperienca jonë në zhvillimin e drejtuesit të CSI në Kubernetes për Yandex.Cloud

Jemi të lumtur të njoftojmë se kompania «Flant» po kontribuon më tej në mjetet Open Source për Kubernetes duke lëshuar versionin alfa të ndihmësit CSI (Container Storage Interface) për Yandex.Cloud.

Por para se të kalojmë në detajet e zbatimit, le të përgjigjemi në pyetjen: përse është kjo e nevojshme, kur Yandex tashmë ka shërbimin Shërbimi Menaxhuar për Kubernetes.

Hyrje

Pse kjo?

Që nga fillimi i përdorimit të Kubernetes në prodhim (në fakt, prej disa vitesh), brenda kompanisë tonë është zhvilluar një mjet i veçantë (deckhouse), i cili, për ta thënë me të vërtetë, ne gjithashtu planifikojmë ta bëjmë në dispozicion si një projekt Open Source së shpejti. Me këtë mjet ne konfigurojmë dhe rregullojmë njëlloj të gjithë klasterët tanë, dhe aktualisht kemi më shumë se 100, në konfigurime të ndryshme hardueri dhe në të gjitha shërbimet e disponueshme në cloud.

Klasterët që përdorin deckhouse kanë të gjithë komponentët e nevojshëm për funksionimin: balancues, monitorim me grafikë të rehatshme, metrika dhe alerte, autentifikimin e përdoruesve përmes ofruesve të jashtëm për qasje në të gjithë dashboard-et dhe kështu me radhë. Një klaster i tillë "i fuqizuar" nuk ka kuptim të vendoset në një zgjidhje të menaxhuar, sepse shpesh kjo është e pamundur ose do të kërkojë çaktivizimin e gjysmës së komponentëve.

NB: Ky është përvoja jonë dhe ajo është mjaft specifike. Ne asnjëherë nuk pretendojmë se të gjithë duhet të merren me vendosjen e klasterëve Kubernetes në vend të përdorimit të zgjidhjeve të gatshme. Po ashtu, ne nuk kemi përvojë të vërtetë në përdorimin e Kubernetes nga Yandex dhe nuk do të japim ndonjë vlerësim për këtë shërbim në këtë artikull.

ÇfarĂ« Ă«shtĂ« kjo dhe pĂ«r kĂ«?

Kështu, ne tashmë kemi folur për qasjen moderne ndaj ruajtjes në Kubernetes: si është ndërtuar CSI dhe si arriti komuniteti në këtë qasje.

Aktualisht, shumë ofrues të mëdhenj të shërbimeve cloud kanë zhvilluar ndihmës për të përdorur diskët e tyre "cloud" si Volume të Eshte zgjatur në Kubernetes. Nëse një ndihmës i tillë nuk ekziston te ofruesi, por të gjitha funksionet e nevojshme janë në dispozicion përmes API, atëherë askush nuk e pengon atëherë të implementojë ndihmësin me forcat e tij. Kjo ndodhi me ne me Yandex.Cloud.

Ne morëm si bazë për zhvillim ndihmësin CSI për cloud-in DigitalOcean dhe disa ide nga ndihmësi për GCP, pasi ndërveprimi me API-në e këtyre cloud-eve (Google dhe Yandex) ka disa ngjashmëri. Në veçanti, API ka GCP, dhe Yandex kthen objekti Operacioni për të ndjekur statusin e operacioneve të gjata (p.sh., krijimi i një disku të ri). Për të ndërvepruar me API-në e Yandex.Cloud përdoret Yandex.Cloud Go SDK.

Rezultati i punës së kryer është publikuar në GitHub dhe mund të jetë i dobishëm për ata që për një arsye apo tjetër përdorin instalimin e tyre të Kubernetes në makinat virtuale të Yandex.Cloud (por jo një klastri të menaxhuar) dhe do të donin të përdorin (të porositin) disqet përmes CSI.

Realizimi

Përgjegjësi kryesore

Aktualisht, drejtori mbështet funksionet e mëposhtme:

  • PorositĂ« e disqeve nĂ« tĂ« gjitha zonat e klastri sipas topologjisĂ« sĂ« nyjeve tĂ« disponueshme nĂ« klasĂ«r;
  • Fshirja e disqeve tĂ« porositura mĂ« parĂ«;
  • Resize offline pĂ«r disqet (Yandex.Cloud nuk mbĂ«shtet rritja e disqeve qĂ« janĂ« tĂ« montuara nĂ« makinat virtuale). PĂ«r mĂ«nyrĂ«n se si u desh tĂ« rregullohej drejtori pĂ«r tĂ« kryer resize nĂ« mĂ«nyrĂ« sa mĂ« pa dhimbje, shiko mĂ« poshtĂ«.

Në të ardhmen, është parashikuar të realizohet mbështetje për krijimin dhe fshirjen e snapshoteve të disqeve.

Vështirësia kryesore dhe tejkalimi i saj

Mungesa në API-në e Yandex.Cloud e mundësisë për të rritur disqet në kohë reale - një kufizim që e komplikon operacionin e resize për PV (Volume të Përshtatshëm): pasi në këtë rast është e nevojshme që pod-i i aplikacionit që përdor disku të ndalet, dhe kjo mund të shkaktojë ndalim të aplikacionit.

Sipas specifikacioni CSI, nĂ«se CSI-kontrolleri raporton se di tĂ« bĂ«jĂ« resize disqesh vetĂ«m “nĂ« offline” (VolumeExpansion.OFFLINE), atĂ«herĂ« procesi i rritjes sĂ« diskut duhet tĂ« kalojĂ« kĂ«shtu:

NĂ«se plugu i ka vetĂ«m VolumeExpansion.OFFLINE kapacitetin e zgjerimit dhe volumi aktualisht Ă«shtĂ« publikuar ose nĂ« dispozitĂ« nĂ« njĂ« nyje, atĂ«herĂ« ControllerExpandVolume DUHET tĂ« thirret VETËM pas ose:

  • Pluga ka PUBLISH_UNPUBLISH_VOLUME kapacitetin dhe ControllerUnpublishVolume Ă«shtĂ« thirrur me sukses.

OSE NJËTJETËR

  • Pluga NUK ka kapacitetin e kontrollit, pluga ka nyjĂ« PUBLISH_UNPUBLISH_VOLUME STAGE_UNSTAGE_VOLUME kapacitetin, dhe NodeUnstageVolume Ă«shtĂ« pĂ«rfunduar me sukses. kapaciteti, as nyja

OSE NJËTJETËR

  • Pluga NUK ka kapacitetin e kontrollit, pluga ka nyjĂ« PUBLISH_UNPUBLISH_VOLUME NodeUnpublishVolume kapacitetin, dhe NodeUnstageVolume nuk Ă«shtĂ« pĂ«rfunduar me sukses. ka pĂ«rfunduar me sukses.

Në thelb, kjo do të thotë se është e nevojshme të shkëputet disku nga makinat virtuale përpara se të rritet.

Megjithatë, fatkeqësisht, implementimi specifikimet e CSI përmes sidecar-ëve nuk i përmbushin këto kërkesa:

  • NĂ« kontejnerin sidecar csi-attacher, i cili duhet tĂ« pĂ«rgjigjet pĂ«r tĂ« siguruar intervalin e nevojshĂ«m midis montimeve, gjatĂ« offline-resize nuk Ă«shtĂ« realizuar ky funksionalitet. Diskutimi pĂ«r kĂ«tĂ« e iniciuan kĂ«tu.
  • ÇfarĂ« Ă«shtĂ« njĂ« kontenier sidecar nĂ« kĂ«tĂ« kontekst? Plugins-i CSI nuk merret me ndĂ«rveprimin me API-nĂ« Kubernetes, ai vetĂ«m reagon nĂ« thirrjet gRPC, tĂ« cilat i dĂ«rgojnĂ« kontenierĂ«t sidecar. KĂ«ta tĂ« fundit zhvillohet nga komuniteti Kubernetes.

Në rastin tonë (plugin-i CSI) operacioni i zgjerimit të diskut duket kështu:

  1. Marrim thirrjen gRPC ControllerExpandVolume;
  2. Përpiqemi të zgjedhim diskun në API, por marrim një gabim për pamundësinë e realizimit të operacionit, sepse disku është i montuar;
  3. Ruajmë identifikuesin e diskut në një hartë, që përmban disqet, për të cilat duhet të kryhet operacioni i zgjerimit. Më vonë, për shkak të shkurtësisë, do ta quajmë këtë hartë si volumeResizeRequired;
  4. Manualisht heqim pod-in, i cili përdor diskun. Kubernetes do ta rindezë atë. Në mënyrë që disku të mos montohenControllerPublishVolumepara përfundimit të operacionit të zgjerimit gjatë përpjekjes për montim, kontrollojmë që ky disk të jetë ende në volumeResizeRequired dhe kthejmë një gabim;
  5. Shoferi CSI përpiqet ta kryejë përsëri operacionin e zgjerimit. Nëse operacioni kalon me sukses, atëherë heqim diskun nga volumeResizeRequired;
  6. Nëse identifikuesi i diskut nuk është i pranishëm në volumeResizeRequired, ControllerPublishVolume kalon me sukses, disku montohen, pod-i aktivizohet.

E gjithë kjo duket mjaft e thjeshtë, por siç ndodh gjithmonë, ka disa pengesa. Zgjerimin e disqeve e menaxhon external-resizer, i cili në rast gabimi gjatë realizimit të operacionit përdor një radhë me rritje eksponenciale të kohës së skadimit deri në 1000 sekonda:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  \/\/ 10 qps, 100 bucket size. Kjo është vetëm për shpejtësinë e riprovimit dhe është vetëm faktori i përgjithshëm (jo për çdo artikull)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

Kjo mund të çojë përherë në rritjen e operacionit të zgjerimit të diskut për 15+ minuta dhe, kështu, në mungesën e përkatës të pod-it.

E vetmja mundësi, e cila na lejojë të reduktojmë kohën e mundshme të papunësisë lehtësisht dhe pa dhimbje, ishte përdorimi i versionit tonë të external-resizer me maximin e kohës së skadimit në 5 sekonda:

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

Nuk arritëm të diskutojmë me urgjencë dhe të patch-ojmë external-resizer, sepse rritja offline e disqeve është një relikt, i cili së shpejti do të zhduket nga të gjithë ofruesit e reja cloud.

Si të filloni ta përdorni?

Shoferi mbështetet në Kubernetes versionin 1.15 dhe më të lartë. Për të punuar shoferi duhet të plotësojnë kërkesat e mëposhtme:

  • Flamuri --allow-privileged caktuar nĂ« vlerĂ« e vĂ«rtetĂ« pĂ«r serverin API dhe kubelet;
  • Aktivizuar --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true pĂ«r serverin API dhe kubelet;
  • Propagimi i montimit (mount propagation) duhet tĂ« jetĂ« i aktivizuar nĂ« klaster. Kur pĂ«rdoret Docker, demon duhet tĂ« jetĂ« i konfiguruar nĂ« mĂ«nyrĂ« qĂ« tĂ« lejojĂ« objektet e ndara tĂ« montimit (shared mounts).

Të gjitha hapat e nevojshëm për instalimin e vetë janë të përshkruara në README. Instalimi përfshin krijimin e objekteve në Kubernetes nga manifestet.

Për të punuar me driverin do t'ju nevojitet ajo që vijon:

  • TĂ« specifikoni nĂ« manifest identifikuesin e katalogut (folder-id) tĂ« Yandex.Cloud (shihni dokumentacionin);
  • PĂ«r tĂ« komunikuar me API-nĂ« e Yandex.Cloud nĂ« driverin CSI pĂ«rdoret njĂ« llogari shĂ«rbyese. NĂ« manifestin Secret nevojitet tĂ« kaloni çelĂ«sat e autorizuar nga llogaria e shĂ«rbimit. NĂ« dokumentacionin janĂ« pĂ«rshkruar, si tĂ« krijoni njĂ« llogari shĂ«rbimi dhe tĂ« merrni çelĂ«sat.

NĂ« pĂ«rgjithĂ«si — provojeni, dhe ne do tĂ« ishim tĂ« lumtur pĂ«r çdo feedback dhe probleme tĂ« reja, nĂ«se hasni ndonjĂ« problem!

Mbështetje e mëtejshme

Në përfundim, do të donim të theksonim se ky driver CSI është realizuar jo për një dëshirë të madhe për të ndihmuar me shkruar aplikacione në Go, por për shkak të një nevoje të ngutshme brenda kompanisë. Të mbash një implementim tëndin nuk na duket praktik, prandaj, nëse Yandex tregon interes dhe vendos të vazhdojë mbështetje e driverit, do ta kalojmë repo-n me kënaqësi në duar e tyre.

PĂ«r mĂ« tepĂ«r, ndoshta Yandex ka njĂ« implementim tĂ« vetin tĂ« driverit CSI nĂ« klasterin e menaxhuar Kubernetes, qĂ« mund tĂ« lĂ«shohet nĂ« Open Source. NjĂ« zhvillim i tillĂ« na duket gjithashtu favorizues — komuniteti mund tĂ« pĂ«rfitojĂ« nga njĂ« driver i provuar nga ofruesi i shĂ«rbimeve, e jo nga njĂ« kompani e jashtme.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster