Տվյալների պահպանման օրինաչափություններ Kubernetes-ում

Հե՜յ Հաբր։

Հիշեցնենք, որ թողարկել ենք ևս մեկ անչափ հետաքրքիր և օգտակար книга Kubernetes-ի նախշերի մասին. Ամեն ինչ սկսվեց «Նախշեր«Բրենդան Բերնսը, և, ի դեպ, մենք աշխատանք ունենք այս հատվածում եռում է. Այսօր մենք ձեզ հրավիրում ենք կարդալ MinIO բլոգից մի հոդված, որը հակիրճ ուրվագծում է Kubernetes-ում տվյալների պահպանման օրինաչափությունների միտումներն ու առանձնահատկությունները:

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

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

Քանի որ Kubernetes-ի օգտագործումը մեծանում է, այնքան խառնաշփոթ է ավելանում դրա պահպանման ձևերի վերաբերյալ:.

Երբ բոլորը մրցում են Kubernetes-ի կարկանդակի մի կտորի համար (այսինքն՝ տվյալների պահպանման), երբ խոսքը վերաբերում է տվյալների պահպանման մասին, ազդանշանը խեղդվում է մեծ աղմուկի մեջ:
Kubernetes-ը մարմնավորում է հավելվածների մշակման, տեղակայման և կառավարման ժամանակակից մոդել: Այս ժամանակակից մոդելը անջատում է տվյալների պահպանումը հաշվարկից: Kubernetes-ի համատեքստում անջատումը լիովին հասկանալու համար դուք նաև պետք է հասկանաք, թե ինչ են պետական ​​և քաղաքացիություն չունեցող հավելվածները, և ինչպես է տվյալների պահպանումը տեղավորվում դրա մեջ: Այստեղ է, որ S3-ի կողմից օգտագործվող REST API մոտեցումը հստակ առավելություններ ունի այլ լուծումների POSIX/CSI մոտեցման նկատմամբ:

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

Քաղաքացիություն չունեցող կոնտեյներներ

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

Պետական ​​կոնտեյներներ

Եթե ​​բեռնարկղը տվյալներ է պահում տեղական կցված սարքերի վրա (կամ բլոկ սարքի վրա), ապա տվյալների պահեստը, որի վրա այն գտնվում է, պետք է տեղափոխվի նոր հանգույց՝ բուն կոնտեյների հետ միասին՝ խափանման դեպքում: Սա կարևոր է, քանի որ հակառակ դեպքում կոնտեյներով աշխատող հավելվածը չի կարողանա ճիշտ աշխատել, քանի որ անհրաժեշտ է մուտք գործել տեղական լրատվամիջոցներում պահվող տվյալներ: Ասում են, որ նման տարաներն աշխատում են պետական.

Զուտ տեխնիկական տեսանկյունից պետական ​​կոնտեյներները կարող են տեղափոխվել նաև այլ հանգույցներ։ Սա սովորաբար ձեռք է բերվում բաշխված ֆայլային համակարգերի միջոցով կամ արգելափակել ցանցային պահեստը, որը կցված է բոլոր հանգույցներին, որոնք աշխատում են բեռնարկղերում: Այս կերպ կոնտեյներները մուտք են գործում տվյալների մշտական ​​պահպանման ծավալներ, և տեղեկատվությունը պահվում է ցանցում տեղակայված սկավառակների վրա: Ես այս մեթոդը կանվանեմ «պետական ​​կոնտեյներային մոտեցում», իսկ հոդվածի մնացած մասում ես դա կկոչեմ միօրինակության համար։

Տիպիկ վիճակագրական կոնտեյների մոտեցման դեպքում բոլոր հավելվածների պատյանները կցվում են մեկ բաշխված ֆայլային համակարգին՝ մի տեսակ ընդհանուր պահեստ, որտեղ գտնվում են հավելվածի բոլոր տվյալները: Թեև հնարավոր են որոշ տատանումներ, սա բարձր մակարդակի մոտեցում է:

Հիմա եկեք նայենք, թե ինչու է պետական ​​կոնտեյներային մոտեցումը հակաօրինաչափություն ամպակենտրոն աշխարհում:

Cloud-native հավելվածի ձևավորում

Ավանդաբար, հավելվածներն օգտագործում էին տվյալների բազաներ՝ տեղեկատվության կառուցվածքային պահպանման և տեղային սկավառակների կամ բաշխված ֆայլային համակարգերի համար, որտեղ բոլոր չկառուցված կամ նույնիսկ կիսակառույց տվյալները թափվում էին: Քանի որ չկառուցված տվյալների ծավալները մեծանում էին, մշակողները հասկացան, որ POSIX-ը չափազանց խոսակցական էր, ուներ զգալի ծախսեր և, ի վերջո, խոչընդոտում էր հավելվածի աշխատանքին իսկապես մեծ մասշտաբների անցնելու ժամանակ:

Սա հիմնականում նպաստեց տվյալների պահպանման նոր ստանդարտի առաջացմանը, այն է՝ ամպի վրա հիմնված պահեստավորումը, որն աշխատում է հիմնականում REST API-ի վրա և ազատում հավելվածը տեղական տվյալների պահպանման ծանրաբեռնվածությունից: Այս դեպքում հավելվածն արդյունավետորեն անցնում է քաղաքացիություն չունեցող ռեժիմի (քանի որ վիճակը գտնվում է հեռավոր պահեստում): Ժամանակակից հավելվածները կառուցված են զրոյից՝ հաշվի առնելով այս գործոնը: Որպես կանոն, ցանկացած ժամանակակից հավելված, որը մշակում է այս կամ այն ​​տեսակի տվյալներ (տեղեկամատյաններ, մետատվյալներ, բլբեր և այլն) կառուցվում է ամպի վրա հիմնված պարադիգմի համաձայն, որտեղ վիճակը փոխանցվում է հատուկ դրա պահպանման համար նախատեսված ծրագրային համակարգին:

Պետական ​​կոնտեյներային մոտեցումը ստիպում է այս ամբողջ պարադիգմը վերադառնալ հենց այնտեղ, որտեղ սկսվել է:

Օգտագործելով POSIX ինտերֆեյսները տվյալների պահպանման համար, հավելվածները գործում են այնպես, ասես պետական ​​լինեն, և այդ պատճառով նրանք հեռանում են ամպակենտրոն դիզայնի ամենակարևոր սկզբունքներից, այսինքն՝ հավելվածի աշխատող թելերի չափը փոխելու հնարավորությունից՝ կախված մուտքից։ մուտքագրում, բեռնում, տեղափոխվում է նոր հանգույց, հենց որ ընթացիկ հանգույցը ձախողվի և այլն:

Ավելի մոտիկից նայելով այս իրավիճակին՝ մենք պարզում ենք, որ տվյալների պահեստ ընտրելիս մենք կրկին ու կրկին բախվում ենք POSIX-ի ընդդեմ REST API-ի երկընտրանքի, ԲԱՅՑ POSIX-ի խնդիրների լրացուցիչ սրման՝ Kubernetes միջավայրերի բաշխված բնույթի պատճառով: Մասնավորապես,

• POSIX-ը շատախոս էPOSIX իմաստաբանությունը պահանջում է, որ յուրաքանչյուր գործողություն կապված լինի մետատվյալների և ֆայլերի նկարագրիչների հետ, որոնք օգնում են պահպանել գործողության վիճակը: Սա հանգեցնում է զգալի ծախսերի, որոնք իրական արժեք չունեն: Օբյեկտների պահպանման API-ները, մասնավորապես S3 API-ն, ազատվում են այս պահանջներից՝ թույլ տալով հավելվածին գործարկել, իսկ հետո «մոռանալ» զանգի մասին: Պահպանման համակարգի պատասխանը ցույց է տալիս՝ գործողությունը հաջող էր, թե ոչ: Եթե ​​այն ձախողվի, հավելվածը կարող է նորից փորձել:
• Ցանցի սահմանափակումներԲաշխված համակարգում ենթադրվում է, որ կարող են լինել բազմաթիվ հավելվածներ, որոնք փորձում են տվյալներ գրել նույն կցված կրիչի վրա: Հետևաբար, ոչ միայն հավելվածները միմյանց հետ կմրցեն տվյալների փոխանցման թողունակության համար (տվյալներ լրատվամիջոցներին ուղարկելու համար), այլ նաև պահեստավորման համակարգն ինքը կմրցի այս թողունակության համար՝ տվյալներ ուղարկելով ֆիզիկական սկավառակներով: POSIX-ի պարզունակության պատճառով ցանցային զանգերի թիվը մի քանի անգամ ավելանում է: Մյուս կողմից, S3 API-ն հստակ տարբերակում է ցանցային զանգերի միջև, որոնք ծագում են հաճախորդից դեպի սերվեր և նրանց միջև, որոնք տեղի են ունենում սերվերի ներսում:
• БезопасностьPOSIX անվտանգության մոդելը նախատեսված է ակտիվ մարդկային մասնակցության համար. ադմինիստրատորները կարգավորում են մուտքի հատուկ մակարդակներ յուրաքանչյուր օգտագործողի կամ խմբի համար: Այս պարադիգմը դժվար է հարմարվել ամպակենտրոն աշխարհին: Ժամանակակից հավելվածները կախված են API-ի վրա հիմնված անվտանգության մոդելներից, որտեղ մուտքի իրավունքները սահմանվում են որպես քաղաքականության մի շարք, հատկացվում են ծառայության հաշիվներ, ժամանակավոր հավատարմագրեր և այլն:
• ԿառավարելիությունՊետական ​​բեռնարկղերը որոշակի կառավարման ծախսեր ունեն: Մենք խոսում ենք տվյալների զուգահեռ հասանելիության համաժամացման, տվյալների հետևողականության ապահովման մասին, այս ամենը պահանջում է մանրակրկիտ քննարկում, թե տվյալների հասանելիության որ օրինաչափություններն օգտագործել: Լրացուցիչ ծրագրակազմը պետք է տեղադրվի, մոնիտորինգի ենթարկվի և կազմաձևվի, էլ չեմ խոսում զարգացման լրացուցիչ ջանքերի մասին:

Կոնտեյների տվյալների պահպանման ինտերֆեյս

Թեև բեռնարկղերի պահպանման ինտերֆեյսը (CSI) մեծ օգնություն է ցուցաբերել Kubernetes ծավալային շերտի տարածման հարցում՝ մասնակիորեն փոխանցելով այն երրորդ կողմի պահեստավորման վաճառողներին, այն նաև ակամա նպաստել է այն համոզմանը, որ կոնտեյների վիճակի մոտեցումը առաջարկվող մեթոդ է: տվյալների պահպանում Kubernetes-ում:

CSI-ն մշակվել է որպես ստանդարտ՝ Կուբերնետեսում աշխատելիս հին հավելվածներին կամայական բլոկների և ֆայլերի պահպանման համակարգեր տրամադրելու համար: Եվ, ինչպես ցույց է տվել այս հոդվածը, միակ իրավիճակը, երբ պետական ​​կոնտեյների մոտեցումը (և CSI-ն իր ներկայիս տեսքով) իմաստ ունի, այն է, երբ հավելվածն ինքնին ժառանգական համակարգ է, որտեղ հնարավոր չէ աջակցություն ավելացնել օբյեկտների պահպանման API-ին: .

Կարևոր է հասկանալ, որ օգտագործելով CSI-ն իր ներկայիս ձևով, այսինքն՝ ծավալների մոնտաժում ժամանակակից հավելվածների հետ աշխատելիս, մենք կհանդիպենք մոտավորապես նույն խնդիրների, որոնք առաջացել են համակարգերում, որտեղ տվյալների պահպանումը կազմակերպված է POSIX ոճով:

Ավելի լավ մոտեցում

Այս դեպքում կարևոր է հասկանալ, որ դիմումների մեծ մասը ի սկզբանե նախատեսված չէ հատուկ պետական ​​կամ քաղաքացիություն չունեցող աշխատանքի համար: Այս վարքագիծը կախված է համակարգի ընդհանուր ճարտարապետությունից և կատարված նախագծման կոնկրետ ընտրությունից: Մի փոքր խոսենք պետական ​​հայտերի մասին։

Սկզբունքորեն, դիմումի բոլոր տվյալները կարելի է բաժանել մի քանի լայն տեսակների.

• Մատյան տվյալներ
• Ժամացույցի տվյալներ
• Գործարքի տվյալներ
• Մետատվյալներ
• Կոնտեյների պատկերներ
• Blob (երկուական խոշոր օբյեկտ) տվյալներ

Տվյալների այս բոլոր տեսակները շատ լավ աջակցվում են ժամանակակից պահեստային հարթակներում, և կան մի քանի ամպային բնիկ հարթակներ, որոնք հարմարեցված են տվյալներ փոխանցելու այս հատուկ ձևաչափերից յուրաքանչյուրում: Օրինակ, գործարքների տվյալները և մետատվյալները կարող են տեղակայվել ժամանակակից ամպային տվյալների բազայում, ինչպիսիք են CockroachDB, YugaByte և այլն: Կոնտեյների պատկերները կամ բլբի տվյալները կարող են պահվել MinIO-ի վրա հիմնված դոկերի ռեեստրում: Ժամացույցի տվյալները կարող են պահվել ժամանակային շարքերի տվյալների բազայում, ինչպիսիք են InfluxDB և այլն: Այստեղ մենք չենք մանրամասնի տվյալների յուրաքանչյուր տեսակի և դրա հետ կապված հավելվածների մասին, սակայն ընդհանուր գաղափարն այն է, որ խուսափենք տվյալների մշտական ​​պահպանումից, որը հիմնված է սկավառակի տեղային տեղադրման վրա:

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

Պետական ​​հայտի պահեստավորում

Թեև շատ դեպքերում օգտակար է հավելվածները պահել առանց քաղաքացիության, այն հավելվածները, որոնք նախատեսված են տվյալներ պահելու համար, ինչպիսիք են տվյալների բազաները, օբյեկտների պահեստները, բանալիների արժեքի պահեստները, պետք է լինեն պետական: Եկեք նայենք, թե ինչու են այս հավելվածները տեղակայվում Kubernetes-ում: Եկեք որպես օրինակ վերցնենք MinIO-ն, սակայն նմանատիպ սկզբունքները կիրառվում են ցանկացած այլ խոշոր ամպային բնիկ պահեստավորման համակարգի համար:

Cloud-ի բնիկ հավելվածները նախատեսված են բեռնարկղերին բնորոշ ճկունությունից լիարժեք օգտվելու համար: Սա նշանակում է, որ նրանք ոչ մի ենթադրություն չեն անում այն ​​միջավայրի մասին, որտեղ կտեղակայվեն: Օրինակ, MinIO-ն օգտագործում է ջնջման ներքին կոդավորման մեխանիզմ, որպեսզի համակարգը ապահովի բավականաչափ ճկունություն, որպեսզի մնա գործառնական, նույնիսկ եթե սկավառակների կեսը ձախողվի: MinIO-ն նաև կառավարում է տվյալների ամբողջականությունն ու անվտանգությունը՝ օգտագործելով սեփական սերվերի կողմից հեշինգ և գաղտնագրում:

Նման ամպի վրա կենտրոնացած հավելվածների համար տեղական կայուն ծավալները (PV) առավել հարմար են որպես պահեստային պահեստ: Տեղական PV-ն ապահովում է չմշակված տվյալներ պահելու հնարավորություն, մինչդեռ այս ՖՎ-ների վերևում աշխատող հավելվածներն ինքնուրույն հավաքում են տեղեկատվություն՝ տվյալների չափման և աճող տվյալների պահանջները կառավարելու համար:

Այս մոտեցումը շատ ավելի պարզ է և զգալիորեն ավելի լայնածավալ, քան CSI-ի վրա հիմնված ՖՎ-ները, որոնք համակարգ են ներմուծում տվյալների կառավարման և ավելորդության իրենց շերտերը. Բանն այն է, որ այս շերտերը սովորաբար հակասում են պետական ​​լինելու համար նախատեսված հավելվածներին:

Ուժեղ շարժում՝ ուղղված հաշվարկներից տվյալների անջատմանը

Այս հոդվածում մենք խոսեցինք այն մասին, թե ինչպես են հավելվածները վերակողմնորոշվում աշխատելու՝ առանց վիճակի պահպանման, կամ, այլ կերպ ասած, տվյալների պահպանումն անջատվում է դրանց վրա հաշվելուց: Եզրափակելով, եկեք նայենք այս միտումի իրական օրինակներին:

Կայծ, տվյալների վերլուծության նշանավոր հարթակ, ավանդաբար եղել է պետական ​​և տեղակայվել HDFS-ում: Այնուամենայնիվ, քանի որ Spark-ը շարժվում է դեպի ամպակենտրոն աշխարհ, հարթակը գնալով ավելի է օգտագործվում առանց քաղաքացիության՝ օգտագործելով «s3a»: Spark-ն օգտագործում է s3a վիճակը այլ համակարգերի փոխանցելու համար, մինչդեռ Spark կոնտեյներներն իրենք գործում են ամբողջովին առանց քաղաքացիության: Մեծ տվյալների վերլուծության ոլորտում ձեռնարկությունների այլ խոշոր խաղացողներ, մասնավորապես, Vertica, Տերադատա, Greenplum Նրանք նաև աշխատանքի են անցնում տվյալների պահպանման և դրանց վրա հաշվարկների տարանջատման հետ:

Նմանատիպ օրինաչափություններ կարելի է տեսնել նաև այլ խոշոր վերլուծական հարթակներում, ներառյալ Presto, Tensorflow to R, Jupyter: Հեռավոր ամպային պահեստավորման համակարգեր բեռնաթափելով՝ շատ ավելի հեշտ է դառնում կառավարել և մասշտաբավորել ձեր հավելվածը: Բացի այդ, այն հեշտացնում է հավելվածի տեղափոխելիությունը տարբեր միջավայրերում:

Source: www.habr.com