ProHoster > Blogs > Administrācija > Mūsu pieredze CSI draivera izstrādē Kubernetes for Yandex.Cloud

Mūsu pieredze CSI draivera izstrādē Kubernetes for Yandex.Cloud

Mūsu pieredze CSI draivera izstrādē Kubernetes for Yandex.Cloud

Ar prieku paziņojam, ka Flant paplaÅ”ina savu ieguldÄ«jumu Kubernetes atvērtā pirmkoda rÄ«kos, izlaižot CSI draivera alfa versija (konteinera krātuves interfeiss) Yandex.Cloud.

Bet pirms pāriet pie ievieÅ”anas detaļām, atbildēsim uz jautājumu, kāpēc tas vispār ir vajadzÄ«gs, ja Yandex jau ir pakalpojums PārvaldÄ«ts pakalpojums Kubernetes.

Ievads

Kāpēc ir Å”is?

MÅ«su uzņēmumā jau no paÅ”a Kubernetes izmantoÅ”anas sākuma ražoÅ”anā (t.i., jau vairākus gadus) esam izstrādājuÅ”i paÅ”i savu rÄ«ku (deckhouse), kuru, starp citu, drÄ«zumā plānojam arÄ« padarÄ«t pieejamu kā atvērtā koda projektu. . Ar tās palÄ«dzÄ«bu mēs vienoti konfigurējam un konfigurējam visus savus klasterus, un Å”obrÄ«d to jau ir vairāk nekā 100 dažādās aparatÅ«ras konfigurācijās un visos pieejamajos mākoņpakalpojumos.

Klasteriem, kas izmanto deckhouse, ir visas darbÄ«bai nepiecieÅ”amās sastāvdaļas: balansētāji, uzraudzÄ«ba ar ērtām diagrammām, metrika un brÄ«dinājumi, lietotāju autentifikācija, izmantojot ārējos pakalpojumu sniedzējus, lai piekļūtu visiem informācijas paneļiem utt. Nav jēgas instalēt Ŕādu ā€œuzsÅ«knētuā€ klasteru pārvaldÄ«tā risinājumā, jo tas bieži vien ir neiespējami vai radÄ«s nepiecieÅ”amÄ«bu atspējot pusi komponentu.

NB: Tā ir mÅ«su pieredze, un tā ir diezgan specifiska. Mēs nekādā gadÄ«jumā neiesakām, ka ikvienam vajadzētu izvietot Kubernetes klasterus atseviŔķi, nevis izmantot gatavus risinājumus. Starp citu, mums nav reālas pieredzes Kubernetes darbÄ«bā no Yandex, un Å”ajā rakstā mēs nesniegsim Ŕī pakalpojuma novērtējumu.

Kas tas ir un kam?

Tātad, mēs jau esam runājuÅ”i par mÅ«sdienu pieeju Kubernetes uzglabāŔanai: kā darbojas CSI? Šø kā radās sabiedrÄ«ba Å”ai pieejai.

PaÅ”laik daudzi lieli mākoņpakalpojumu sniedzēji ir izstrādājuÅ”i draiverus, lai izmantotu savus mākoņdiskus kā pastāvÄ«gu sējumu pakalpojumā Kubernetes. Ja piegādātājam nav Ŕāda draivera, bet visas nepiecieÅ”amās funkcijas tiek nodroÅ”inātas caur API, tad nekas neliedz jums paÅ”iem ieviest draiveri. Tas notika ar Yandex.Cloud.

Mēs ņēmām par pamatu attÄ«stÄ«bai CSI draiveris DigitalOcean mākonim un pāris idejas no draiveri GCP, jo mijiedarbÄ«bai ar Å”o mākoņu API (Google un Yandex) ir vairākas lÄ«dzÄ«bas. Jo Ä«paÅ”i API un GCPun plkst Yandex atgriezt objektu Operation lai izsekotu ilgstoÅ”u darbÄ«bu statusam (piemēram, jauna diska izveidei). Lai mijiedarbotos ar Yandex.Cloud API, izmantojiet Yandex.Cloud Go SDK.

Paveiktā darba rezultāts publicēts vietnē GitHub un var bÅ«t noderÄ«gi tiem, kuri kaut kādu iemeslu dēļ izmanto savu Kubernetes instalāciju Yandex.Cloud virtuālajās maŔīnās (bet ne gatavu pārvaldÄ«tu klasteru) un vēlas izmantot (pasÅ«tÄ«t) diskus, izmantojot CSI.

IevieŔana

Galvenās iezīmes

PaŔlaik draiveris atbalsta Ŕādas funkcijas:

  • Disku sakārtoÅ”ana visās klastera zonās atbilstoÅ”i klastera mezglu topoloÄ£ijai;
  • IepriekÅ” pasÅ«tÄ«to disku noņemÅ”ana;
  • Bezsaistes izmēru maiņa diskiem (Yandex.Cloud neatbalsta palielinot disku skaitu, kas ir pievienoti virtuālajai maŔīnai). Informāciju par to, kā draiveris bija jāmaina, lai izmēru maiņa bÅ«tu pēc iespējas nesāpÄ«gāka, skatiet tālāk.

Nākotnē plānojam ieviest atbalstu diska momentuzņēmumu izveidei un dzÄ“Å”anai.

Galvenās grūtības un kā tās pārvarēt

Disku palielināŔanas iespējas reāllaikā trÅ«kums Yandex.Cloud API ir ierobežojums, kas sarežģī PV (Persistent Volume) lieluma maiņas darbÄ«bu: Å”ajā gadÄ«jumā ir jāaptur lietojumprogrammu komplekts, kas izmanto disku, un tas var izraisÄ«t dÄ«kstāves lietojumprogrammas.

Saskaņā ar CSI specifikācijas, ja CSI kontrolleris ziņo, ka var mainÄ«t disku izmērus tikai ā€œbezsaistēā€ (VolumeExpansion.OFFLINE), tad diska palielināŔanas procesam vajadzētu notikt Ŕādi:

Ja spraudnim ir tikai VolumeExpansion.OFFLINE paplaÅ”ināŔanas iespējas un apjoms paÅ”laik ir publicēts vai pieejams mezglā ControllerExpandVolume Jāizsauc TIKAI pēc:

  • Spraudnim ir kontrolieris PUBLISH_UNPUBLISH_VOLUME spējas un ControllerUnpublishVolume ir veiksmÄ«gi izsaukts.

VAI ARÄŖ

  • Spraudnim NAV kontrollera PUBLISH_UNPUBLISH_VOLUME iespēju, spraudnim ir mezgls STAGE_UNSTAGE_VOLUME spējas un NodeUnstageVolume ir veiksmÄ«gi pabeigts.

VAI ARÄŖ

  • Spraudnim NAV kontrollera PUBLISH_UNPUBLISH_VOLUME spēja, ne mezgls STAGE_UNSTAGE_VOLUME spējas un NodeUnpublishVolume ir veiksmÄ«gi pabeigts.

Tas bÅ«tÄ«bā nozÄ«mē, ka pirms tā paplaÅ”ināŔanas disks ir jāatvieno no virtuālās maŔīnas.

Tomēr diemžēl Ä«stenoÅ”anu CSI specifikācija, izmantojot blakusvāģus, neatbilst Ŕīm prasÄ«bām:

  • Blakusvāģa konteinerā csi-attacher, kam vajadzētu bÅ«t atbildÄ«gam par vajadzÄ«gās atstarpes esamÄ«bu starp stiprinājumiem, Ŕī funkcionalitāte vienkārÅ”i nav ieviesta bezsaistes izmēru maiņā. Par to tika uzsākta diskusija Å”eit.
  • Kas Ä«sti ir blakusvāģa konteiners Å”ajā kontekstā? Pats CSI spraudnis nesadarbojas ar Kubernetes API, bet atbild tikai uz gRPC izsaukumiem, ko tam nosÅ«ta blakusvāģa konteineri. Jaunākais tiek izstrādāti Kubernetes kopiena.

Mūsu gadījumā (CSI spraudnis) diska palielināŔanas darbība izskatās Ŕādi:

  1. Mēs saņemam gRPC zvanu ControllerExpandVolume;
  2. Mēs cenÅ”amies palielināt disku API, bet mēs saņemam kļūdu par neiespējamÄ«bu veikt operāciju, jo disks ir uzstādÄ«ts;
  3. Diska identifikatoru saglabājam kartē, kurā ir diski, kuriem jāveic palielināŔanas operācija. Tālāk Ä«suma labad mēs Å”o karti sauksim kā volumeResizeRequired;
  4. Manuāli noņemiet disku, kurā tiek izmantots disks. Kubernetes to restartēs. Lai diskam nebÅ«tu laika uzstādÄ«t (ControllerPublishVolume) pirms palielināŔanas darbÄ«bas pabeigÅ”anas, mēģinot montēt, mēs pārbaudām, vai dotais disks joprojām ir iekŔā volumeResizeRequired un atgriezt kļūdu;
  5. CSI draiveris mēģina atkārtoti izpildīt izmēru maiņas darbību. Ja darbība bija veiksmīga, izņemiet disku no volumeResizeRequired;
  6. Jo Trūkst diska ID no volumeResizeRequired, ControllerPublishVolume veiksmīgi iziet, disks ir uzstādīts, pods sākas.

Viss izskatās pietiekami vienkārÅ”i, taču, kā vienmēr, ir nepilnÄ«bas. Palielina diskus ārējais izmēra mainÄ«tājs, kas operācijas laikā raduŔās kļūdas gadÄ«jumā izmanto rindu ar eksponenciālu taimauta laika pieaugumu lÄ«dz 1000 sekundēm:

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

Tā rezultātā periodiski diska paplaÅ”ināŔanas darbÄ«ba var tikt pagarināta par 15 + minÅ«tēm, un lÄ«dz ar to atbilstoÅ”ais pods nav pieejams.

VienÄ«gā iespēja, kas diezgan viegli un nesāpÄ«gi ļāva samazināt iespējamo dÄ«kstāvi, bija mÅ«su ārējā izmēra mainÄ«tāja versijas izmantoÅ”ana ar maksimālo taimauta ierobežojumu. 5 sekundēs:

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

Mēs neuzskatÄ«jām par vajadzÄ«gu steidzami uzsākt diskusiju un lāpÄ«t ārējo izmēru mainÄ«tāju, jo disku izmēru maiņa bezsaistē ir atgrieÅ”anās, kas drÄ«z pazudÄ«s no visiem mākoņa pakalpojumu sniedzējiem.

Kā sākt lietot?

Draiveris tiek atbalstÄ«ts Kubernetes versijā 1.15 un jaunākā versijā. Lai vadÄ«tājs varētu strādāt, ir jāievēro Ŕādas prasÄ«bas:

  • AtzÄ«mēt --allow-privileged iestatÄ«t uz vērtÄ«bu true API serverim un kubelet;
  • Iekļauts --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API serverim un kubelet;
  • Mount pavairoÅ”ana (mount pavairoÅ”ana) ir jāiespējo klasterÄ«. Lietojot Docker, dēmonam jābÅ«t konfigurētam, lai atļautu koplietotus stiprinājumus.

Visas nepiecieÅ”amās darbÄ«bas paÅ”ai instalÄ“Å”anai aprakstÄ«ts README. InstalÄ“Å”ana ietver objektu izveidi Kubernetes no manifestiem.

Lai vadÄ«tājs varētu strādāt, jums bÅ«s nepiecieÅ”ams:

  • Norādiet direktorija identifikatoru manifestā (folder-id) Yandex.Cloud (skatiet dokumentāciju);
  • Lai mijiedarbotos ar Yandex.Cloud API, CSI draiveris izmanto pakalpojuma kontu. Manifestā jānodod Secret autorizētās atslēgas no pakalpojuma konta. Dokumentācijā aprakstÄ«ts, kā izveidot pakalpojuma kontu un iegÅ«t atslēgas.

Visā visumā - izmēģiniet to, un mēs priecāsimies saņemt atsauksmes un jauni jautājumija rodas kādas problēmas!

Turpmākais atbalsts

Rezultātā vēlamies atzÄ«mēt, ka Å”o CSI draiveri ieviesām nevis aiz lielas vēlmes izklaidēties rakstÄ«t lietojumprogrammas Go, bet gan tādēļ, ka uzņēmuma iekÅ”ienē bija steidzama nepiecieÅ”amÄ«ba. Mums neŔķiet praktiski saglabāt savu ievieÅ”anu, tāpēc, ja Yandex izrādÄ«s interesi un nolems turpināt atbalstÄ«t draiveri, mēs ar prieku nodosim krātuvi viņiem.

Turklāt Yandex, iespējams, savā pārvaldÄ«tajā Kubernetes klasterÄ« ir ieviesis CSI draiveri, ko var izlaist atvērtā pirmkoda režīmā. Mēs arÄ« uzskatām, ka Ŕī attÄ«stÄ«bas iespēja ir labvēlÄ«ga - sabiedrÄ«ba varēs izmantot pārbaudÄ«tu draiveri no pakalpojumu sniedzēja, nevis no treŔās puses uzņēmuma.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru