ProHoster > Օրագիր > Վարչակազմը > Yandex.Cloud-ի համար Kubernetes-ում CSI դրայվեր մշակելու մեր փորձը

Yandex.Cloud-ի համար Kubernetes-ում CSI դրայվեր մշակելու մեր փորձը

Yandex.Cloud-ի համար Kubernetes-ում CSI դրայվեր մշակելու մեր փորձը

Ուրախ ենք տեղեկացնել, որ Flant-ը ընդլայնում է իր ներդրումը Kubernetes-ի բաց կոդով գործիքներում՝ թողարկելով CSI վարորդի ալֆա տարբերակը (Container Storage Interface) Yandex.Cloud-ի համար:

Բայց նախքան իրականացման մանրամասներին անցնելը, եկեք պատասխանենք այն հարցին, թե ինչու է դա ընդհանրապես անհրաժեշտ, երբ Yandex-ն արդեն ունի ծառայություն: Կառավարվող ծառայություն Kubernetes-ի համար.

Ներածություն

Ինչու սա?

Մեր ընկերության ներսում, Kubernetes-ի արտադրության մեջ օգտագործելու հենց սկզբից (այսինքն արդեն մի քանի տարի) մենք մշակում ենք մեր սեփական գործիքը (deckhouse), որը, ի դեպ, նախատեսում ենք նաև շուտով հասանելի դարձնել որպես բաց կոդով նախագիծ։ . Նրա օգնությամբ մենք միատեսակ կազմաձևում և կազմաձևում ենք մեր բոլոր կլաստերները, և ներկայումս դրանցից ավելի քան 100-ը՝ ապարատային կոնֆիգուրացիաների լայն տեսականիով և բոլոր հասանելի ամպային ծառայություններում:

Կլաստերները, որոնք օգտագործում են տախտակամածը, ունեն շահագործման համար անհրաժեշտ բոլոր բաղադրիչները՝ հավասարակշռողներ, մոնիտորինգ հարմար գծապատկերներով, չափումներ և ազդանշաններ, օգտատերերի նույնականացում արտաքին պրովայդերների միջոցով՝ բոլոր վահանակների մուտքի համար և այլն: Նման «պոմպացված» կլաստերի տեղադրումը կառավարվող լուծույթում իմաստ չունի, քանի որ դա հաճախ կամ անհնար է կամ կհանգեցնի բաղադրիչների կեսն անջատելու անհրաժեշտությանը:

NBՍա մեր փորձն է, և այն բավականին կոնկրետ է: Մենք ոչ մի կերպ չենք առաջարկում, որ յուրաքանչյուրը պետք է ինքնուրույն տեղակայի Kubernetes կլաստերները՝ պատրաստի լուծումներ օգտագործելու փոխարեն: Ի դեպ, մենք Yandex-ից Kubernetes-ի շահագործման իրական փորձ չունենք, և այս հոդվածում որևէ գնահատական ​​չենք տա այս ծառայությանը:

Ի՞նչ է դա և ո՞ւմ համար:

Այսպիսով, մենք արդեն խոսել ենք Kubernetes-ում պահեստավորման ժամանակակից մոտեցման մասին. ինչպես է աշխատում CSI-ն: и ինչպես եկավ համայնքը այս մոտեցմանը:

Ներկայումս շատ խոշոր ամպային ծառայություններ մատուցողներ մշակել են վարորդներ՝ իրենց ամպային սկավառակներն օգտագործելու համար որպես մշտական ​​ձայն Kubernetes-ում: Եթե ​​մատակարարը չունի նման դրայվեր, բայց բոլոր անհրաժեշտ գործառույթներն ապահովված են API-ի միջոցով, ապա ոչինչ չի խանգարում ձեզ ինքներդ ներդնել դրայվերը։ Ահա թե ինչ եղավ Yandex.Cloud-ի հետ:

Մենք հիմք ենք ընդունել զարգացման համար CSI վարորդ DigitalOcean ամպի համար և մի քանի գաղափար վարորդներ GCP-ի համար, քանի որ այս ամպերի (Google և Yandex) API-ի հետ փոխազդեցությունն ունի մի շարք նմանություններ։ Մասնավորապես, API-ն և GCP, և ժամը Yandex վերադարձնել օբյեկտ Operation հետևելու երկարատև գործողությունների կարգավիճակին (օրինակ, նոր սկավառակի ստեղծում): Yandex.Cloud API-ի հետ փոխազդելու համար օգտագործեք Yandex.Cloud Go SDK.

Կատարված աշխատանքի արդյունքը հրապարակված GitHub-ում և կարող է օգտակար լինել նրանց համար, ովքեր ինչ-ինչ պատճառներով օգտագործում են իրենց սեփական Kubernetes տեղադրումը Yandex.Cloud վիրտուալ մեքենաներում (բայց ոչ պատրաստի կառավարվող կլաստեր) և ցանկանում են օգտագործել (պատվիրել) սկավառակներ CSI-ի միջոցով:

Իրականացման

Հիմնական հատկանիշները

Ներկայումս վարորդը աջակցում է հետևյալ գործառույթները.

  • Կլաստերի բոլոր գոտիներում սկավառակների դասակարգում ըստ կլաստերի հանգույցների տոպոլոգիայի.
  • Նախկինում պատվիրված սկավառակների հեռացում;
  • Սկավառակների համար անցանց չափափոխում (Yandex.Cloud չեն աջակցում ավելացնելով սկավառակները, որոնք տեղադրված են վիրտուալ մեքենայի վրա): Տեղեկությունների համար, թե ինչպես պետք է վարորդը փոփոխվեր, որպեսզի չափափոխումը հնարավորինս ցավ չպատճառի, տե՛ս ստորև:

Ապագայում մենք նախատեսում ենք աջակցություն ներդնել սկավառակի նկարների ստեղծման և ջնջման համար:

Հիմնական դժվարությունը և ինչպես հաղթահարել այն

Yandex.Cloud API-ում սկավառակները իրական ժամանակում մեծացնելու հնարավորության բացակայությունը սահմանափակում է, որը բարդացնում է PV-ի (մշտական ​​ծավալի) չափափոխման գործողությունը. և դա կարող է առաջացնել ընդհատման հավելվածներ:

Ըստ CSI բնութագրերը, եթե CSI վերահսկիչը հայտնում է, որ այն կարող է փոխել սկավառակների չափերը միայն «անցանց» (VolumeExpansion.OFFLINE), ապա սկավառակի ավելացման գործընթացը պետք է գնա այսպես.

Եթե ​​plugin-ն ունի միայն VolumeExpansion.OFFLINE Ընդլայնման հնարավորությունը և ծավալը ներկայումս հրապարակվում են կամ հասանելի են հանգույցի վրա ControllerExpandVolume ՊԵՏՔ Է զանգահարել ՄԻԱՅՆ այն բանից հետո, երբ.

  • Փլագինը ունի վերահսկիչ PUBLISH_UNPUBLISH_VOLUME կարողություն և ControllerUnpublishVolume հաջողությամբ կանչվել է:

ԱՅԼԱՊԵՍ

  • Փլագինը կարգավորիչ չունի PUBLISH_UNPUBLISH_VOLUME հնարավորություն, plugin-ն ունի հանգույց STAGE_UNSTAGE_VOLUME կարողություն, և NodeUnstageVolume հաջողությամբ ավարտվել է:

ԱՅԼԱՊԵՍ

  • Փլագինը կարգավորիչ չունի PUBLISH_UNPUBLISH_VOLUME կարողություն, ոչ էլ հանգույց STAGE_UNSTAGE_VOLUME կարողություն, և NodeUnpublishVolume հաջողությամբ ավարտվել է:

Սա, ըստ էության, նշանակում է, որ նախքան այն ընդլայնելը, դուք պետք է անջատեք սկավառակը վիրտուալ մեքենայից:

Այնուամենայնիվ, ցավոք իրականացումը CSI-ի սպեցիֆիկացիան կողային սայլերի միջոցով չի համապատասխանում այս պահանջներին.

  • Կողքի կոնտեյներով csi-attacher, որը պետք է պատասխանատու լինի մոնտաժների միջև անհրաժեշտ բացվածքի առկայության համար, այս ֆունկցիոնալությունը պարզապես չի իրականացվում օֆլայն չափափոխման մեջ: Այս մասին քննարկում է սկսվել այստեղ.
  • Այս համատեքստում կոնկրետ ի՞նչ է իրենից ներկայացնում կողային բեռնարկղը: CSI plugin-ն ինքնին չի փոխազդում Kubernetes API-ի հետ, այլ միայն արձագանքում է gRPC զանգերին, որոնք նրան ուղարկվում են կողային բեռնարկղերի միջոցով: Վերջին մշակվում են Կուբերնետես համայնքի կողմից։

Մեր դեպքում (CSI plugin) սկավառակի ավելացման գործողությունը հետևյալն է.

  1. Մենք ստանում ենք gRPC զանգ ControllerExpandVolume;
  2. Մենք փորձում ենք մեծացնել սկավառակը API-ում, բայց մենք սխալ ենք ստանում գործողությունը կատարելու անհնարինության մասին, քանի որ սկավառակը տեղադրված է.
  3. Մենք պահում ենք սկավառակի նույնացուցիչը քարտեզում, որը պարունակում է սկավառակներ, որոնց համար պետք է կատարվի ավելացման գործողությունը: Ստորև, հակիրճ լինելու համար, մենք այս քարտեզը կանվանենք այսպես volumeResizeRequired;
  4. Ձեռքով հեռացրեք սկավառակը օգտագործող պատյան: Kubernetes-ը կվերագործարկի այն: Որպեսզի սկավառակը ժամանակ չունենա տեղադրելու (ControllerPublishVolume) բարձրացման գործողությունն ավարտելուց առաջ, երբ փորձում ենք մոնտաժել, մենք ստուգում ենք, որ տվյալ սկավառակը դեռ գտնվում է volumeResizeRequired և վերադարձնել սխալ;
  5. CSI վարորդը փորձում է կրկին կատարել չափափոխման գործողությունը: Եթե ​​գործողությունը հաջող էր, ապա հեռացրեք սկավառակը volumeResizeRequired;
  6. Որովհետեւ Սկավառակի ID-ն բացակայում է volumeResizeRequired, ControllerPublishVolume հաջողությամբ անցնում, սկավառակը տեղադրվում է, պատիճը սկսվում է:

Ամեն ինչ բավականին պարզ է թվում, բայց ինչպես միշտ կան որոգայթներ: Մեծացնում է սկավառակները արտաքին չափափոխիչ, որը շահագործման ընթացքում սխալի դեպքում օգտագործում է հերթ մինչև 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)},
  )
}

Դա կարող է հանգեցնել նրան, որ սկավառակի ընդլայնման գործողությունը պարբերաբար երկարաձգվի 15+ րոպեով և, հետևաբար, համապատասխան պատիճը անհասանելի լինի:

Միակ տարբերակը, որը բավականին հեշտությամբ և ցավազուրկ թույլ տվեց մեզ նվազեցնել պոտենցիալ խափանումը, դա արտաքին չափափոխիչի մեր տարբերակի օգտագործումն էր առավելագույն ժամանակի սահմանափակումով: 5 վայրկյանում:

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

Մենք հարկ չհամարեցինք շտապ քննարկում սկսել և կարկատել արտաքին չափափոխիչը, քանի որ սկավառակների օֆլայն չափափոխումը վերադարձ է, որը շուտով կվերանա բոլոր ամպային պրովայդերներից:

Ինչպե՞ս սկսել օգտագործել այն:

Վարորդը աջակցվում է Kubernetes 1.15 և ավելի բարձր տարբերակում: Վարորդի աշխատանքի համար պետք է բավարարվեն հետևյալ պահանջները.

  • Դրոշ --allow-privileged սահմանել արժեքը true API սերվերի և kubelet-ի համար;
  • Ներառված է --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API սերվերի և kubelet-ի համար;
  • Լեռան տարածում (լեռների տարածում) պետք է միացված լինի կլաստերի վրա: Docker-ն օգտագործելիս դեյմոնը պետք է կազմաձևվի այնպես, որ թույլ տա ընդհանուր ամրացումներ:

Ինքնին տեղադրման համար անհրաժեշտ բոլոր քայլերը նկարագրված է README-ում. Տեղադրումը ներառում է Kubernetes-ում օբյեկտների ստեղծում մանիֆեստներից:

Որպեսզի վարորդը աշխատի, ձեզ հարկավոր է հետևյալը.

  • Նշեք գրացուցակի նույնացուցիչը մանիֆեստում (folder-id) Yandex.Cloud (տես փաստաթղթերը);
  • Yandex.Cloud API-ի հետ փոխգործակցելու համար CSI վարորդը օգտագործում է ծառայության հաշիվ: Գաղտնի մանիֆեստում դուք պետք է անցնեք լիազորված բանալիներ ծառայության հաշվից: Փաստաթղթերում նկարագրված է, ինչպես ստեղծել ծառայության հաշիվ և ստանալ բանալիներ:

Վերջիվերջո - փորձեք, և մենք ուրախ կլինենք ստանալ արձագանքներ և նոր հարցերեթե որևէ խնդրի հանդիպեք!

Հետագա աջակցություն

Արդյունքում ցանկանում ենք նշել, որ մենք ներդրել ենք այս CSI դրայվերը ոչ թե Go-ում հավելվածներ գրելով զվարճանալու մեծ ցանկությամբ, այլ ընկերության ներսում հրատապ անհրաժեշտության պատճառով: Մեզ համար գործնական չի թվում պահպանել մեր սեփական ներդրումը, ուստի, եթե Yandex-ը հետաքրքրություն ցուցաբերի և որոշի շարունակել աջակցել վարորդին, մենք ուրախ կլինենք փոխանցել պահեստը նրանց:

Բացի այդ, Yandex-ը, հավանաբար, ունի CSI դրայվերի սեփական ներդրումը իր կառավարվող Kubernetes կլաստերում, որը կարող է թողարկվել բաց կոդով: Մենք նաև տեսնում ենք զարգացման այս տարբերակը որպես բարենպաստ. համայնքը կկարողանա օգտագործել ապացուցված դրայվեր ծառայություններ մատուցողից, այլ ոչ թե երրորդ կողմի ընկերություններից:

PS

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Добавить комментарий