ProHoster > Блог > Administrado > Nia sperto pri evoluigado de CSI-ŝoforo en Kubernetes por Yandex.Cloud

Nia sperto pri evoluigado de CSI-ŝoforo en Kubernetes por Yandex.Cloud

Nia sperto pri evoluigado de CSI-ŝoforo en Kubernetes por Yandex.Cloud

Ni ĝojas anonci, ke Flant plivastigas sian kontribuon al Malfermfontaj iloj por Kubernetes publikigante alfa versio de la CSI-ŝoforo (Uja Stokado-Interfaco) por Yandex.Cloud.

Sed antaŭ ol pluiri al la efektivigdetaloj, ni respondu la demandon, kial ĉi tio estas bezonata kiam Yandex jam havas servon. Administrita Servo por Kubernetes.

Enkonduko

Kial ĉi tio estas?

Ene de nia kompanio, ekde la komenco de uzado de Kubernetes en produktado (t.e. jam de kelkaj jaroj), ni disvolvas nian propran ilon (ferdejo), kiun, cetere, ni ankaŭ planas disponigi baldaŭ kiel Malfermfontan projekton. . Kun ĝia helpo, ni unuforme agordas kaj agordas ĉiujn niajn aretojn, kaj nuntempe jam estas pli ol 100 el ili, sur diversaj aparataj agordoj kaj en ĉiuj disponeblaj nubaj servoj.

Aretoj, kiuj uzas ferdekon, havas ĉiujn komponantojn necesajn por funkciado: balanciloj, monitorado kun oportunaj leteroj, metrikoj kaj atentigoj, uzanto-aŭtentikigo per eksteraj provizantoj por aliro al ĉiuj paneloj, ktp. Ne utilas instali tian "pumpitan" areton en administrita solvo, ĉar tio ofte estas aŭ neebla aŭ kondukos al la bezono malŝalti duonon de la komponantoj.

NB: Ĉi tio estas nia sperto, kaj ĝi estas sufiĉe specifa. Ni neniel sugestas, ke ĉiuj mem disfaldi Kubernetes-grupojn anstataŭ uzi pretajn solvojn. Cetere, ni ne havas realan sperton pri funkciigado de Kubernetes de Yandex kaj ni ne donos ajnan takson pri ĉi tiu servo en ĉi tiu artikolo.

Kio estas kaj por kiu?

Do, ni jam parolis pri la moderna aliro al stokado en Kubernetes: kiel funkcias CSI? и kiel venis la komunumo al ĉi tiu aliro.

Nuntempe, multaj grandaj nubaj servoprovizantoj evoluigis ŝoforojn por uzi siajn nubajn diskojn kiel Persistent Volume en Kubernetes. Se la provizanto ne havas tian ŝoforon, sed ĉiuj necesaj funkcioj estas provizitaj per la API, tiam nenio malhelpas vin mem efektivigi la ŝoforon. Jen kio okazis kun Yandex.Cloud.

Ni prenis kiel bazon por disvolviĝo CSI-ŝoforo por DigitalOcean-nubo kaj kelkaj ideoj de ŝoforoj por GCP, ĉar interago kun la API de ĉi tiuj nuboj (Google kaj Yandex) havas kelkajn similecojn. Aparte, la API kaj GCP, kaj ĉe Yandex redoni objekton Operation por spuri la staton de longdaŭraj operacioj (ekzemple, kreante novan diskon). Por interagi kun la Yandex.Cloud API, uzu Yandex.Cloud Go SDK.

La rezulto de la laboro farita publikigita sur GitHub kaj povas esti utila por tiuj, kiuj ial uzas sian propran instalaĵon de Kubernetes sur virtualaj maŝinoj Yandex.Cloud (sed ne preta administrita areto) kaj ŝatus uzi (mendi) diskojn per CSI.

Реализация

Ŝlosilaj trajtoj

Nuntempe la ŝoforo subtenas la sekvajn funkciojn:

  • Mendado de diskoj en ĉiuj zonoj de la areto laŭ la topologio de la nodoj en la areto;
  • Forigo de antaŭe menditaj diskoj;
  • Senrete regrandigi por diskoj (Yandex.Cloud ne subtenas pliigante la diskojn kiuj estas muntitaj al la virtuala maŝino). Por informoj pri kiel la ŝoforo devis esti modifita por ke regrandigi kiel eble plej sendolore, vidu sube.

En la estonteco, ni planas efektivigi subtenon por krei kaj forigi diskojn.

La ĉefa malfacilaĵo kaj kiel venki ĝin

La manko de la kapablo pliigi diskojn en reala tempo en la Yandex.Cloud API estas limigo, kiu malfaciligas la regrandigi operacion por PV (Persistent Volume): en ĉi tiu kazo, necesas, ke la aplikaĵo, kiu uzas la diskon, estu haltigita, kaj ĉi tio povas kaŭzi malfunkciajn aplikojn.

Laŭ CSI-specifoj, se la CSI-regilo raportas, ke ĝi povas regrandigi diskojn nur "senrete" (VolumeExpansion.OFFLINE), tiam la procezo de pliigo de la disko devus iri jene:

Se la kromaĵo havas nur VolumeExpansion.OFFLINE ekspansiokapablo kaj volumeno estas nuntempe publikigitaj aŭ haveblaj sur nodo tiam ControllerExpandVolume DEVAS esti nomita NUR post aŭ:

  • La kromaĵo havas regilon PUBLISH_UNPUBLISH_VOLUME kapablo kaj ControllerUnpublishVolume estis alvokita sukcese.

ALIE

  • La kromaĵo NE havas regilon PUBLISH_UNPUBLISH_VOLUME kapablo, la kromaĵo havas nodon STAGE_UNSTAGE_VOLUME kapablo, kaj NodeUnstageVolume kompletiĝis sukcese.

ALIE

  • La kromaĵo NE havas regilon PUBLISH_UNPUBLISH_VOLUME kapablo, nek nodo STAGE_UNSTAGE_VOLUME kapablo, kaj NodeUnpublishVolume sukcese finiĝis.

Ĉi tio esence signifas, ke vi devas dekroĉi la diskon de la virtuala maŝino antaŭ ol vastigi ĝin.

Tamen, bedaŭrinde efektivigo La CSI-specifo per kromĉaroj ne renkontas tiujn postulojn:

  • En kromĉarujo csi-attacher, kiu devus respondeci pri la ĉeesto de la bezonata interspaco inter montoj, ĉi tiu funkcio simple ne estas efektivigita en la senreta regrandigo. Diskuto pri tio estis komencita tie.
  • Kio ĝuste estas kromĉarujo en ĉi tiu kunteksto? La CSI-kromaĵo mem ne interagas kun la Kubernetes API, sed nur respondas al gRPC-vokoj senditaj al ĝi per flankaj ujoj. Plej lasta estas evoluigitaj de la Kubernetes-komunumo.

En nia kazo (CSI-kromaĵo), la operacio pliigi la diskon aspektas jene:

  1. Ni ricevas gRPC-vokon ControllerExpandVolume;
  2. Ni provas pliigi la diskon en la API, sed ni ricevas eraron pri la neeblo plenumi la operacion ĉar la disko estas muntita;
  3. Ni stokas la diskidentigilon en mapo, kiu enhavas la diskojn por kiuj la pliiga operacio devas esti farita. Malsupre, por koncizeco, ni nomos ĉi tiun mapon kiel volumeResizeRequired;
  4. Mane forigu la pod kiu uzas la diskon. Kubernetes rekomencos ĝin. Por ke la disko ne havu tempon por munti (ControllerPublishVolume) antaŭ ol kompletigi la pligrandigan operacion kiam vi provas munti, ni kontrolas, ke la donita disko ankoraŭ estas enigita volumeResizeRequired kaj redonu eraron;
  5. La CSI-ŝoforo provas reefektigi la regrandigi operacion. Se la operacio sukcesis, tiam forigu la diskon de volumeResizeRequired;
  6. Ĉar Diska ID mankas volumeResizeRequired, ControllerPublishVolume sukcese pasas, la disko estas muntita, la pod komenciĝas.

Ĉio aspektas sufiĉe simpla, sed kiel ĉiam estas kaptiloj. Pligrandigas diskojn ekstera-regrandigilo, kiu en kazo de eraro dum la operacio uzas voston kun eksponenta pliiĝo en la tempodaŭro ĝis 1000 sekundoj:

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

Ĉi tio povas periode rezultigi la diskon-vastiĝoperacion esti etendita dum 15+ minutoj kaj, tiel, la ekvivalenta pod estanta neatingebla.

La sola opcio, kiu sufiĉe facile kaj senpolore permesis al ni redukti eblan malfunkcion, estis la uzo de nia versio de ekstera-regrandigilo kun maksimuma limo de tempodaŭro. en 5 sekundoj:

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

Ni ne konsideris necese urĝe komenci diskuton kaj fliki la eksteran regrandigilon, ĉar eksterrete regrandigi diskojn estas retrovo, kiu baldaŭ malaperos de ĉiuj nubaj provizantoj.

Kiel ekuzi?

La ŝoforo estas subtenata en Kubernetes versio 1.15 kaj pli alta. Por ke la ŝoforo funkciu, la sekvaj postuloj devas esti plenumitaj:

  • Flago --allow-privileged agordi al valoro true por API-servilo kaj kubelet;
  • Inkluzivita --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true por API-servilo kaj kubelet;
  • Monto-disvastigo (monto disvastigo) devas esti ebligita sur la areto. Kiam vi uzas Docker, la demono devas esti agordita por permesi komunajn muntadojn.

Ĉiuj necesaj paŝoj por la instalado mem priskribita en README. Instalado implikas krei objektojn en Kubernetes el manifestoj.

Por ke la ŝoforo funkciu, vi bezonos la jenon:

  • Indiku la dosierujan identigilon en la manifesto (folder-id) Yandex.Cloud (vidu dokumentadon);
  • Por interagi kun la Yandex.Cloud API, la CSI-ŝoforo uzas servokonton. En la manifesto, Sekreto devas esti pasigita rajtigitaj ŝlosiloj de la servokonto. En la dokumentado priskribis, kiel krei servokonton kaj akiri ŝlosilojn.

Entute - provu, kaj ni ĝojos ricevi komentojn kaj novaj aferojse vi renkontas problemojn!

Plia subteno

Kiel rezulto, ni ŝatus noti, ke ni efektivigis ĉi tiun CSI-ŝoforon ne pro granda deziro amuziĝi skribante aplikaĵojn en Go, sed pro urĝa bezono ene de la kompanio. Ne ŝajnas al ni praktike konservi nian propran efektivigon, do se Yandex montras intereson kaj decidas daŭrigi subteni la ŝoforon, ni volonte translokigos la deponejon al ili.

Krome, Yandex verŝajne havas sian propran efektivigon de la CSI-ŝoforo en sia administrita Kubernetes-areo, kiu povas esti liberigita en Malferma Fonto. Ni ankaŭ vidas ĉi tiun disvolvan opcion kiel favora - la komunumo povos uzi provitan ŝoforon de provizanto de servoj, kaj ne de tria kompanio.

PS

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Aldoni komenton