ProHoster > Blog > Rêveberî > Tecrûbeya me di pêşxistina ajokerek CSI de li Kubernetes ji bo Yandex.Cloud

Tecrûbeya me di pêşxistina ajokerek CSI de li Kubernetes ji bo Yandex.Cloud

Tecrûbeya me di pêşxistina ajokerek CSI de li Kubernetes ji bo Yandex.Cloud

Em kêfxweş in ku radigihînin ku Flant bi berdana tevkariya xwe ji amûrên Çavkaniya Vekirî ya Kubernetes re berfireh dike. guhertoya alpha ya ajokera CSI (Interface Storage Container) ji bo Yandex.Cloud.

Lê berî ku em biçin ser hûrguliyên pêkanînê, werin em bersiva vê pirsê bidin ka çima ev yek hewce ye dema ku Yandex jixwe karûbarek heye Karûbarê Birêvebir ji bo Kubernetes.

Pîrozbahiyê

Çima ev e?

Di hundurê pargîdaniya me de, ji destpêka karanîna Kubernetes di hilberînê de (ango ev çend sal in), em amûra xwe (deckhouse) pêşdixin, ku, bi awayê, em jî plan dikin ku di demek nêzîk de wekî projeyek Çavkaniya Vekirî peyda bikin. . Bi alîkariya wê, em hemî komikên xwe bi yekdengî mîheng û mîheng dikin, û niha ji wan zêdetirî 100 hene, li ser cûrbecûr veavakirinên hardware û di hemî karûbarên cloudê yên berdest de.

Komên ku deckhouse bikar tînin hemî hêmanên ku ji bo xebitandinê hewce ne hene: balansker, çavdêrîkirina bi nexşeyên hêsan, metrîk û hişyariyan, erêkirina bikarhêner bi navgîniya pêşkêşkerên derveyî ji bo gihîştina hemî dashboardan, û hwd. Di çareseriyek rêveberî de sazkirina komek wusa "pompkirî" tune ye, ji ber ku ev bi gelemperî ne gengaz e an jî dê bibe sedema hewcedariya neçalakkirina nîvê pêkhateyan.

NB: Ev tecrubeya me ye, û bi taybetî jî. Em bi tu awayî pêşniyar nakin ku her kes li şûna ku çareseriyên amade bikar bîne, komikên Kubernetes bi serê xwe bicîh bike. Bi awayê, di xebitandina Kubernetes ji Yandex-ê de ezmûnek me ya rastîn tune û em ê di vê gotarê de nirxandinek vê karûbarê nedin.

Çi ye û ji bo kê ye?

Ji ber vê yekê, me berê li ser nêzîkatiya nûjen a hilanînê li Kubernetes peyivî: CSI çawa dixebite? и civat çawa hat ji vê nêzîkatiyê re.

Heya nuha, gelek pêşkêşkerên karûbarê ewr ên mezin ji bo karanîna dîskên xwe yên ewr wekî Voluma Persistent di Kubernetes de ajokar pêşve xistine. Ger dabînker ne xwediyê ajokarek wusa be, lê hemî fonksiyonên pêwîst bi API-yê ve têne peyda kirin, wê hingê tiştek nahêle ku hûn bi xwe ajokerê bicîh bikin. Ya ku bi Yandex.Cloud re qewimî ev e.

Me ji bo pêşketinê bingeh girt Ajokarê CSI ji bo ewr DigitalOcean û çend ramanên ji ajokarên ji bo GCP, ji ber ku pêwendiya bi API-ya van ewran (Google û Yandex) re çend celeb hene. Bi taybetî, API û GCP, û y Yandex tiştekî vegerîne Operation ji bo şopandina rewşa operasyonên demdirêj (mînak, çêkirina dîskek nû). Ji bo ku bi Yandex.Cloud API re têkilî daynin, bikar bînin Yandex.Cloud Go SDK.

Encama xebata ku hatiye kirin li ser GitHub hate weşandin û dibe ku ji bo kesên ku, ji ber hin sedeman, sazkirina Kubernetes-a xwe ya li ser makîneyên virtual Yandex.Cloud bikar tînin (lê ne komikek birêvebir a amadekirî) bikar bînin û dixwazin dîskên bi navgîniya CSI-ê bikar bînin (sipariz bikin).

Реализация

Taybetmendiyên sereke

Niha ajoker fonksiyonên jêrîn piştgirî dike:

  • Rêzkirina dîskên li hemî deverên komê li gorî topolojiya girêkên di komê de;
  • Rakirina dîskên berê yên fermankirî;
  • Mezinahiya negirêdayî ji bo dîskan (Yandex.Cloud piştgirî nakin zêdekirina dîskên ku li ser makîna virtual têne danîn). Ji bo agahdariya li ser ka ajokar çawa diviyabû were guheztin da ku ji nû ve mezinbûnê bi qasî ku gengaz bê êş bike, li jêr binêre.

Di pêşerojê de, em plan dikin ku piştgirî ji bo çêkirin û jêbirina dîmenên dîskê bicîh bikin.

Zehmetiya sereke û meriv wê çawa derbas bike

Kêmbûna şiyana zêdekirina dîskan di wextê rast de di Yandex.Cloud API-yê de sînorkirinek e ku operasyona veguheztina mezinbûnê ya PV-yê (Dengê Berdewam) tevlihev dike: Di vê rewşê de, pêdivî ye ku podê serîlêdanê ku dîskê bikar tîne were sekinandin, û ev dikare bibe sedema sepanên demdirêj.

Li gorî Taybetmendiyên CSI, heke kontrolkerê CSI rapor dike ku ew dikare tenê "negirêdayî" mezinahiya dîskan biguherîne (VolumeExpansion.OFFLINE), wê hingê divê pêvajoya zêdekirina dîskê wiha biçe:

Ger pêvek tenê hebe VolumeExpansion.OFFLINE kapasîteya berfirehbûnê û hêjmar niha li ser nodekê tê weşandin an peyda dibe ControllerExpandVolume DIVÊ TENÊ piştî van jî were gotin:

  • Plugin xwedan kontrolker e PUBLISH_UNPUBLISH_VOLUME şiyan û ControllerUnpublishVolume bi serketî hatiye bang kirin.

AN DIN

  • Pêvek kontrolker TUNE ye PUBLISH_UNPUBLISH_VOLUME kapasîteyê, pêvekê girêk heye STAGE_UNSTAGE_VOLUME kapasîteya, û NodeUnstageVolume bi serkeftî pêk hatiye.

AN DIN

  • Pêvek kontrolker TUNE ye PUBLISH_UNPUBLISH_VOLUME kapasîteya, ne jî girêk STAGE_UNSTAGE_VOLUME kapasîteya, û NodeUnpublishVolume bi serkeftî qedandiye.

Ev bi rastî tê vê wateyê ku hûn hewce ne ku berî ku ew berfireh bikin dîskê ji makîneya virtual veqetînin.

Lêbelê, mixabin pêkanîn Taybetmendiya CSI-ê bi riya sidecaran van hewcedariyên xwe nagire:

  • Di konteynirek kêlekê de csi-attacher, ku divê ji hebûna valahiya hewce ya di navbera çiyayan de berpirsiyar be, ev fonksiyon bi tenê di mezinahiya offline de nayê bicîh kirin. Li ser vê yekê nîqaş hat destpêkirin vir.
  • Di vê çarçoveyê de bi rastî konteynera kêlekê çi ye? Pêveka CSI bixwe bi Kubernetes API re têkilî nake, lê tenê bersivê dide bangên gRPC ku ji hêla konteynerên kêlekê ve jê re têne şandin. Dawîtirîn têne pêşxistin ji hêla civaka Kubernetes ve.

Di doza me de (pêveka CSI), operasyona zêdekirina dîskê bi vî rengî xuya dike:

  1. Em bangek gRPC distînin ControllerExpandVolume;
  2. Em hewl didin ku dîskê di API-yê de zêde bikin, lê em xeletiyek di derbarê nemumkiniya pêkanîna operasyonê de distînin ji ber ku dîsk lê hatî danîn;
  3. Em nasnama dîskê di nexşeyê de hilînin, ku tê de dîskên ku divê operasyona zêdekirinê ji bo wan were kirin vedihewîne. Li jêr, ji bo kurtahî, em ê vê nexşeyê wekî nav bikin volumeResizeRequired;
  4. Podê ku dîskê bikar tîne bi destan rakin. Kubernetes dê ji nû ve dest pê bike. Ji ber vê yekê ku dîskê dem tune ku siwar bibe (ControllerPublishVolume) berî ku operasyona zêdekirinê biqedînin dema ku hewl didin ku lê bixin, em kontrol dikin ku dîska hatî dayîn hîn jî tê de ye volumeResizeRequired û xeletiyek vegerînin;
  5. Ajokera CSI hewl dide ku operasyona mezinbûnê ji nû ve bimeşîne. Ger operasyon serketî bû, wê hingê dîskê jê derxin volumeResizeRequired;
  6. Bo Nasnameya dîskê ji wenda ye volumeResizeRequired, ControllerPublishVolume bi serfirazî derbas dibe, dîsk tê siwar kirin, pod dest pê dike.

Her tişt têra xwe hêsan xuya dike, lê wekî her gav xeletî hene. Dîskan mezin dike derve-resizer, ku di dema operasyonê de çewtiyek çewt e dorê bi kar tîne bi zêdebûnek berbiçav di dema wextê de heya 1000 çirkeyan:

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

Ev dikare bi awayekî periyodîk bibe sedema ku operasyona berfirehkirina dîskê ji bo 15+ hûrdeman were dirêj kirin û, bi vî rengî, podê têkildar tune be.

Yekane vebijarka ku bi hêsanî û bê êş rê da me ku em demdirêjiya potansiyel kêm bikin, karanîna guhertoya meya guhastkera derveyî ya bi sînorek demdirêj a herî zêde bû. di 5 seconds:

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

Me hewce nedidît ku bi lezgînî dest bi nîqaşê bikin û guhezkarê ji derve veguhezînin, ji ber ku mezinahiya dîskên negirêdayî paşvegerek e ku dê di demek nêzîk de ji hemî pêşkêşkerên ewr winda bibe.

Meriv çawa dest bi kar dike?

Ajokar li ser guhertoya Kubernetes 1.15 û mezintir tê piştgirî kirin. Ji bo ku ajokar kar bike, pêdivî ye ku hewcedariyên jêrîn bêne bicîh kirin:

  • Flag --allow-privileged bi nirx danîn true ji bo servera API û kubelet;
  • Tevlî --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true ji bo servera API û kubelet;
  • Berbelavbûna çiyê (belavbûna çiyê) divê li ser komê were çalak kirin. Dema ku Docker bikar tînin, pêdivî ye ku daemon were mîheng kirin da ku destûr bide çiyayên hevbeş.

Hemî gavên pêwîst ji bo sazkirinê bixwe di README de tê vegotin. Sazkirin di nav manîfestoyan de çêkirina tiştan li Kubernetes pêk tîne.

Ji bo ku ajokar bixebite hûn ê hewceyê jêrîn bikin:

  • Nasnameya pelrêça di manîfestoyê de diyar bike (folder-id) Yandex.Cloud (belgeyê bibînin);
  • Ji bo ku bi Yandex.Cloud API re têkilî daynin, ajokera CSI hesabek karûbarê bikar tîne. Di eşkerebûna veşartî de, divê hûn derbas bibin keys destûr ji hesabê xizmetê. Di belgeyê de şirove kirin, Meriv çawa hesabek karûbarê biafirîne û kilîtan bigire.

Niha na - biceribîne, û em ê kêfxweş bibin ku bersivê bistînin û pirsgirêkên nûheke hûn bi ti pirsgirêkan re rû bi rû bimînin!

Piştgiriya bêtir

Wekî encamek, em dixwazin bala xwe bidinê ku me ev ajokera CSI ne ji ber xwestekek mezin a kêfa serîlêdanên nivîsandina Go-yê, lê ji ber hewcedariyek lezgîn di nav pargîdaniyê de bicîh kir. Ji me re ne pratîkî xuya dike ku pêkanîna xwe bidomînin, ji ber vê yekê heke Yandex eleqe nîşan bide û biryar bide ku piştgiriya ajokerê bidomîne, em ê kêfxweş bibin ku depoyê ji wan re veguhezînin.

Wekî din, Yandex belkî di koma xweya Kubernetes a rêvebirinê de pêkanîna xwe ya ajokera CSI-yê heye, ku dikare di Çavkaniya Vekirî de were berdan. Di heman demê de em vê vebijarka pêşkeftinê jî xweş dibînin - civak dê karibe ajokerek pejirandî ji pêşkêşkarek karûbar bikar bîne, û ne ji pargîdaniyek sêyemîn.

PS

Li ser bloga me jî bixwînin:

Source: www.habr.com

Add a comment