ProHoster > Dienoraštis > Administravimas > Mūsų patirtis kuriant CSI tvarkyklę Kubernetes, skirta Yandex.Cloud

Mūsų patirtis kuriant CSI tvarkyklę Kubernetes, skirta Yandex.Cloud

Mūsų patirtis kuriant CSI tvarkyklę Kubernetes, skirta Yandex.Cloud

Džiaugiamės galėdami pranešti, kad „Flant“ plečia savo indėlį į „Kubernetes“ atvirojo kodo įrankius, išleisdamas CSI tvarkyklės alfa versija (konteinerių saugojimo sąsaja), skirta Yandex.Cloud.

Tačiau prieš pereidami prie diegimo detalių, atsakykime į klausimą, kodėl to apskritai reikia, kai „Yandex“ jau turi paslaugą „Kubernetes“ valdoma paslauga.

įvedimas

Kodėl tai?

Savo įmonėje nuo pat Kubernetes naudojimo gamyboje pradžios (t. y. jau keletą metų) kūrėme savo įrankį (deckhouse), kurį, beje, taip pat planuojame netrukus pateikti kaip atvirojo kodo projektą. . Jo pagalba vienodai konfigūruojame ir konfigūruojame visus savo klasterius, o šiuo metu jų jau yra daugiau nei 100, įvairiose aparatinės įrangos konfigūracijose ir visose prieinamose debesijos paslaugose.

Klasteriai, kurie naudoja deckhouse, turi visus darbui būtinus komponentus: balansavimo priemones, stebėjimą su patogiomis diagramomis, metriką ir įspėjimus, vartotojo autentifikavimą per išorinius tiekėjus, kad būtų galima pasiekti visas prietaisų skydelius ir pan. Nėra prasmės diegti tokį „pripumpuotą“ klasterį valdomame sprendime, nes tai dažnai neįmanoma arba dėl to reikės išjungti pusę komponentų.

NB: Tai mūsų patirtis ir gana specifinė. Mes jokiu būdu nesiūlome, kad kiekvienas turėtų diegti Kubernetes grupes atskirai, o ne naudoti paruoštus sprendimus. Beje, mes neturime realios „Yandex“ operacinės „Kubernetes“ patirties ir šiame straipsnyje nepateiksime šios paslaugos įvertinimo.

Kas tai yra ir kam?

Taigi, mes jau kalbėjome apie šiuolaikinį požiūrį į saugojimą Kubernetes: kaip veikia CSI? и kaip atsirado bendruomenė prie šio požiūrio.

Šiuo metu daugelis didelių debesų paslaugų teikėjų sukūrė tvarkykles, skirtas naudoti savo debesies diskus kaip nuolatinį tomą Kubernetes. Jei tiekėjas neturi tokios tvarkyklės, bet visos reikalingos funkcijos yra teikiamos per API, tada niekas netrukdo jums įdiegti tvarkyklės patiems. Taip atsitiko su „Yandex.Cloud“.

Mes ėmėmės plėtros pagrindu CSI tvarkyklė, skirta DigitalOcean debesiui ir pora idėjų iš GCP tvarkyklės, nes sąveika su šių debesų API („Google“ ir „Yandex“) turi nemažai panašumų. Visų pirma, API ir GKPir "Yandex" grąžinti daiktą Operation stebėti ilgai vykdomų operacijų būseną (pavyzdžiui, kuriant naują diską). Norėdami bendrauti su Yandex.Cloud API, naudokite Yandex.Cloud Go SDK.

Atlikto darbo rezultatas paskelbta GitHub ir gali būti naudinga tiems, kurie dėl kokių nors priežasčių naudoja savo Kubernetes diegimą Yandex.Cloud virtualiose mašinose (bet ne paruoštą valdomą klasterį) ir norėtų naudoti (užsisakyti) diskus per CSI.

Vykdymas

Pagrindinės savybės

Šiuo metu tvarkyklė palaiko šias funkcijas:

  • Diskų užsakymas visose klasterio zonose pagal klasterio mazgų topologiją;
  • Anksčiau užsakytų diskų išėmimas;
  • Diskų dydžio keitimas neprisijungus (Yandex.Cloud nepalaiko padidinti diskų, kurie yra prijungti prie virtualios mašinos). Informacijos apie tai, kaip reikėjo pakeisti vairuotoją, kad dydžio keitimas būtų kuo neskausmingesnis, žr. toliau.

Ateityje planuojame įdiegti disko momentinių nuotraukų kūrimo ir ištrynimo palaikymą.

Pagrindinis sunkumas ir kaip jį įveikti

Galimybės padidinti diskus realiuoju laiku Yandex.Cloud API nebuvimas yra apribojimas, apsunkinantis PV (persistent Volume) dydžio keitimo operaciją: tokiu atveju būtina sustabdyti diską naudojančią programų grupę, ir tai gali sukelti programų prastovos laiką.

Pagal CSI specifikacijos, jei CSI valdiklis praneša, kad diskų dydį gali keisti tik neprisijungus (VolumeExpansion.OFFLINE), tada disko didinimo procesas turėtų vykti taip:

Jei papildinys turi tik VolumeExpansion.OFFLINE išplėtimo galimybė ir apimtis šiuo metu paskelbta arba pasiekiama mazge ControllerExpandVolume BŪTINA skambinti TIK po kurio nors:

  • Papildinys turi valdiklį PUBLISH_UNPUBLISH_VOLUME pajėgumas ir ControllerUnpublishVolume buvo sėkmingai iškviestas.

ARBA

  • Papildinys NĖRA valdiklio PUBLISH_UNPUBLISH_VOLUME galimybė, papildinys turi mazgą STAGE_UNSTAGE_VOLUME pajėgumas ir NodeUnstageVolume buvo sėkmingai baigtas.

ARBA

  • Papildinys NĖRA valdiklio PUBLISH_UNPUBLISH_VOLUME galimybė, nei mazgas STAGE_UNSTAGE_VOLUME pajėgumas ir NodeUnpublishVolume sėkmingai baigtas.

Tai iš esmės reiškia, kad prieš išplečiant diską reikia atjungti nuo virtualios mašinos.

Tačiau, deja įgyvendinimas CSI specifikacija per šonines priekabas neatitinka šių reikalavimų:

  • Šoninėje priekaboje csi-attacher, kuris turėtų būti atsakingas už reikiamo tarpo tarp laikiklių buvimą, ši funkcija tiesiog neįdiegta keičiant dydį neprisijungus. Apie tai buvo pradėta diskusija čia.
  • Kas šiame kontekste yra konteineris su šoniniu priekabu? Pats CSI įskiepis nesąveikauja su Kubernetes API, o tik reaguoja į gRPC iškvietimus, kuriuos jam siunčia šoninių vagonų konteineriai. Naujausias yra kuriami Kubernetes bendruomenė.

Mūsų atveju (CSI įskiepis) disko padidinimo operacija atrodo taip:

  1. Sulaukiame gRPC skambučio ControllerExpandVolume;
  2. Bandome padidinti diską API, bet gauname klaidą apie negalėjimą atlikti operacijos, nes diskas sumontuotas;
  3. Disko identifikatorių saugome žemėlapyje, kuriame yra diskai, kuriems reikia atlikti didinimo operaciją. Žemiau trumpumo dėlei šį žemėlapį pavadinsime kaip volumeResizeRequired;
  4. Rankiniu būdu išimkite diską naudojančią dėklą. „Kubernetes“ jį paleis iš naujo. Kad diskas neturėtų laiko montuoti (ControllerPublishVolume) prieš užbaigdami padidinimo operaciją, kai bandome prijungti, patikriname, ar nurodytas diskas vis dar yra volumeResizeRequired ir grąžinti klaidą;
  5. CSI tvarkyklė bando iš naujo atlikti dydžio keitimo operaciją. Jei operacija buvo sėkminga, išimkite diską iš volumeResizeRequired;
  6. Nes Trūksta disko ID volumeResizeRequired, ControllerPublishVolume sėkmingai praeina, diskas sumontuotas, podas paleidžiamas.

Viskas atrodo pakankamai paprasta, bet kaip visada yra spąstų. Padidina diskus išorinis dydžio keitiklis, kuris operacijos metu įvykus klaidai naudoja eilę eksponentiškai padidinus skirtąjį laiką iki 1000 sekundžių:

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

Dėl to disko išplėtimo operacija gali būti periodiškai pratęsta 15 ir daugiau minučių, todėl atitinkamas blokas gali būti neprieinamas.

Vienintelė galimybė, kuri gana lengvai ir neskausmingai leido sumažinti galimą prastovą, buvo mūsų išorinio dydžio keitiklio versijos naudojimas su maksimaliu laiko limitu. per 5 sekundes:

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

Nemanėme, kad būtina skubiai inicijuoti diskusiją ir pataisyti išorinį dydžio keitiklį, nes diskų dydžio keitimas neprisijungus yra grįžimas, kuris greitai išnyks iš visų debesų tiekėjų.

Kaip pradėti vartoti?

Tvarkyklė palaikoma Kubernetes 1.15 ir naujesnėje versijoje. Kad vairuotojas galėtų dirbti, turi būti laikomasi šių reikalavimų:

  • Vėliava --allow-privileged nustatyti į vertę true API serveriui ir kubeletui;
  • Įskaitant --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API serveriui ir kubeletui;
  • Kalnų dauginimas (kalno dauginimasis) turi būti įjungtas klasteryje. Kai naudojate „Docker“, demonas turi būti sukonfigūruotas taip, kad būtų galima naudoti bendrinamus prijungimus.

Visi reikalingi žingsniai pačiam įrengimui aprašyta README. Diegimas apima objektų kūrimą Kubernetes iš manifestų.

Kad vairuotojas dirbtų, jums reikės šių dalykų:

  • Apraše nurodykite katalogo identifikatorių (folder-id) Yandex.Cloud (žiūrėti dokumentaciją);
  • Norėdami sąveikauti su Yandex.Cloud API, CSI tvarkyklė naudoja paslaugos paskyrą. Manifeste reikia perduoti paslaptį įgaliotus raktus iš paslaugų sąskaitos. Dokumentacijoje aprašyta, kaip susikurti paslaugos paskyrą ir gauti raktus.

Apskritai - pabandykite, ir mes mielai sulauksime atsiliepimų ir nauji klausimaijei susidursite su problemomis!

Tolesnė parama

Dėl to norime pažymėti, kad šią CSI tvarkyklę įdiegėme ne dėl didelio noro smagiai rašyti programas Go, o dėl neatidėliotino poreikio įmonėje. Mums neatrodo praktiška išlaikyti savo diegimą, todėl jei „Yandex“ parodys susidomėjimą ir nuspręs toliau remti vairuotoją, mes mielai perduosime saugyklą jiems.

Be to, „Yandex“ tikriausiai turi savo CSI tvarkyklės įdiegimą savo valdomame „Kubernetes“ klasteryje, kurį galima išleisti atvirojo kodo. Šią plėtros galimybę taip pat vertiname kaip palankią – bendruomenė galės naudoti patikrintą tvarkyklę iš paslaugų teikėjo, o ne iš trečiosios šalies įmonės.

PS

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Добавить комментарий