🥇 Reynsla okkar í að þróa CSI rekla í Kubernetes fyrir Yandex.Cloud

Það gleður okkur að tilkynna að Flant er að auka framlag sitt til Open Source verkfæra fyrir Kubernetes með því að gefa út alfa útgáfa af CSI bílstjóri (Container Storage Interface) fyrir Yandex.Cloud.

En áður en við förum að útfærsluupplýsingunum skulum við svara spurningunni hvers vegna þetta er nauðsynlegt þegar Yandex er nú þegar með þjónustu Stýrð þjónusta fyrir Kubernetes.

Inngangur

Hvers vegna er þetta?

Innan fyrirtækis okkar, frá upphafi notkunar Kubernetes í framleiðslu (þ.e. í nokkur ár núna), höfum við verið að þróa okkar eigið tól (þilfarshús), sem við ætlum líka að gera fljótlega aðgengilegt sem opið uppspretta verkefni. . Með hjálp þess stillum við og stillum alla klasana okkar jafnt og þétt, og eins og er eru þeir nú þegar fleiri en 100 af þeim, á fjölbreyttum vélbúnaðarstillingum og í allri tiltækri skýjaþjónustu.

Klasar sem nota þilfarshús hafa alla íhluti sem nauðsynlegir eru til notkunar: jafnvægistæki, vöktun með þægilegum töflum, mæligildum og viðvörunum, auðkenning notenda í gegnum utanaðkomandi veitendur til að fá aðgang að öllum mælaborðum og svo framvegis. Það þýðir ekkert að setja upp svona „uppdæltan“ þyrping í stýrðri lausn, þar sem þetta er oft annað hvort ómögulegt eða mun leiða til þess að þú þurfir að slökkva á helmingi íhlutanna.

NB: Þetta er reynsla okkar og hún er alveg sértæk. Við erum á engan hátt að leggja til að allir ættu að setja upp Kubernetes klasa á eigin spýtur í stað þess að nota tilbúnar lausnir. Við the vegur, við höfum enga raunverulega reynslu af rekstri Kubernetes frá Yandex og við munum ekki gefa neitt mat á þessari þjónustu í þessari grein.

Hvað er það og fyrir hvern?

Svo við höfum þegar talað um nútíma nálgun við geymslu í Kubernetes: hvernig virkar CSI? и hvernig samfélagið kom við þessa nálgun.

Eins og er, hafa margir stórir skýjaþjónustuaðilar þróað rekla til að nota skýjadiskana sína sem viðvarandi bindi í Kubernetes. Ef birgirinn er ekki með slíkan rekil, en allar nauðsynlegar aðgerðir eru veittar í gegnum API, þá kemur ekkert í veg fyrir að þú útfærir bílstjórann sjálfur. Þetta er það sem gerðist með Yandex.Cloud.

Við tókum sem grundvöll fyrir þróun CSI bílstjóri fyrir DigitalOcean ský og nokkrar hugmyndir frá Bílstjóri fyrir GCP, þar sem samskipti við API þessara skýja (Google og Yandex) hafa ýmislegt líkt. Einkum API og GCP, og kl Yandex skila hlut Operation til að fylgjast með stöðu langvinnra aðgerða (til dæmis að búa til nýjan disk). Til að hafa samskipti við Yandex.Cloud API, notaðu Yandex.Cloud Go SDK.

Afrakstur vinnunnar опубликован á GitHub og getur verið gagnlegt fyrir þá sem af einhverjum ástæðum nota sína eigin Kubernetes uppsetningu á Yandex.Cloud sýndarvélum (en ekki tilbúinn stýrðan klasa) og vilja nota (panta) diska í gegnum CSI.

Framkvæmd

Helstu eiginleikar

Sem stendur styður bílstjórinn eftirfarandi aðgerðir:

Röðun diska á öllum svæðum þyrpingarinnar í samræmi við staðfræði hnúta í þyrpingunni;
Að fjarlægja áður pantaða diska;
Breyta stærð fyrir diska án nettengingar (Yandex.Cloud styðja ekki auka diskana sem eru festir á sýndarvélina). Fyrir upplýsingar um hvernig breyta þurfti bílstjóranum til að gera stærðarbreytingu eins sársaukalausa og mögulegt er, sjá hér að neðan.

Í framtíðinni ætlum við að innleiða stuðning við að búa til og eyða diska skyndimyndum.

Helstu erfiðleikar og hvernig á að sigrast á honum

Skortur á getu til að auka diska í rauntíma í Yandex.Cloud API er takmörkun sem flækir stærðaraðgerðina fyrir PV (Persistent Volume): í þessu tilfelli er nauðsynlegt að stöðva forritabelginn sem notar diskinn, og þetta getur valdið niðurtímaumsóknum.

Samkvæmt CSI forskriftir, ef CSI stjórnandi tilkynnir að hann geti aðeins breytt stærð diska „ótengdur“ (VolumeExpansion.OFFLINE), þá ætti ferlið við að auka diskinn að fara svona:

Ef viðbótin hefur aðeins VolumeExpansion.OFFLINE stækkunarmöguleiki og magn er nú gefið út eða fáanlegt á hnút þá ControllerExpandVolume VERÐUR að hringja AÐEINS eftir annað hvort:

Viðbótin er með stjórnandi PUBLISH_UNPUBLISH_VOLUME getu og ControllerUnpublishVolume hefur verið kallað fram með góðum árangri.

EÐA ANNARS

Viðbótin er EKKI með stjórnanda PUBLISH_UNPUBLISH_VOLUME getu, viðbótin hefur hnút STAGE_UNSTAGE_VOLUME getu, og NodeUnstageVolume hefur verið lokið með góðum árangri.

EÐA ANNARS

Viðbótin er EKKI með stjórnanda PUBLISH_UNPUBLISH_VOLUME getu, né hnút STAGE_UNSTAGE_VOLUME getu, og NodeUnpublishVolume hefur lokið með góðum árangri.

Þetta þýðir í raun og veru að þú þarft að aftengja diskinn frá sýndarvélinni áður en þú stækkar hann.

Hins vegar því miður framkvæmd CSI forskriftin um hliðarvagna uppfyllir ekki þessar kröfur:

Í hliðarvagnsgámi csi-attacher, sem ætti að vera ábyrgur fyrir tilvist nauðsynlegs bils milli festinga, þessi virkni er einfaldlega ekki útfærð í ótengdu stærðarbreytingunni. Umræða var hafin um þetta hér.
Hvað er hliðarvagnagámur eiginlega í þessu samhengi? CSI viðbótin sjálf hefur ekki samskipti við Kubernetes API heldur bregst aðeins við gRPC símtölum sem send eru til þess með hliðarvagni. Nýjasta verið að þróa af Kubernetes samfélaginu.

Í okkar tilviki (CSI tappi) lítur aðgerðin við að auka diskinn svona út:

Við fáum gRPC símtal ControllerExpandVolume;
Við erum að reyna að auka diskinn í API, en við fáum villu um að ómögulegt sé að framkvæma aðgerðina vegna þess að diskurinn er festur;
Við geymum diskaauðkennið í korti, sem inniheldur diskana sem þarf að framkvæma aukninguna fyrir. Hér að neðan, til styttingar, munum við kalla þetta kort sem volumeResizeRequired;
Fjarlægðu belg sem notar diskinn handvirkt. Kubernetes mun endurræsa það. Svo að diskurinn hafi ekki tíma til að tengja (ControllerPublishVolume) áður en við lýkur hækkunaraðgerðinni þegar reynt er að tengja, athugum við að tiltekinn diskur sé enn í volumeResizeRequired og skila villu;
CSI bílstjórinn reynir að endurræsa stærðarbreytinguna. Ef aðgerðin tókst, fjarlægðu þá diskinn úr volumeResizeRequired;
Vegna þess að Auðkenni disks vantar í volumeResizeRequired, ControllerPublishVolume líður vel, diskurinn er settur upp, podinn fer í gang.

Allt lítur nógu einfalt út, en eins og alltaf eru gildrur. Stækkar diska ytri-resizer, sem ef um villu stendur í aðgerðinni notar biðröð með veldisvísis aukningu á tímamörkum í allt að 1000 sekúndur:

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

Þetta getur með reglulegu millibili leitt til þess að stækkun disksins er framlengd um 15+ mínútur og þar af leiðandi er samsvarandi hólf ekki tiltækt.

Eini kosturinn sem auðveldlega og sársaukalaust leyfði okkur að draga úr hugsanlegum niður í miðbæ var notkun okkar útgáfu af ytri resizer með hámarkstímamörkum á 5 sekúndum:

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

Við töldum ekki nauðsynlegt að hefja umræðu í skyndi og plástra ytri resizer, því að breyta stærð diska án nettengingar er afturhvarf sem mun brátt hverfa frá öllum skýjaveitum.

Hvernig á að byrja að nota?

Ökumaðurinn er studdur á Kubernetes útgáfu 1.15 og nýrri. Til að ökumaður geti unnið þarf að uppfylla eftirfarandi kröfur:

Flagga --allow-privileged stillt á gildi true fyrir API netþjón og kubelet;
Innifalið --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true fyrir API netþjón og kubelet;
Fjallfjölgun (fjölgun fjalla) verður að vera virkt á þyrpingunni. Þegar Docker er notað verður púkinn að vera stilltur til að leyfa sameiginlegar festingar.

Öll nauðsynleg skref fyrir uppsetninguna sjálfa lýst í README. Uppsetning felur í sér að búa til hluti í Kubernetes úr upplýsingaskrám.

Til að ökumaðurinn virki þarftu eftirfarandi:

Tilgreindu möppuauðkenni í upplýsingaskrá (folder-id) Yandex.Cloud (sjá skjöl);
Til að hafa samskipti við Yandex.Cloud API notar CSI bílstjórinn þjónustureikning. Í upplýsingaskránni þarf að fara framhjá Secret viðurkenndum lyklum af þjónustureikningnum. Í skjölunum lýst, hvernig á að búa til þjónustureikning og fá lykla.

Allt í allt - reyna, og við munum vera ánægð að fá viðbrögð og ný málef þú lendir í einhverjum vandræðum!

Frekari stuðningur

Þess vegna viljum við taka fram að við innleiddum þennan CSI driver ekki af mikilli löngun til að hafa gaman af því að skrifa umsóknir í Go, heldur vegna brýnnar þörf innan fyrirtækisins. Okkur virðist ekki hagkvæmt að viðhalda eigin útfærslu, þannig að ef Yandex sýnir áhuga og ákveður að halda áfram að styðja við ökumanninn, munum við vera fús til að flytja geymsluna til þeirra.

Að auki hefur Yandex líklega sína eigin útfærslu á CSI reklanum í stýrðum Kubernetes þyrpingunni, sem hægt er að gefa út í Open Source. Við lítum líka á þennan þróunarmöguleika sem hagstæðan - samfélagið mun geta notað sannaðan ökumann frá þjónustuaðila, en ekki frá þriðja aðila.

PS

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Reynsla okkar í að þróa CSI bílstjóri í Kubernetes fyrir Yandex.Cloud