Us ûnderfining yn it ûntwikkeljen fan in CSI-bestjoerder yn Kubernetes foar Yandex.Cloud

Wy binne bliid om oan te kundigjen dat Flant har bydrage útwreidet oan Open Source-ark foar Kubernetes troch frij te litten alpha ferzje fan de CSI stjoerprogramma (Container Storage Interface) foar Yandex.Cloud.

Mar foardat jo oergean nei de ymplemintaasjedetails, litte wy de fraach beantwurdzje wêrom dit überhaupt nedich is as Yandex al in tsjinst hat Beheare tsjinst foar Kubernetes.

Ynlieding

Wêrom is dit?

Binnen ús bedriuw hawwe wy fan it begjin ôf fan it brûken fan Kubernetes yn produksje (dus al ferskate jierren no), ús eigen ark (dekhûs) ûntwikkele, dat wy trouwens ek fan plan binne om gau beskikber te stellen as in Open Source-projekt . Mei har help konfigurearje en konfigurearje wy al ús klusters unifoarm, en op it stuit binne d'r mear as 100 fan har, op in breed ferskaat oan hardwarekonfiguraasjes en yn alle beskikbere wolktsjinsten.

Klusters dy't deckhouse brûke hawwe alle komponinten dy't nedich binne foar operaasje: balancers, tafersjoch mei handige diagrammen, metriken en warskôgings, brûkersautentikaasje fia eksterne providers foar tagong ta alle dashboards, ensfh. D'r hat gjin punt om sa'n "oppompte" kluster te ynstallearjen yn in beheare oplossing, om't dit faaks ûnmooglik is of sil liede ta de needsaak om de helte fan 'e komponinten út te skeakeljen.

NB: Dit is ús ûnderfining, en it is frij spesifyk. Wy suggerearje op gjin inkelde manier dat elkenien Kubernetes-klusters op har eigen moat ynsette ynstee fan klearmakke oplossingen. Trouwens, wy hawwe gjin echte ûnderfining yn it operearjen fan Kubernetes fan Yandex en wy sille gjin beoardieling fan dizze tsjinst jaan yn dit artikel.

Wat is it en foar wa?

Dat, wy hawwe al praat oer de moderne oanpak fan opslach yn Kubernetes: hoe wurket CSI? и hoe't de mienskip kaam oan dizze oanpak.

Op it stuit hawwe in protte grutte wolktsjinstferlieners drivers ûntwikkele foar it brûken fan har wolkeskiven as Persistent Volume yn Kubernetes. As de leveransier net sa'n bestjoerder hat, mar alle nedige funksjes wurde levere fia de API, dan hinderet neat jo om de bestjoerder sels te ymplementearjen. Dit is wat barde mei Yandex.Cloud.

Wy namen as basis foar ûntwikkeling CSI stjoerprogramma foar DigitalOcean wolk en in pear ideeën út bestjoerders foar GCP, sûnt ynteraksje mei de API fan dizze wolken (Google en Yandex) hat in oantal oerienkomsten. Benammen de API en GCP,en by Yandex werom in foarwerp Operation om de status fan langrinnende operaasjes te folgjen (bygelyks it meitsjen fan in nije skiif). Om ynteraksje mei de Yandex.Cloud API, brûk Yandex.Cloud Go SDK.

It resultaat fan it dien wurk publisearre op GitHub en kin nuttich wêze foar dyjingen dy't, om ien of oare reden, har eigen Kubernetes-ynstallaasje brûke op Yandex.Cloud firtuele masines (mar net in ready-made managed cluster) en wolle graach brûke (bestelle) skiven fia CSI.

Ymplemintaasje

Main Features

Op it stuit stipet de bestjoerder de folgjende funksjes:

• It bestellen fan skiven yn alle sônes fan it kluster neffens de topology fan 'e knopen yn it kluster;
• It fuortsmiten fan earder bestelde skiven;
• Offline grutte feroarje foar skiven (Yandex.Cloud net stypje it fergrutsjen fan de skiven dy't binne monteard op 'e firtuele masine). Foar ynformaasje oer hoe't de sjauffeur moast wurde wizige om it feroarjen fan grutte sa pynlik mooglik te meitsjen, sjoch hjirûnder.

Yn 'e takomst binne wy ​​fan plan om stipe te ymplementearjen foar it meitsjen en wiskjen fan skyf-snapshots.

De wichtichste muoite en hoe te oerwinnen it

It ûntbrekken fan 'e mooglikheid om skiven yn realtime te fergrutsjen yn' e Yandex.Cloud API is in beheining dy't de operaasje foar PV (Persistent Volume) komplisearret: yn dit gefal is it needsaaklik dat de applikaasje pod dy't de skiif brûkt wurdt stoppe, en dit kin feroarsaakje downtime applikaasjes.

Neffens CSI spesifikaasjes, as de CSI-kontrôler rapportearret dat it de grutte fan skiven allinich "offline" kin feroarje (VolumeExpansion.OFFLINE), dan moat it proses fan it fergrutsjen fan de skiif sa gean:

As de plugin hat allinne VolumeExpansion.OFFLINE útwreiding kapasiteit en folume is op it stuit publisearre of beskikber op in knooppunt dan ControllerExpandVolume MOET ALLEEN oproppen wurde nei ien fan:

• De plugin hat controller PUBLISH_UNPUBLISH_VOLUME kapasiteit en ControllerUnpublishVolume is mei súkses oproppen.

OF OARS

• De plugin hat NET kontrôler PUBLISH_UNPUBLISH_VOLUME mooglikheid, de plugin hat node STAGE_UNSTAGE_VOLUME kapasiteit, en NodeUnstageVolume is mei súkses foltôge.

OF OARS

• De plugin hat NET kontrôler PUBLISH_UNPUBLISH_VOLUME kapasiteit, noch node STAGE_UNSTAGE_VOLUME kapasiteit, en NodeUnpublishVolume hat mei súkses foltôge.

Dit betsjut yn wêzen dat jo de skiif moatte losmeitsje fan 'e firtuele masine foardat jo it útwreidzje.

Lykwols, spitigernôch ymplemintaasje De CSI-spesifikaasje fia sidecars foldocht net oan dizze easken:

• Yn in sidecar container csi-attacher. Dêr is in diskusje oer begûn hjir.
• Wat is krekt in sidecarcontainer yn dit ferbân? De CSI-plugin sels ynteraktearret net mei de Kubernetes API, mar reagearret allinich op gRPC-oproppen dy't dernei stjoerd wurde troch sidecar-konteners. Latest wurde ûntwikkele troch de Kubernetes-mienskip.

Yn ús gefal (CSI-plugin) sjocht de operaasje fan it fergrutsjen fan de skiif der sa út:

1. Wy krije in gRPC-oprop ControllerExpandVolume;
2. Wy besykje de skiif yn 'e API te fergrutsjen, mar wy ûntfange in flater oer de ûnmooglikheid om de operaasje út te fieren, om't de skiif is monteard;
3. Wy bewarje de skiif identifier yn kaart, dy't befettet de skiven wêrfoar de ferheging operaasje moat wurde útfierd. Hjirûnder, foar koartens, sille wy dizze kaart neame as volumeResizeRequired;
4. Ferwiderje de pod dy't de skiif brûkt mei de hân. Kubernetes sil it opnij starte. Dat de skiif gjin tiid hat om te mount (ControllerPublishVolume) foardat jo de ferhegingsoperaasje foltôgje by it besykjen fan mount, kontrolearje wy dat de opjûne skiif noch yn is volumeResizeRequired en in flater weromjaan;
5. De CSI-bestjoerder besiket de operaasje opnij út te fieren. As de operaasje suksesfol wie, ferwiderje dan de skiif út volumeResizeRequired;
6. Omdat Disk ID ûntbrekt út volumeResizeRequired, ControllerPublishVolume giet mei súkses, de skiif is monteard, de pod begjint.

Alles liket ienfâldich genôch, mar lykas altyd binne d'r pitfalls. Fergruttet skiven eksterne-resizer, dy't yn gefal fan in flater tidens de operaasje brûkt in wachtrige mei in eksponinsjele ferheging fan time-out tiid oant 1000 sekonden:

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

Dit kin periodyk resultearje yn 'e operaasje fan' e skiifútwreiding wurdt ferlingd foar 15+ minuten en dus de korrespondearjende pod net beskikber is.

De iennichste opsje dy't ús frij maklik en pynlik liet om potinsjele downtime te ferminderjen wie it gebrûk fan ús ferzje fan eksterne resizer mei in maksimale time-outlimyt yn 5 sekonden:

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

Wy achte it net nedich om urgent in diskusje te begjinnen en de eksterne resizer te patchjen, om't offline grutte feroarje fan skiven in weromkear is dy't gau sil ferdwine fan alle wolkproviders.

Hoe kinne jo it begjinne te brûken?

De stjoerprogramma wurdt stipe op Kubernetes ferzje 1.15 en heger. Om de bestjoerder te wurkjen, moatte de folgjende easken foldien wurde:

• Flag --allow-privileged ynsteld op wearde true foar API tsjinner en kubelet;
• Ynbegrepen --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true foar API tsjinner en kubelet;
• Mount propagation (berch fuortplanting) moat ynskeakele wurde op it kluster. By it brûken fan Docker moat de daemon wurde konfigureare om dielde mounts te tastean.

Alle nedige stappen foar de ynstallaasje sels beskreaun yn README. Ynstallaasje omfettet it meitsjen fan objekten yn Kubernetes fan manifesten.

Foar de sjauffeur om te wurkjen hawwe jo it folgjende nedich:

• Spesifisearje de map identifier yn it manifest (folder-id) Yandex.Cloud (sjoch dokumintaasje);
• Om ynteraksje mei de Yandex.Cloud API, brûkt de CSI-bestjoerder in tsjinstkonto. Yn it manifest moat Geheim trochjûn wurde autorisearre kaaien út de tsjinst account. Yn de dokumintaasje beskriuwe, hoe meitsje in tsjinst account en krije kaaien.

Alles by inoar - probearje it, en wy sille graach ûntfange feedback en nije sakenas jo problemen tsjinkomme!

Fierdere stipe

As resultaat wolle wy opmerke dat wy dizze CSI-bestjoerder ymplementearre hawwe net út in grutte winsk om wille te hawwen mei it skriuwen fan applikaasjes yn Go, mar fanwegen in driuwend ferlet binnen it bedriuw. It liket ús net praktysk om ús eigen ymplemintaasje te behâlden, dus as Yandex belangstelling toant en beslút troch te gean mei it stypjen fan de sjauffeur, sille wy graach it repository nei har oerdrage.

Derneist hat Yandex wierskynlik in eigen ymplemintaasje fan 'e CSI-bestjoerder yn har behearde Kubernetes-kluster, dat kin wurde frijlitten yn Open Source. Wy sjogge dizze ûntwikkelingsopsje ek as geunstich - de mienskip sil in bewezen bestjoerder kinne brûke fan in tsjinstferliener, en net fan in bedriuw fan tredden.

PS

Lês ek op ús blog:

• «Folume plugins foar Kubernetes opslach: fan Flexvolume nei CSI";
• «Wy begripe de Container Storage Interface (yn Kubernetes en net allinich)";
• «Is it maklik en handich om in Kubernetes-kluster te meitsjen? Addon-operator oankundigje";
• «Kubernetes útwreidzje en oanfolje (oersjoch en fideorapport)".

Boarne: www.habr.com