Տվյալների պահպանում Kubernetes կլաստերում

Կան մի քանի եղանակներ կարգավորելու տվյալների պահեստը Kubernetes կլաստերի վրա աշխատող հավելվածների համար: Դրանցից մի քանիսն արդեն հնացել են, մյուսները հայտնվել են բոլորովին վերջերս։ Այս հոդվածում մենք կանդրադառնանք պահեստավորման համակարգերի միացման երեք տարբերակի հայեցակարգին, ներառյալ ամենավերջինը` կոնտեյների պահպանման միջերեսի միջոցով միացումը:

Մեթոդ 1. նշեք PV-ն մանիֆեստում

Տիպիկ մանիֆեստ, որը նկարագրում է պատիճը Kubernetes կլաստերի մեջ.

Մանիֆեստի այն մասերը, որոնք նկարագրում են, թե որ ծավալն է միացված և որտեղ, ընդգծված են գունավոր:

Բաժին volumeMounts նշեք տեղադրման կետերը (mountPath) - կոնտեյների ներսում որ գրացուցակում կտեղադրվի մշտական ​​ծավալը, ինչպես նաև ծավալի անվանումը:

Բաժին x թվարկում է բոլոր հատորները, որոնք օգտագործվում են պատիճում: Նշեք յուրաքանչյուր հատորի անունը, ինչպես նաև տեսակը (մեր դեպքում՝ awsElasticBlockStore) և կապի պարամետրերը։ Որ պարամետրերը նշված են մանիֆեստում, կախված է ծավալի տեսակից:

Նույն ծավալը կարող է տեղադրվել միաժամանակ մի քանի պատիճ բեռնարկղերի մեջ: Այս կերպ տարբեր կիրառական գործընթացներ կարող են մուտք գործել նույն տվյալները:

Կապի այս մեթոդը հորինվել է հենց սկզբում, երբ Kubernetes-ը դեռ նոր էր սկսվում, իսկ այսօր մեթոդը հնացել է։

Այն օգտագործելիս կան մի քանի խնդիրներ.

1. բոլոր հատորները պետք է ձեռքով ստեղծվեն, Kubernetes-ը մեզ համար ոչինչ չի կարող ստեղծել.
2. Յուրաքանչյուր հատորի համար մուտքի պարամետրերը եզակի են, և դրանք պետք է նշվեն ձայնը օգտագործող բոլոր պատյանների մանիֆեստներում.
3. պահեստավորման համակարգը փոխելու համար (օրինակ՝ AWS-ից Google Cloud տեղափոխվել), դուք պետք է փոխեք բոլոր մանիֆեստներում տեղադրված ծավալների կարգավորումները և տեսակը:

Այս ամենը շատ անհարմար է, ուստի իրականում այս մեթոդը օգտագործվում է միայն որոշ հատուկ տեսակի հատորներ միացնելու համար՝ configMap, secret, դատարկDir, hostPath:

• configMap-ը և secret-ը ծառայությունների ծավալներ են, որոնք թույլ են տալիս կոնտեյների մեջ ստեղծել հատոր Kubernetes մանիֆեստներից ֆայլերով:

• valaDir-ը ժամանակավոր ծավալ է, որը ստեղծվել է միայն պատի ողջ կյանքի համար: Հարմար է օգտագործել փորձարկման կամ ժամանակավոր տվյալների պահպանման համար: Երբ pod-ը ջնջվում է, դատարկDir ծավալը նույնպես ջնջվում է, և բոլոր տվյալները կորչում են:

• hostPath - թույլ է տալիս տեղադրել ցանկացած գրացուցակ սերվերի տեղական սկավառակի վրա, որի վրա հավելվածն աշխատում է հավելվածի կոնտեյների ներսում, ներառյալ /etc/kubernetes: Սա վտանգավոր հատկություն է, ուստի անվտանգության քաղաքականությունը սովորաբար արգելում է այս տեսակի ծավալների օգտագործումը: Հակառակ դեպքում, հարձակվողի հավելվածը կկարողանա տեղադրել HTC Kubernetes գրացուցակը իր կոնտեյների ներսում և գողանալ բոլոր կլաստերի վկայականները: Սովորաբար, hostPath-ի ծավալները թույլատրվում են օգտագործել միայն համակարգային հավելվածների կողմից, որոնք աշխատում են kube-համակարգի անվանատարածքում:

Պահպանման համակարգեր, որոնցով Kubernetes-ը աշխատում է տուփից դուրս ներկայացված են փաստաթղթերում:

Մեթոդ 2. Միացում SC/PVC/PV օջախներին

Այլընտրանքային կապի մեթոդը Storage դասի, PersistentVolumeClaim, PersistentVolume հասկացությունն է:

Պահպանման դաս պահպանում է տվյալների պահպանման համակարգի միացման պարամետրերը:

PersistentVolumeClaim նկարագրում է այն պահանջները, որոնց կարիքն ունի հայտը:
Մշտական ​​ծավալ պահպանում է մուտքի պարամետրերը և ծավալի կարգավիճակը:

Գաղափարի էությունը. pod մանիֆեստում նրանք նշում են PersistentVolumeClaim տիպի ծավալը և նշում են այս էության անունը pretendName պարամետրում:

PersistentVolumeClaim մանիֆեստը նկարագրում է հավելվածի պահանջվող տվյալների ծավալի պահանջները: Ներառյալ՝

• սկավառակի չափը;
• մուտքի եղանակը՝ ReadWriteOnce կամ ReadWriteMany;
• հղում Storage դասին - տվյալների պահպանման որ համակարգում ենք ցանկանում ստեղծել ծավալը:

Storage դասի մանիֆեստը պահպանում է պահպանման համակարգի հետ կապի տեսակը և պարամետրերը: Cubelet-ին անհրաժեշտ են դրանք՝ ձայնը իր հանգույցի վրա տեղադրելու համար:

PersistentVolume մանիֆեստները ցույց են տալիս Storage դասը և մուտքի պարամետրերը որոշակի ծավալի համար (ծավալի ID, ուղի և այլն):

ՊՎՔ ստեղծելիս Kubernetes-ը նայում է, թե ինչ չափի ծավալ և ինչ Storage դաս է պահանջվում, և ընտրում է անվճար PersistentVolume:

Եթե ​​նման PV-ները հասանելի չեն, Kubernetes-ը կարող է գործարկել հատուկ ծրագիր՝ Provisioner (նրա անունը նշված է Storage դասում): Այս ծրագիրը միանում է պահեստավորման համակարգին, ստեղծում է անհրաժեշտ չափի ծավալ, ստանում է նույնացուցիչ և ստեղծում է PersistentVolume մանիֆեստ Kubernetes կլաստերում, որը կապված է PersistentVolumeClaim-ի հետ:

Վերացականների այս ամբողջ բազմությունը թույլ է տալիս հեռացնել տեղեկատվությունը այն մասին, թե որ պահպանման համակարգի հետ է աշխատում հավելվածը հավելվածի մանիֆեստի մակարդակից մինչև կառավարման մակարդակ:

Տվյալների պահպանման համակարգին միանալու բոլոր պարամետրերը գտնվում են Storage դասում, որի համար պատասխանատու են կլաստերի ադմինիստրատորները։ Այն ամենը, ինչ դուք պետք է անեք AWS-ից Google Cloud տեղափոխվելիս, հավելվածի մանիֆեստներում Storage դասի անվանումը փոխելն է PVC-ի: Տվյալների պահպանման համար Persistance Volume-ը կստեղծվի կլաստերում ավտոմատ կերպով՝ օգտագործելով Provisioner ծրագիրը:

Մեթոդ 3. Բեռնարկղերի պահպանման միջերես

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

Խնդիրը լուծելու համար Cloud Foundry-ի, Kubernetes-ի, Mesos-ի և Docker-ի ծրագրավորողները ստեղծեցին Container Storage Interface (CSI)՝ պարզ միասնական ինտերֆեյս, որը նկարագրում է կոնտեյների կառավարման համակարգի փոխազդեցությունը և հատուկ դրայվերի (CSI Driver), որն աշխատում է որոշակի հատուկ սարքի հետ: պահեստավորման համակարգ. Պահպանման համակարգերի հետ փոխգործակցության բոլոր ծածկագրերը Kubernetes միջուկից տեղափոխվել են առանձին համակարգ:

Բեռնարկղերի պահպանման միջերեսի փաստաթղթեր.

Սովորաբար, CSI Driver-ը բաղկացած է երկու բաղադրիչից՝ Node Plugin և Controller plugin:

Node Plugin-ն աշխատում է յուրաքանչյուր հանգույցի վրա և պատասխանատու է ծավալների տեղադրման և դրանց վրա գործողություններ կատարելու համար: Controller plugin-ը փոխազդում է պահեստավորման համակարգի հետ՝ ստեղծում կամ ջնջում է ծավալներ, հատկացնում մուտքի իրավունքներ և այլն:

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

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

Եկեք օրինակ վերցնենք՝ տեսնելու այն առավելությունները, որոնք դուք կարող եք ստանալ՝ միացնելով Ceph պահեստավորման համակարգերին՝ օգտագործելով CSI դրայվերը:

Ceph-ի հետ աշխատելիս CSI plugin-ն ավելի շատ տարբերակներ է ապահովում պահեստավորման համակարգերի հետ աշխատելու համար, քան ներկառուցված դրայվերները:

1. Դինամիկ սկավառակի ստեղծում: Սովորաբար RBD սկավառակներն օգտագործվում են միայն RWO ռեժիմում, սակայն CSI-ը Ceph-ի համար թույլ է տալիս դրանք օգտագործել RWX ռեժիմում: Մի քանի պատիճ տարբեր հանգույցների վրա կարող են միևնույն RDB սկավառակը տեղադրել իրենց հանգույցների վրա և աշխատել դրանց հետ զուգահեռ: Արդարության համար, ամեն ինչ այնքան էլ պայծառ չէ. այս սկավառակը կարող է միացվել միայն որպես բլոկ սարք, ինչը նշանակում է, որ դուք պետք է հարմարեցնեք հավելվածը, որպեսզի աշխատի դրա հետ բազմակի մուտքի ռեժիմում:
2. Պատկերների ստեղծում: Kubernetes կլաստերում դուք կարող եք ստեղծել մանիֆեստ՝ լուսանկար ստեղծելու պահանջով: CSI plugin-ը կտեսնի այն և լուսանկար կտա սկավառակից: Դրա հիման վրա դուք կարող եք ստեղծել կամ կրկնօրինակ կամ պատճենել PersistentVolume-ը:
3. Սկավառակի չափի մեծացում պահեստավորման և PersistentVolume-ի վրա Kubernetes կլաստերում:
4. Քվոտաներ. Kubernetes-ում ներկառուցված CephFS դրայվերները չեն աջակցում քվոտաներին, սակայն վերջին Ceph Nautilus-ով թարմ CSI հավելվածները կարող են միացնել քվոտաները CephFS միջնորմների վրա:
5. Չափումներ. CSI plugin-ը կարող է Պրոմեթևսին տրամադրել մի շարք չափումներ այն մասին, թե որ ծավալներն են միացված, ինչ հաղորդակցություններ են տեղի ունենում և այլն:
6. Տոպոլոգիայի տեղյակ. Թույլ է տալիս մանիֆեստներում նշել, թե ինչպես է կլաստերը աշխարհագրորեն բաշխված, և խուսափել Ամստերդամում տեղակայված պահեստավորման համակարգը Լոնդոնում աշխատող բլոկներին միացնելուց:

Ինչպես միացնել Ceph-ը Kubernetes կլաստերին CSI-ի միջոցով, տես Slurm երեկոյան դպրոցի դասախոսության գործնական մասում. Կարող եք նաև բաժանորդագրվել Ceph վիդեո դասընթաց, որը կմեկնարկի հոկտեմբերի 15-ին։

Հոդվածի հեղինակ՝ Սերգեյ Բոնդարև, Southbridge-ի պրակտիկ ճարտարապետ, Kubernetes-ի հավաստագրված ադմինիստրատոր, kubespray-ի մշակողներից մեկը։

Մի փոքրիկ Պոստ Սկրիպտում ոչ թե գովազդի, այլ շահի համար...

Հ.Գ. Սերգեյ Բոնդարևը վարում է երկու ինտենսիվ դասընթացներ՝ թարմացված Կուբերնետես բազա սեպտեմբերի 28-30-ը և խորացված Kubernetes Mega հոկտեմբերի 14–16.

Source: www.habr.com