ProHoster > blog > Gweinyddiaeth > Ein profiad o ddatblygu gyrrwr CSI yn Kubernetes ar gyfer Yandex.Cloud

Ein profiad o ddatblygu gyrrwr CSI yn Kubernetes ar gyfer Yandex.Cloud

Ein profiad o ddatblygu gyrrwr CSI yn Kubernetes ar gyfer Yandex.Cloud

Rydym yn falch o gyhoeddi bod Flant yn ehangu ei gyfraniad i offer Ffynhonnell Agored ar gyfer Kubernetes trwy ryddhau fersiwn alffa o'r gyrrwr CSI (Rhyngwyneb Storio Cynhwysydd) ar gyfer Yandex.Cloud.

Ond cyn symud ymlaen at y manylion gweithredu, gadewch i ni ateb y cwestiwn pam mae angen hyn o gwbl pan fydd gan Yandex wasanaeth eisoes Gwasanaeth a Reolir ar gyfer Kubernetes.

Cyflwyniad

Pam fod hyn?

O fewn ein cwmni, o'r cychwyn cyntaf o ddefnyddio Kubernetes wrth gynhyrchu (h.y. ers sawl blwyddyn bellach), rydym wedi bod yn datblygu ein hofferyn ein hunain (deckhouse), sydd, gyda llaw, hefyd yn bwriadu sicrhau ei fod ar gael yn fuan fel prosiect Ffynhonnell Agored. . Gyda'i help, rydym yn ffurfweddu ac yn ffurfweddu ein holl glystyrau yn unffurf, ac ar hyn o bryd mae mwy na 100 ohonynt eisoes, ar amrywiaeth eang o ffurfweddiadau caledwedd ac yn yr holl wasanaethau cwmwl sydd ar gael.

Mae gan glystyrau sy'n defnyddio deckhouse yr holl gydrannau angenrheidiol ar gyfer gweithredu: balanswyr, monitro gyda siartiau cyfleus, metrigau a rhybuddion, dilysu defnyddwyr trwy ddarparwyr allanol ar gyfer mynediad i bob dangosfyrddau, ac ati. Nid oes diben gosod clwstwr “pwmpio” o'r fath mewn datrysiad wedi'i reoli, gan fod hyn yn aml naill ai'n amhosibl neu'n arwain at yr angen i analluogi hanner y cydrannau.

NB: Dyma ein profiad, ac y mae yn bur neillduol. Nid ydym mewn unrhyw ffordd yn awgrymu y dylai pawb ddefnyddio clystyrau Kubernetes ar eu pen eu hunain yn lle defnyddio atebion parod. Gyda llaw, nid oes gennym unrhyw brofiad gwirioneddol o weithredu Kubernetes o Yandex ac ni fyddwn yn rhoi unrhyw asesiad o'r gwasanaeth hwn yn yr erthygl hon.

Beth ydyw ac i bwy?

Felly, rydym eisoes wedi siarad am y dull modern o storio yn Kubernetes: sut mae CSI yn gweithio? и sut y daeth y gymuned i'r dull hwn.

Ar hyn o bryd, mae llawer o ddarparwyr gwasanaeth cwmwl mawr wedi datblygu gyrwyr ar gyfer defnyddio eu disgiau cwmwl fel Cyfrol Barhaus yn Kubernetes. Os nad oes gan y cyflenwr yrrwr o'r fath, ond mae'r holl swyddogaethau angenrheidiol yn cael eu darparu trwy'r API, yna nid oes dim yn eich atal rhag gweithredu'r gyrrwr eich hun. Dyma beth ddigwyddodd gyda Yandex.Cloud.

Rydym yn cymryd fel sail ar gyfer datblygiad Gyrrwr CSI ar gyfer cwmwl DigitalOcean a chwpl o syniadau gan gyrwyr ar gyfer GCP, gan fod rhyngweithio ag API y cymylau hyn (Google a Yandex) â nifer o debygrwydd. Yn benodol, mae'r API a GCP, ac yn Yandex dychwelyd gwrthrych Operation i olrhain statws gweithrediadau hir-redeg (er enghraifft, creu disg newydd). I ryngweithio â'r API Yandex.Cloud, defnyddiwch Yandex.Cloud Ewch SDK.

Canlyniad y gwaith a wnaed cyhoeddwyd ar GitHub a gall fod yn ddefnyddiol i'r rhai sydd, am ryw reswm, yn defnyddio eu gosodiad Kubernetes eu hunain ar beiriannau rhithwir Yandex.Cloud (ond nid clwstwr a reolir yn barod) ac a hoffai ddefnyddio (archebu) disgiau trwy CSI.

Gweithredu

Prif nodweddion

Ar hyn o bryd mae'r gyrrwr yn cefnogi'r swyddogaethau canlynol:

  • Trefnu disgiau ym mhob parth o'r clwstwr yn ôl topoleg y nodau yn y clwstwr;
  • Tynnu disgiau a archebwyd yn flaenorol;
  • Newid maint all-lein ar gyfer disgiau (Yandex.Cloud peidiwch â chefnogi cynyddu'r disgiau sy'n cael eu gosod ar y peiriant rhithwir). I gael gwybodaeth am sut yr oedd yn rhaid addasu'r gyrrwr i wneud newid maint mor ddi-boen â phosibl, gweler isod.

Yn y dyfodol, rydym yn bwriadu gweithredu cefnogaeth ar gyfer creu a dileu cipluniau disg.

Y prif anhawster a sut i'w oresgyn

Mae diffyg y gallu i gynyddu disgiau mewn amser real yn API Yandex.Cloud yn gyfyngiad sy'n cymhlethu gweithrediad newid maint PV (Cyfrol Barhaus): yn yr achos hwn, mae angen atal y pod cais sy'n defnyddio'r ddisg, a gall hyn achosi ceisiadau amser segur.

Yn ôl Manylebau CSI, os yw'r rheolydd CSI yn adrodd y gall newid maint disgiau “all-lein” yn unig (VolumeExpansion.OFFLINE), yna dylai'r broses o gynyddu'r ddisg fynd fel hyn:

Os oes gan yr ategyn yn unig VolumeExpansion.OFFLINE gallu ehangu a chyfaint yn cael ei gyhoeddi ar hyn o bryd neu ar gael ar nod bryd hynny ControllerExpandVolume DIM OND ar ôl naill ai:

  • Mae gan yr ategyn reolwr PUBLISH_UNPUBLISH_VOLUME galluog a ControllerUnpublishVolume wedi cael ei ddefnyddio yn llwyddiannus.

NEU ARALL

  • NID oes gan yr ategyn reolydd PUBLISH_UNPUBLISH_VOLUME gallu, mae'r ategyn wedi nod STAGE_UNSTAGE_VOLUME gallu, a NodeUnstageVolume wedi ei gwblhau yn llwyddiannus.

NEU ARALL

  • NID oes gan yr ategyn reolydd PUBLISH_UNPUBLISH_VOLUME gallu, na nôd STAGE_UNSTAGE_VOLUME gallu, a NodeUnpublishVolume wedi cwblhau yn llwyddiannus.

Mae hyn yn ei hanfod yn golygu bod angen i chi ddatgysylltu'r ddisg o'r peiriant rhithwir cyn ei ehangu.

Fodd bynnag, yn anffodus gweithredu Nid yw'r fanyleb CSI trwy geir ochr yn bodloni'r gofynion hyn:

  • Mewn cynhwysydd car ochr csi-attacher, a ddylai fod yn gyfrifol am bresenoldeb y bwlch gofynnol rhwng mowntiau, nid yw'r swyddogaeth hon yn cael ei gweithredu yn y newid maint all-lein. Dechreuwyd trafodaeth am hyn yma.
  • Beth yn union yw cynhwysydd car ochr yn y cyd-destun hwn? Nid yw'r ategyn CSI ei hun yn rhyngweithio ag API Kubernetes, ond dim ond yn ymateb i alwadau gRPC a anfonir ato gan gynwysyddion ceir ochr. diweddaraf yn cael eu datblygu gan gymuned Kubernetes.

Yn ein hachos ni (ategyn CSI), mae gweithrediad cynyddu'r ddisg yn edrych fel hyn:

  1. Rydym yn derbyn galwad GPC ControllerExpandVolume;
  2. Rydyn ni'n ceisio cynyddu'r ddisg yn yr API, ond rydyn ni'n derbyn gwall am yr amhosibilrwydd o berfformio'r llawdriniaeth oherwydd bod y ddisg wedi'i osod;
  3. Rydym yn storio'r dynodwr disg yn y map, sy'n cynnwys y disgiau y mae angen cyflawni'r gweithrediad cynyddu ar eu cyfer. Isod, er mwyn bod yn gryno, byddwn yn galw'r map hwn fel volumeResizeRequired;
  4. Tynnwch y cod sy'n defnyddio'r ddisg â llaw. Bydd Kubernetes yn ei ailgychwyn. Fel nad oes gan y ddisg amser i osod (ControllerPublishVolume) cyn cwblhau'r gweithrediad cynyddu wrth geisio mowntio, rydym yn gwirio bod y ddisg a roddir yn dal i fod i mewn volumeResizeRequired a dychwelyd gwall;
  5. Mae'r gyrrwr CSI yn ceisio ail-wneud y gweithrediad newid maint. Os oedd y llawdriniaeth yn llwyddiannus, yna tynnwch y ddisg o volumeResizeRequired;
  6. Achos Mae ID y ddisg ar goll o volumeResizeRequired, ControllerPublishVolume yn pasio'n llwyddiannus, mae'r ddisg wedi'i osod, mae'r pod yn cychwyn.

Mae popeth yn edrych yn ddigon syml, ond fel bob amser mae yna beryglon. Yn chwyddo disgiau allanol-resizer, sydd rhag ofn y bydd gwall yn ystod y llawdriniaeth yn defnyddio ciw gyda chynnydd esbonyddol yn yr amser terfyn hyd at 1000 eiliad:

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

Gall hyn arwain o bryd i'w gilydd at ymestyn y gweithrediad ehangu disg am 15+ munud ac, felly, na fydd y pod cyfatebol ar gael.

Yr unig opsiwn a oedd yn ddigon hawdd a di-boen i'n galluogi i leihau amser segur posibl oedd defnyddio ein fersiwn o resizer allanol gyda therfyn terfyn amser terfyn uchaf. mewn 5 eiliad:

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

Nid oeddem o'r farn ei bod yn angenrheidiol cychwyn trafodaeth ar fyrder a chlytio'r ailosodydd allanol, oherwydd mae newid maint disgiau all-lein yn adlais a fydd yn diflannu'n fuan o bob darparwr cwmwl.

Sut i ddechrau defnyddio?

Cefnogir y gyrrwr ar fersiwn Kubernetes 1.15 ac uwch. Er mwyn i'r gyrrwr weithio, rhaid bodloni'r gofynion canlynol:

  • Baner --allow-privileged gosod i werth true ar gyfer gweinydd API a kubelet;
  • Yn gynwysedig --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true ar gyfer gweinydd API a kubelet;
  • Gosod lluosogi (lluosogi mount) rhaid ei alluogi ar y clwstwr. Wrth ddefnyddio Docker, rhaid ffurfweddu'r daemon i ganiatáu mowntiau a rennir.

Yr holl gamau angenrheidiol ar gyfer y gosodiad ei hun a ddisgrifir yn README. Mae gosod yn golygu creu gwrthrychau yn Kubernetes o faniffestau.

Er mwyn i'r gyrrwr weithio bydd angen y canlynol arnoch:

  • Nodwch y dynodwr cyfeiriadur yn y maniffest (folder-id) Yandex.Cloud (gweler dogfennaeth);
  • I ryngweithio â'r API Yandex.Cloud, mae'r gyrrwr CSI yn defnyddio cyfrif gwasanaeth. Yn y maniffest, rhaid pasio Cyfrinach allweddi awdurdodedig o'r cyfrif gwasanaeth. Yn y ddogfennaeth a ddisgrifiwyd, sut i greu cyfrif gwasanaeth a chael allweddi.

Ar y cyfan - ceisiwch, a byddwn yn falch o dderbyn adborth a materion newyddos ydych chi'n dod ar draws unrhyw broblemau!

Cefnogaeth pellach

O ganlyniad, hoffem nodi ein bod wedi gweithredu'r gyrrwr CSI hwn nid allan o awydd mawr i gael hwyl yn ysgrifennu ceisiadau yn Go, ond oherwydd angen brys o fewn y cwmni. Nid yw'n ymddangos yn ymarferol i ni gynnal ein gweithrediad ein hunain, felly os yw Yandex yn dangos diddordeb ac yn penderfynu parhau i gefnogi'r gyrrwr, byddwn yn hapus i drosglwyddo'r ystorfa iddynt.

Yn ogystal, mae'n debyg bod gan Yandex ei weithrediad ei hun o'r gyrrwr CSI yn ei glwstwr Kubernetes a reolir, y gellir ei ryddhau yn Ffynhonnell Agored. Rydym hefyd yn gweld yr opsiwn datblygu hwn yn ffafriol - bydd y gymuned yn gallu defnyddio gyrrwr profedig gan ddarparwr gwasanaeth, ac nid gan gwmni trydydd parti.

PS

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Ychwanegu sylw