Uzoefu wetu katika kutengeneza kiendesha CSI katika Kubernetes kwa Yandex.Cloud

Tunayo furaha kutangaza kwamba Flant inapanua mchango wake kwa zana za Open Source za Kubernetes kwa kutoa toleo la alpha la kiendeshi cha CSI (Kiolesura cha Kuhifadhi Kontena) kwa Yandex.Cloud.

Lakini kabla ya kuendelea na maelezo ya utekelezaji, hebu tujibu swali la kwa nini hii inahitajika wakati Yandex tayari ina huduma. Huduma inayosimamiwa ya Kubernetes.

Utangulizi

Kwa nini hii?

Ndani ya kampuni yetu, tangu mwanzo wa kutumia Kubernetes katika uzalishaji (yaani kwa miaka kadhaa sasa), tumekuwa tukitengeneza zana yetu wenyewe (deckhouse), ambayo, kwa njia, tunapanga pia kuifanya ipatikane kama mradi wa Open Source. . Kwa msaada wake, tunasanidi na kusanidi kwa usawa vikundi vyetu vyote, na kwa sasa tayari kuna zaidi ya 100 kati yao, kwenye anuwai ya usanidi wa vifaa na katika huduma zote za wingu zinazopatikana.

Vikundi vinavyotumia deckhouse vina vipengele vyote vinavyohitajika kwa uendeshaji: usawazishaji, ufuatiliaji na chati zinazofaa, vipimo na arifa, uthibitishaji wa mtumiaji kupitia watoa huduma wa nje kwa upatikanaji wa dashibodi zote, na kadhalika. Hakuna maana ya kusanikisha nguzo kama hiyo ya "pumped up" kwenye suluhisho iliyosimamiwa, kwani hii mara nyingi haiwezekani au itasababisha hitaji la kuzima nusu ya vifaa.

NB: Huu ni uzoefu wetu, na ni maalum kabisa. Hatupendekezi kwa vyovyote kwamba kila mtu atumie vikundi vya Kubernetes peke yake badala ya kutumia suluhu zilizotengenezwa tayari. Kwa njia, hatuna uzoefu halisi katika uendeshaji wa Kubernetes kutoka Yandex na hatutatoa tathmini yoyote ya huduma hii katika makala hii.

Ni nini na kwa nani?

Kwa hivyo, tayari tumezungumza juu ya njia ya kisasa ya kuhifadhi katika Kubernetes: CSI inafanyaje kazi? и jinsi jumuiya ilikuja kwa mbinu hii.

Hivi sasa, watoa huduma wengi wakubwa wa wingu wameunda viendeshaji kwa kutumia diski zao za wingu kama Kiasi Kinachoendelea katika Kubernetes. Ikiwa muuzaji hana dereva kama huyo, lakini kazi zote muhimu hutolewa kupitia API, basi hakuna kitu kinachokuzuia kutekeleza dereva mwenyewe. Hii ndio ilifanyika na Yandex.Cloud.

Tulichukua kama msingi wa maendeleo Dereva wa CSI wa wingu la DigitalOcean na mawazo kadhaa kutoka madereva kwa GCP, kwa kuwa mwingiliano na API ya mawingu haya (Google na Yandex) ina idadi ya kufanana. Hasa, API na GCP, na y Yandex kurudisha kitu Operation kufuatilia hali ya uendeshaji wa muda mrefu (kwa mfano, kuunda diski mpya). Ili kuingiliana na Yandex.Cloud API, tumia Yandex.Cloud Go SDK.

Matokeo ya kazi iliyofanywa iliyochapishwa kwenye GitHub na inaweza kuwa na manufaa kwa wale ambao, kwa sababu fulani, wanatumia usakinishaji wao wa Kubernetes kwenye mashine za mtandaoni za Yandex.Cloud (lakini si nguzo iliyosimamiwa tayari) na wangependa kutumia (kuagiza) diski kupitia CSI.

Utekelezaji

Vipengele muhimu

Hivi sasa kiendeshaji inasaidia kazi zifuatazo:

• Kuagiza diski katika kanda zote za nguzo kulingana na topolojia ya nodi kwenye nguzo;
• Kuondoa diski zilizoagizwa hapo awali;
• Badilisha ukubwa wa nje ya mtandao kwa diski (Yandex.Cloud usiunge mkono kuongeza diski ambazo zimewekwa kwenye mashine ya kawaida). Kwa habari juu ya jinsi dereva alilazimika kurekebishwa ili kufanya ukubwa wa saizi usiwe na uchungu iwezekanavyo, tazama hapa chini.

Katika siku zijazo, tunapanga kutekeleza usaidizi wa kuunda na kufuta snapshots za disk.

Ugumu kuu na jinsi ya kuondokana nayo

Ukosefu wa uwezo wa kuongeza diski kwa wakati halisi katika Yandex.Cloud API ni kizuizi ambacho kinachanganya operesheni ya kurekebisha ukubwa wa PV (Volume inayoendelea): katika kesi hii, ni muhimu kwamba pod ya maombi inayotumia diski ikomeshwe, na hii inaweza kusababisha utumizi wa muda wa chini.

Kulingana na Vipimo vya CSI, ikiwa kidhibiti cha CSI kinaripoti kwamba kinaweza kubadilisha ukubwa wa diski "nje ya mtandao" pekee (VolumeExpansion.OFFLINE), basi mchakato wa kuongeza diski unapaswa kwenda kama hii:

Ikiwa programu-jalizi ina tu VolumeExpansion.OFFLINE uwezo wa upanuzi na kiasi kinachapishwa kwa sasa au kinapatikana kwenye nodi basi ControllerExpandVolume LAZIMA ipigwe TU baada ya mojawapo:

• Programu-jalizi ina kidhibiti PUBLISH_UNPUBLISH_VOLUME uwezo na ControllerUnpublishVolume imeombwa kwa mafanikio.

AU VINGINEVYO

• Programu-jalizi HAINA kidhibiti PUBLISH_UNPUBLISH_VOLUME uwezo, programu-jalizi ina nodi STAGE_UNSTAGE_VOLUME uwezo, na NodeUnstageVolume imekamilika kwa mafanikio.

AU VINGINEVYO

• Programu-jalizi HAINA kidhibiti PUBLISH_UNPUBLISH_VOLUME uwezo, wala nodi STAGE_UNSTAGE_VOLUME uwezo, na NodeUnpublishVolume imekamilika kwa mafanikio.

Hii inamaanisha kuwa unahitaji kuondoa diski kutoka kwa mashine ya kawaida kabla ya kuipanua.

Hata hivyo, kwa bahati mbaya utekelezaji Vipimo vya CSI kupitia kando havikidhi mahitaji haya:

• Katika chombo cha kando csi-attacher, ambayo inapaswa kuwajibika kwa uwepo wa pengo linalohitajika kati ya vipandikizi, utendakazi huu hautekelezwi katika urekebishaji wa ukubwa wa nje ya mtandao. Majadiliano kuhusu hili yalianzishwa hapa.
• Chombo cha kando ni nini hasa katika muktadha huu? Programu-jalizi ya CSI yenyewe haiingiliani na API ya Kubernetes, lakini hujibu tu simu za gRPC zinazotumwa kwake na vyombo vya kando. Karibuni zinaendelezwa na jumuiya ya Kubernetes.

Kwa upande wetu (Plugin ya CSI), operesheni ya kuongeza diski inaonekana kama hii:

1. Tunapokea simu ya gRPC ControllerExpandVolume;
2. Tunajaribu kuongeza disk katika API, lakini tunapokea kosa kuhusu kutowezekana kwa kufanya operesheni kwa sababu disk imewekwa;
3. Tunahifadhi kitambulisho cha diski kwenye ramani iliyo na diski ambazo operesheni ya ongezeko inahitaji kufanywa. Hapo chini, kwa ufupi, tutaita ramani hii kama volumeResizeRequired;
4. Ondoa kwa mikono ganda ambalo linatumia diski. Kubernetes itawasha upya. Ili diski haina wakati wa kuweka (ControllerPublishVolume) kabla ya kukamilisha operesheni ya ongezeko wakati wa kujaribu kuweka, tunaangalia kwamba diski iliyotolewa bado iko volumeResizeRequired na kurudisha kosa;
5. Kiendeshaji cha CSI kinajaribu kutekeleza tena utendakazi wa kubadilisha ukubwa. Ikiwa operesheni ilifanikiwa, kisha uondoe diski kutoka volumeResizeRequired;
6. Kwa sababu Kitambulisho cha diski hakipo volumeResizeRequired, ControllerPublishVolume hupita kwa mafanikio, diski imewekwa, pod huanza.

Kila kitu kinaonekana rahisi vya kutosha, lakini kama kawaida kuna mitego. Hupanua diski nje-resizer, ambayo katika kesi ya hitilafu wakati wa operesheni hutumia foleni na ongezeko kubwa la muda wa kuisha hadi sekunde 1000:

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

Hii inaweza kusababisha mara kwa mara upanuzi wa upanuzi wa diski kwa dakika 15+ na, kwa hivyo, ganda linalolingana halipatikani.

Chaguo pekee ambalo lilituruhusu kwa urahisi na bila uchungu kupunguza muda unaowezekana ni matumizi ya toleo letu la kiboreshaji cha nje chenye kikomo cha juu zaidi cha kuisha. katika sekunde 5:

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

Hatukuona kuwa ni muhimu kuanzisha mjadala kwa haraka na kuweka kiraka cha kurekebisha ukubwa wa nje ya mtandao, kwa sababu kubadilisha ukubwa wa diski nje ya mtandao ni urejesho ambao utatoweka hivi karibuni kutoka kwa watoa huduma wote wa mtandao.

Jinsi ya kuanza kutumia?

Kiendeshaji kinatumika kwenye toleo la Kubernetes 1.15 na matoleo mapya zaidi. Ili dereva afanye kazi, mahitaji yafuatayo lazima yatimizwe:

• Bendera --allow-privileged kuweka kwa thamani true kwa seva ya API na kubelet;
• Imejumuishwa --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true kwa seva ya API na kubelet;
• Uenezi wa mlima (uenezi wa mlima) lazima kuwezeshwa kwenye nguzo. Unapotumia Docker, daemoni lazima isanidiwe ili kuruhusu vipandikizi vilivyoshirikiwa.

Hatua zote muhimu kwa ajili ya ufungaji yenyewe ilivyoelezwa katika README. Ufungaji unahusisha kuunda vitu katika Kubernetes kutoka kwa maonyesho.

Ili dereva afanye kazi utahitaji zifuatazo:

• Bainisha kitambulisho cha saraka kwenye faili ya maelezo (folder-id) Yandex.Cloud (tazama nyaraka);
• Ili kuingiliana na Yandex.Cloud API, dereva wa CSI hutumia akaunti ya huduma. Katika faili ya maelezo, Siri lazima ipitishwe funguo zilizoidhinishwa kutoka kwa akaunti ya huduma. Katika nyaraka ilivyoelezwa, jinsi ya kuunda akaunti ya huduma na kupata funguo.

Yote kwa yote - jaribu, na tutafurahi kupokea maoni na masuala mapyaukikutana na matatizo yoyote!

Msaada zaidi

Kwa hivyo, tungependa kutambua kwamba tulitekeleza kiendeshi hiki cha CSI si kwa hamu kubwa ya kufurahia kuandika maombi katika Go, lakini kwa sababu ya hitaji la dharura ndani ya kampuni. Haionekani kuwa ya vitendo kwetu kudumisha utekelezaji wetu wenyewe, kwa hivyo ikiwa Yandex itaonyesha kupendezwa na kuamua kuendelea kusaidia dereva, tutafurahi kuhamisha hazina kwao.

Kwa kuongeza, Yandex labda ina utekelezaji wake wa dereva wa CSI katika nguzo yake ya Kubernetes iliyosimamiwa, ambayo inaweza kutolewa katika Open Source. Pia tunaona chaguo hili la usanidi kuwa zuri - jumuiya itaweza kutumia kiendeshi kilichothibitishwa kutoka kwa mtoa huduma, na si kutoka kwa kampuni nyingine.

PS

Soma pia kwenye blogi yetu:

• «Programu jalizi za kiasi kwa hifadhi ya Kubernetes: kutoka Flexvolume hadi CSI";
• «Tunaelewa Kiolesura cha Kuhifadhi Kontena (huko Kubernetes na sio tu)";
• «Je, ni rahisi na rahisi kuandaa nguzo ya Kubernetes? Inatangaza kiendeshaji cha kuongeza";
• «Kupanua na kukamilisha Kubernetes (hakiki na ripoti ya video)'.

Chanzo: mapenzi.com