ProHoster > Eksperienca jonë e zhvillimit të driver-it CSI në Kubernetes për Yandex.Cloud

Eksperienca jonë e zhvillimit të driver-it CSI në Kubernetes për Yandex.Cloud

Eksperienca jonë e zhvillimit të driver-it CSI në Kubernetes për Yandex.Cloud

Jemi të lumtur të njoftojmë se kompania «Flant» po kontribuon edhe më shumë në mjetet Open Source për Kubernetes duke lëshuar versionin alfa të driver-it CSI (Container Storage Interface) për Yandex.Cloud.

Por para se të kalojmë te detajet e realizimit, le të përgjigjemi në pyetjen se pse është e nevojshme kjo, kur Yandex tashmë ka shërbimin Managed Service for Kubernetes.

Hyrje

Pse është kjo?

Brenda kompanisë sonë, që nga fillimi i përdorimit të Kubernetes në prodhim (dmth. për disa vite), ka zhvilluar një mjet të vetin (deckhouse), i cili, për fat të mirë, po planifikojmë gjithashtu ta bëjmë të disponueshëm si projekt Open Source së shpejti. Me ndihmën e tij ne konfiguroni dhe iniciativat tona në mënyrë uniform për të gjitha klastra tona, të cilat aktualisht janë më shumë se 100, dhe përsëri janë në konfiguracione të ndryshme harduerike dhe në të gjitha shërbimet e disponueshme të cloud.

Klastrat qĂ« pĂ«rdorin deckhouse kanĂ« tĂ« gjitha komponentĂ«t e nevojshĂ«m pĂ«r funksionimin: balancuesit, monitorimin me grafika, metrika dhe alerte tĂ« pĂ«rshtatshme, autentifikimin e pĂ«rdoruesve pĂ«rmes ofruesve tĂ« jashtĂ«m pĂ«r akses nĂ« tĂ« gjitha dashboard-et dhe kĂ«shtu me radhĂ«. NjĂ« klaster i tillĂ« i ‘pĂ«rmirĂ«suar’ nuk ka kuptim tĂ« vendoset nĂ« njĂ« zgjidhje tĂ« menaxhuar, pasi shpeshherĂ« Ă«shtĂ« e pamundur, ose do tĂ« çonte nĂ« nevojĂ«n pĂ«r tĂ« çaktivizuar gjysmĂ«n e komponenteve.

NB: Kjo është përvoja jonë, dhe ajo është mjaft e veçantë. Ne aspak nuk po sigurojmë se gjithkush duhet të merret vetë me vendosjen e klastra Kubernetes në vend që të përdorë zgjidhjet e gatshme. Sidoqoftë, nuk kemi përvojë reale të përdorimit të Kubernetes nga Yandex dhe nuk do ta vlerësojmë këtë shërbim në artikullin e tanishëm.

ÇfarĂ« Ă«shtĂ« kjo dhe pĂ«r kĂ«?

Kështu, ne tashmë kemi folur për qasjen moderne ndaj ruajtjes në Kubernetes: si funksionon CSI dhe si arriti komuniteti në këtë qasje.

Aktualisht, shumĂ« ofrues tĂ« mĂ«dhenj tĂ« shĂ«rbimeve tĂ« cloud kanĂ« zhvilluar driver-a pĂ«r tĂ« pĂ«rdorur diskĂ«t e tyre ‘cloud’ si Volume tĂ« PĂ«rhershĂ«m nĂ« Kubernetes. NĂ«se njĂ« ofrues nuk ka njĂ« driver tĂ« tillĂ«, por tĂ« gjitha funksionet e nevojshme ofrohen pĂ«rmes API-sĂ«, atĂ«herĂ« nuk ka asgjĂ« qĂ« ndalon realizimin e driver-it me forcat tona. KĂ«shtu ndodhi edhe me Yandex.Cloud.

Për bazën e zhvillimit ne e morëm CSI-driver-in për cloud-in DigitalOcean dhe disa ide nga driver-i për GCP, pasi ndërveprimi me API-në e këtyre cloud-ëve (Google dhe Yandex) ka disa ngjashmëri. Në veçanti, API janë siç janë GCP, dhe Yandex kthen objekti Operacioni për të ndjekur statusin e operacioneve të gjatë (p.sh., krijimi i një disku të ri). Për t'u bashkëvepruar me API-në e Yandex.Cloud përdoret Yandex.Cloud Go SDK.

Rezultati i punës së kryer është publikuar në GitHub dhe mund të jetë i dobishëm për ata që për një arsye apo tjetër përdorin një instalim të vetin të Kubernetes në makinat virtuale të Yandex.Cloud (por jo një klaster të menaxhuar) dhe do të dëshironin të përdornin (porosinin) disqet përmes CSI.

Implementimi

Veçoritë kryesore

Në këtë moment, driveri mbështet funksionet e mëposhtme:

  • PorosinĂ« e disqeve nĂ« tĂ« gjitha zonat e klasterit sipas topologjisĂ« sĂ« nyjave tĂ« disponueshme nĂ« klaster;
  • Fshirjen e disqeve tĂ« porositura mĂ« parĂ«;
  • Rritjen offline pĂ«r disqet (Yandex.Cloud nuk mbĂ«shtet rritja e disqeve qĂ« janĂ« tĂ« montuara nĂ« makinĂ«n virtuale). PĂ«r mĂ«nyrĂ«n se si duhej tĂ« ribĂ«hej driveri qĂ« tĂ« realizohej sa mĂ« pa dhembje rritja, shih mĂ« poshtĂ«.

Në të ardhmen planifikohet të implementohet mbështetje për krijimin dhe fshirjen e snapshot-eve të disqeve.

Sfidat kryesore dhe kapërcimi i tyre

Mungesa nĂ« API-nĂ« e Yandex.Cloud e mundĂ«sisĂ« pĂ«r tĂ« rritur disqet nĂ« kohĂ« reale — njĂ« kufizim qĂ« e vĂ«shtirĂ«son operacionin e rritjes pĂ«r PV (VĂ«llimi i PĂ«rhershĂ«m): sepse nĂ« atĂ« rast Ă«shtĂ« e nevojshme qĂ« pod-i i aplikacionit qĂ« pĂ«rdor disku tĂ« ndalet, gjĂ« qĂ« mund tĂ« shkaktojĂ« ndalimin e aplikacionit.

Sipas specifikimeve CSI, nëse CSI-kontrollori raporton se di të bëjë rritjen e disqeve vetëm "në offline" (VolumeExpansion.OFFLINE), procesi i rritjes së disku duhet të kalojë kështu:

NĂ«se plugin-i ka vetĂ«m VolumeExpansion.OFFLINE kapacitetin e rritjes dhe vĂ«llimi aktualisht Ă«shtĂ« i publikuar ose i disponueshĂ«m nĂ« njĂ« nyje atĂ«herĂ« ControllerExpandVolume DUHET tĂ« thirret VETËM pasi:

  • Plugin-i ka PUBLISH_UNPUBLISH_VOLUME kapacitetin dhe ControllerUnpublishVolume Ă«shtĂ« thirrur me sukses.

OSE PAS

  • Plugin-i NUK ka PUBLISH_UNPUBLISH_VOLUME kapacitetin e kontrollit, plugin-i ka nyje STAGE_UNSTAGE_VOLUME kapacitetin, dhe NodeUnstageVolume Ă«shtĂ« pĂ«rfunduar me sukses.

OSE PAS

  • Plugin-i NUK ka PUBLISH_UNPUBLISH_VOLUME kapacitetin, as nyja STAGE_UNSTAGE_VOLUME kapacitetin, dhe NodeUnpublishVolume nuk Ă«shtĂ« pĂ«rfunduar me sukses.

Në thelb, kjo do të thotë se është e nevojshme të shkëputet disku nga makina virtuale përpara se ta rrisim.

Megjithatë, fatkeqësisht, implementim specifikimet e CSI përmes sidecar-ve nuk i përmbushin këto kërkesa:

  • NĂ« konteinerin sidecar csi-attacher, i cili duhet tĂ« jetĂ« pĂ«rgjegjĂ«s pĂ«r sigurimin e hapĂ«sirĂ«s sĂ« nevojshme midis montimeve, gjatĂ« rritjes offline thjesht nuk Ă«shtĂ« implementuar ky funksionalitet. Diskutimin pĂ«r kĂ«tĂ« e iniciuan kĂ«tu.
  • ÇfarĂ« Ă«shtĂ« nĂ« tĂ« vĂ«rtetĂ« njĂ« kontenier sidecar nĂ« kĂ«tĂ« kontekst? VetĂ« plugini CSI nuk merret me ndĂ«rveprimin me API-nĂ« e Kubernetes, por thjesht reagon ndaj thirrjeve gRPC qĂ« i dĂ«rgojnĂ« kontenierĂ«t sidecar. zhvillohen Komuniteti Kubernetes.

Në rastin tonë (plugini CSI) operacioni i rritjes së diskut duket si më poshtë:

  1. Merrni thirrjen gRPC. ControllerExpandVolume;
  2. Përpiqemi të rrisim diskun në API, por marrim një gabim për pamundësinë e kryerjes së operacionit, pasi disku është i montuar;
  3. Ruajmë identifikuesin e diskut në një hartë që përmban diskët për të cilët duhet të kryhet operacioni i rritjes. Më pas, për shkak të shkurtësisë, do ta quajmë këtë hartë si volumeResizeRequired.;
  4. Dorezoni manualisht pod-in që përdor disku. Kubernetes do ta ri-startojë atë. Për të parandaluar që disku të montojë përpara përfundimit të operacionit të rritjes gjatë përpjekjes për të montuar, kontrollojmë që ky disk të jetë akoma nëControllerPublishVolume) e të kthejmë një gabim; volumeResizeRequired. Driver-i CSI përpiqet të rrisë përsëri operacionin. Nëse operacioni kalon, atëherë e hiqni diskun nga
  5. Pasi identifikuesi i diskut mungon në volumeResizeRequired.;
  6. kalon me sukses, disku monton, pod-i startohet. volumeResizeRequired., ControllerPublishVolume E gjithë kjo duket mjaft e thjeshtë, por si gjithmonë ka pengesat e veta. Rritja e diskëve është përgjegjësia e

external-resizer, i cili në rast gabimi gjatë kryerjes së operacionit përdor një radhëme rritje eksponenciale të kohës së skadimit deri në 1000 sekonda: func DefaultControllerRateLimiter() RateLimiter { return NewMaxOfRateLimiter( NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second), &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)}, ) } Kjo mund të çojë përherë në rritjen e operacionit të diskut të zgjasë 15+ minuta dhe, kështu, të shkaktojë mungesë të përkatës pod-i.

Opcioni i vetëm që na lejojë të reduktojmë kohën e mundshme të ndërprerjes ishte përdorimi i versionit tonë të external-resizer me kufizim maksimal të skadimit

në 5 sekonda.

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second) Nuk e konsideruam të nevojshme të nisim një diskutim urgjent dhe të patch-ojmë external-resizer, sepse rritja offline e diskëve është një relikt që së shpejti do të humbasë tek të gjithë ofruesit e shërbimeve në cloud.:

Si mund të filloni përdorimin?

Driver-i mbështetet në Kubernetes versionin 1.15 dhe më lart. Për të funksionuar, duhet të përmbushen kërkesat e mëposhtme:

Si si filloni ta përdorni?

Drejtuesi mbështetet në Kubernetes versionin 1.15 dhe më lart. Për të punuar me drejtuesin duhet të plotësohen kërkesat e mëposhtme:

  • Flamuri --allow-privileged i vendosur nĂ« vlerĂ«n true pĂ«r API-nĂ« e serverit dhe kubelet;
  • Aktivizuar --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true pĂ«r API-nĂ« e serverit dhe kubelet;
  • PĂ«rhapja e montimit (montimi i pĂ«rhapjes) duhet tĂ« aktivizohet nĂ« klaster. Kur pĂ«rdoret Docker, demoni duhet tĂ« konfigurohet nĂ« mĂ«nyrĂ« qĂ« tĂ« lejojĂ« objektet e pĂ«rbashkĂ«ta tĂ« montimit (montime tĂ« ndara).

Të gjitha hapat e nevojshëm për instalimin e tij janë përshkruar në README. Instalimi përbën krijimin e objekteve në Kubernetes nga manifestet.

Për të punuar me drejtuesin do t'ju nevojitet:

  • TĂ« specifikoni nĂ« manifest identifikuesin e direktoriumit (folder-id) tĂ« Yandex.Cloud (shih dokumentacionin);
  • PĂ«r tĂ« ndĂ«rvepruar me API-nĂ« e Yandex.Cloud nĂ« drejtuesin CSI pĂ«rdoret njĂ« llogari shĂ«rbimi. NĂ« manifestin Secret duhet tĂ« kaloni çelĂ«sat e autorizuar tĂ« llogarisĂ« sĂ« shĂ«rbimit. NĂ« dokumentacionin pĂ«rshkruhet, si tĂ« krijoni njĂ« llogari shĂ«rbimi dhe tĂ« merrni çelĂ«sat.

NĂ« pĂ«rgjithĂ«si — provoni, dhe ne do tĂ« jemi tĂ« lumtur pĂ«r feedbackun dhe probleme tĂ« reja, nĂ«se ndoni ndonjĂ« problem!

Mbështetje e mëtejshme

Si përfundim, do të dëshironim të theksonim se këtë drejtues CSI e kemi zhvilluar jo nga dëshira për të luajtur me shkrimin e aplikacioneve në Go, por për një nevojë të ngutshme brenda kompanisë. Të mbash një realizim të tillë të vetin nuk na duket e arsyeshme, prandaj, nëse Yandex shfaq interes dhe vendos të vazhdojë mbështetje për drejtuesin, atëherë ne me kënaqësi do ta transferojmë depozitën në dispozitat e tyre.

PĂ«r mĂ« tepĂ«r, ndoshta Yandex nĂ« klasterin e menaxhuar Kubernetes ka njĂ« realizim tĂ« vetin tĂ« drejtuesit CSI, tĂ« cilin mund ta lĂ«shojĂ« nĂ« Open Source. Ky variant i zhvillimit gjithashtu na duket i favorshĂ«m — komuniteti do tĂ« jetĂ« nĂ« gjendje tĂ« pĂ«rdorĂ« njĂ« drejtues tĂ« provuar nga ofruesi i shĂ«rbimeve, jo nga njĂ« kompani e jashtme.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster