ProHoster > Blog > Administratioun > Eis Erfahrung an der Entwécklung vun engem CSI Chauffer zu Kubernetes fir Yandex.Cloud

Eis Erfahrung an der Entwécklung vun engem CSI Chauffer zu Kubernetes fir Yandex.Cloud

Eis Erfahrung an der Entwécklung vun engem CSI Chauffer zu Kubernetes fir Yandex.Cloud

Mir si frou matzedeelen datt de Flant säi Bäitrag zu Open Source Tools fir Kubernetes erweidert andeems se verëffentlecht alpha Versioun vum CSI Chauffer (Container Storage Interface) fir Yandex.Cloud.

Awer ier mer op d'Implementatiounsdetailer weidergoen, loosst eis d'Fro beäntweren firwat dëst iwwerhaapt gebraucht gëtt wann Yandex schonn e Service huet Managed Service fir Kubernetes.

Aféierung

Firwat ass dat?

Bannent eiser Firma, vun Ufank u Kubernetes an der Produktioun (dh zënter e puer Joer) entwéckelen mir eisen eegenen Tool (Deckhouse), wat mir iwwregens och plangen geschwënn als Open Source Projet zur Verfügung ze stellen. . Mat senger Hëllef konfiguréieren a konfiguréieren mir all eis Stärekéip eenheetlech, an de Moment sinn et scho méi wéi 100 vun hinnen, op enger grousser Villfalt vun Hardware Konfiguratiounen an an all verfügbare Cloud Servicer.

Cluster, déi Deckhouse benotzen, hunn all d'Komponente fir d'Operatioun néideg: Balancer, Iwwerwachung mat praktesche Charts, Metriken an Alarmer, Benotzerauthentifikatioun duerch extern Ubidder fir Zougang zu all Dashboards, a sou weider. Et ass kee Sënn fir sou e "gepompelt" Cluster an enger verwalteter Léisung z'installéieren, well dëst dacks entweder onméiglech ass oder zu der Bedierfnes féiert fir d'Halschent vun de Komponenten auszeschalten.

NB: Dëst ass eis Erfahrung, an et ass ganz spezifesch. Mir proposéieren op kee Fall datt jidderee Kubernetes Cluster eleng soll ofsetzen anstatt fäerdege Léisungen ze benotzen. Iwwregens hu mir keng richteg Erfahrung am Betrib Kubernetes aus Yandex a mir wäerten keng Bewäertung vun dësem Service an dësem Artikel ginn.

Wat ass et a fir wien?

Also, mir hu schonn iwwer déi modern Approche fir d'Lagerung an Kubernetes geschwat: wéi funktionéiert CSI? и wéi d'Gemeng koum zu dëser Approche.

De Moment hu vill grouss Cloud Service Provider Chauffeuren entwéckelt fir hir Cloud Disks als Persistent Volume an Kubernetes ze benotzen. Wann de Fournisseur net sou e Chauffer huet, awer all déi néideg Funktiounen iwwer d'API geliwwert ginn, da verhënnert näischt datt Dir de Chauffer selwer implementéiert. Dëst ass wat mam Yandex.Cloud geschitt ass.

Mir hunn als Basis fir Entwécklung geholl CSI Treiber fir DigitalOcean Cloud an e puer Iddien aus Treiber fir GCP, Zënter Interaktioun mat der API vun dëse Wolleken (Google an Yandex) huet eng Rei Ähnlechkeeten. Besonnesch d'API an GCP, a bei Yandex en Objet zréckginn Operation fir de Status vu laang lafenden Operatiounen ze verfolgen (zum Beispill eng nei Scheif erstellen). Fir mat der Yandex.Cloud API ze interagéieren, benotzt Yandex.Cloud Go SDK.

D'Resultat vun der Aarbecht gemaach опубликован op GitHub a kann nëtzlech sinn fir déi, déi aus irgendege Grënn hir eege Kubernetes Installatioun op Yandex benotzen.Cloud virtuelle Maschinnen (awer net e fäerdege verwaltete Cluster) a gären Disken duerch CSI benotzen (bestellen).

Ëmsetzung

Schlëssel Features

De Moment ënnerstëtzt de Chauffer déi folgend Funktiounen:

  • Uerdnung vun Disken an all Zonen vum Stärekoup no der Topologie vun den Noden am Stärekoup;
  • Ewechzehuelen virdrun bestallt discs;
  • Offline Gréisst änneren fir Disken (Yandex.Cloud net ënnerstëtzen d'Erhéijung vun den Disken déi op der virtueller Maschinn montéiert sinn). Fir Informatiounen iwwer wéi de Chauffer muss geännert ginn fir d'Gréisst esou schmerzlos wéi méiglech ze maachen, kuckt hei ënnen.

An Zukunft plangen mir d'Ënnerstëtzung fir d'Erstelle an d'Läschen vun Disk Snapshots ëmzesetzen.

D'Haaptschwieregkeet a wéi et ze iwwerwannen

D'Feele vun der Fäegkeet fir Disken an Echtzäit an der Yandex ze vergréisseren.Cloud API ass eng Begrenzung déi d'Gréisst änneren fir PV (Persistent Volumen) komplizéiert: an dësem Fall ass et néideg datt d'Applikatioun Pod, déi d'Disk benotzt, gestoppt gëtt, an dëst kann Ausdauer Uwendungen Ursaach.

Nëmmen Spezifikatioune vun CSI, wann den CSI Controller mellt datt et d'Gréisst vun Disken nëmmen "offline" ka änneren (VolumeExpansion.OFFLINE), da soll de Prozess vun der Erhéijung vun der Disk esou goen:

Wann de Plugin huet nëmmen VolumeExpansion.OFFLINE Expansiounsfäegkeet a Volumen ass de Moment publizéiert oder verfügbar op engem Node dann ControllerExpandVolume MUSS NËMMEN genannt ginn no entweder:

  • De Plugin huet Controller PUBLISH_UNPUBLISH_VOLUME Fäegkeet an ControllerUnpublishVolume gouf erfollegräich opgeruff.

ODER SOSS

  • De Plugin huet NET Controller PUBLISH_UNPUBLISH_VOLUME Fäegkeet, de Plugin huet Node STAGE_UNSTAGE_VOLUME Fäegkeet, an NodeUnstageVolume gouf erfollegräich ofgeschloss.

ODER SOSS

  • De Plugin huet NET Controller PUBLISH_UNPUBLISH_VOLUME Fäegkeet, nach Node STAGE_UNSTAGE_VOLUME Fäegkeet, an NodeUnpublishVolume huet erfollegräich ofgeschloss.

Dëst bedeit am Wesentlechen datt Dir den Disk vun der virtueller Maschinn muss trennen ier Dir se ausbaut.

Allerdéngs leider Ëmsetzung D'CSI Spezifizéierung iwwer Sidecars entsprécht dës Ufuerderungen net:

  • An engem Sidecar Container csi-attacher, déi verantwortlech ass fir d'Präsenz vun der erfuerderter Spalt tëscht Mounts, ass dës Funktionalitéit einfach net an der Offline-Gréisst ëmgesat. Eng Diskussioun doriwwer gouf lancéiert hei.
  • Wat ass genee e Sidecar Container an dësem Kontext? Den CSI Plugin selwer interagéiert net mat der Kubernetes API, awer reagéiert nëmmen op gRPC Uriff, déi duerch Sidecar Container geschéckt ginn. Neisten entwéckelt ginn vun der Kubernetes Gemeinschaft.

An eisem Fall (CSI Plugin) gesäit d'Operatioun vun der Erhéijung vun der Disk esou aus:

  1. Mir kréien e gRPC Uruff ControllerExpandVolume;
  2. Mir probéieren d'Disk an der API ze erhéijen, awer mir kréien e Feeler iwwer d'Onméiglechkeet fir d'Operatioun auszeféieren, well d'Disk montéiert ass;
  3. Mir späicheren den Disk Identifizéierer op der Kaart, déi d'Disken enthält fir déi d'Erhéijungsoperatioun muss gemaach ginn. Drënner, fir Kuerzegkeet, wäerte mir dës Kaart als volumeResizeRequired;
  4. Huelt de Pod manuell deen den Disk benotzt. Kubernetes wäert et nei starten. Also datt den Disk keng Zäit huet fir ze montéieren (ControllerPublishVolume) ier Dir d'Erhéijungsoperatioun ofgeschloss hutt wann Dir probéiert ze montéieren, kontrolléiere mir datt de gegebene Disk nach ëmmer dran ass volumeResizeRequired an e Feeler zréck;
  5. Den CSI-Treiber probéiert d'Gréisst änneren ze maachen. Wann d'Operatioun erfollegräich war, huelt d'Disk aus volumeResizeRequired;
  6. Well Disk ID fehlt vun volumeResizeRequired, ControllerPublishVolume passéiert erfollegräich, den Disk ass montéiert, de Pod fänkt un.

Alles gesäit einfach genuch aus, awer wéi ëmmer ginn et Falen. Vergréissert Disken externen-resizer, déi am Fall vun engem Feeler während der Operatioun benotzt eng Schlaang mat enger exponentieller Erhéijung vun der Timeoutzäit bis zu 1000 Sekonnen:

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

Dëst kann periodesch dozou féieren datt d'Diskexpansiounsoperatioun fir 15+ Minutten verlängert gëtt an domat de entspriechende Pod net verfügbar ass.

Déi eenzeg Optioun, déi eis ganz einfach a schmerzlos erlaabt huet, potenziell Ausdauer ze reduzéieren, war d'Benotzung vun eiser Versioun vum externen Resizer mat enger maximaler Timeout Limit an 5 Sekonnen:

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

Mir hunn et net néideg ugesinn fir dréngend eng Diskussioun ze initiéieren an den externen Resizer ze patchen, well d'Offline Gréisst vun Disken e Réckgang ass dee geschwënn vun all Cloud Provider verschwannen.

Wéi ufänken ze benotzen?

De Chauffer gëtt op Kubernetes Versioun 1.15 a méi héich ënnerstëtzt. Fir de Chauffer ze schaffen, mussen déi folgend Ufuerderunge erfëllt sinn:

  • Fändel --allow-privileged op Wäert gesat true fir API Server an kubelet;
  • abegraff --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true fir API Server an kubelet;
  • Mount Verbreedung (Mount Verbreedung) muss um Cluster aktivéiert ginn. Wann Dir Docker benotzt, muss den Daemon konfiguréiert sinn fir gedeelt Mounts z'erméiglechen.

All déi néideg Schrëtt fir d'Installatioun selwer beschriwwen an README. Installatioun beinhalt d'Erstelle vun Objeten an Kubernetes aus Manifestatiounen.

Fir de Chauffer ze schaffen, braucht Dir déi folgend:

  • Gitt den Verzeichnisidentifizéierer am Manifest un (folder-id) Yandex.Cloud (gesinn Dokumentatioun);
  • Fir mat der Yandex.Cloud API ze interagéieren, benotzt den CSI Chauffeur e Servicekonto. Am Manifest muss Geheimnis passéiert ginn autoriséiert Schlësselen vum Service Kont. An der Dokumentatioun beschriwwen, wéi een e Servicekonto erstellt a Schlëssele kritt.

Alles an Allem - probéieren, a mir wäerten frou Feedback ze kréien an nei Problemerwann Dir Problemer stousse!

Weider Ënnerstëtzung

Als Resultat wëlle mir bemierken datt mir dësen CSI Chauffer implementéiert hunn net aus engem grousse Wonsch fir Spaass ze schreiwen Uwendungen am Go, mee wéinst engem dréngende Bedierfnes bannent der Firma. Et schéngt eis net praktesch fir eis eegen Implementatioun z'erhalen, also wann Yandex Interessi weist an decidéiert de Chauffer weider ze ënnerstëtzen, wäerte mir frou de Repository un hinnen ze transferéieren.

Zousätzlech huet Yandex wahrscheinlech seng eege Implementatioun vum CSI Chauffer a sengem verwalteten Kubernetes Cluster, deen an Open Source verëffentlecht ka ginn. Mir gesinn och dës Entwécklungsoptioun als gënschteg - d'Gemeinschaft wäert fäeg sinn e bewährte Chauffer vun engem Déngschtleeschter ze benotzen, an net vun enger Drëtt Partei Firma.

PS

Liest och op eisem Blog:

Source: will.com

Setzt e Commentaire