Kubernetes. բաց կոդով ընդդեմ վաճառողի հատուկ

Բարև, ես Դմիտրի Կրասնովն եմ: Ավելի քան հինգ տարի ես կառավարում եմ Kubernetes-ի կլաստերները և կառուցում միկրոսերվիսային համալիր ճարտարապետություններ: Այս տարվա սկզբին մենք գործարկեցինք ծառայություն՝ կառավարելու Kubernetes կլաստերները՝ հիմնված Containerum-ի վրա: Օգտվելով այս հնարավորությունից՝ ես ձեզ կասեմ, թե ինչ է Kubernetes-ը և ինչպես է վաճառողի հետ ինտեգրումը տարբերվում բաց կոդով։

Սկսելու համար, թե ինչ է Կուբերնետես. Սա մեծ թվով հոսթների վրա բեռնարկղերի կառավարման համակարգ է: Հունարենից, ի դեպ, այն թարգմանվում է որպես «օդաչու» կամ «ղեկավար»։ Սկզբնապես մշակվել է Google-ի կողմից և այնուհետև նվիրաբերվել որպես տեխնոլոգիական ներդրում Cloud Native Computing Foundation-ին՝ միջազգային ոչ առևտրային կազմակերպությանը, որը միավորում է աշխարհի առաջատար մշակողներին, վերջնական օգտագործողներին և կոնտեյներային տեխնոլոգիաների մատակարարներին:

Կառավարեք մեծ քանակությամբ բեռնարկղեր

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

Կոնտեյների պատկերը ներկայացնում է հավելված՝ գումարած դրա կախվածությունները: Հավելվածը, դրա կախվածությունները և ՕՀ ֆայլային համակարգի պատկերը գտնվում են պատկերի տարբեր մասերում, այսպես կոչված, շերտերում։ Շերտերը կարող են կրկին օգտագործվել տարբեր տարաների համար: Օրինակ, ընկերության բոլոր հավելվածները կարող են օգտագործել Ubuntu-ի բազային շերտը: Կոնտեյներներ գործարկելիս կարիք չկա հյուրընկալողի վրա մեկ բազային շերտի մի քանի օրինակներ պահել: Սա թույլ է տալիս օպտիմալացնել պատկերների պահպանումն ու առաքումը:

Երբ մենք ցանկանում ենք գործարկել հավելվածը կոնտեյներից, անհրաժեշտ շերտերը դրվում են միմյանց վրա և ձևավորվում է overlay ֆայլային համակարգ։ Վերևում տեղադրվում է ձայնագրող շերտ, որը հանվում է, երբ բեռնարկղը կանգ է առնում: Սա ապահովում է, որ երբ բեռնարկղը գործարկվի, հավելվածը միշտ կունենա նույն միջավայրը, որը հնարավոր չէ փոխել: Սա երաշխավորում է շրջակա միջավայրի վերարտադրելիությունը տարբեր հյուրընկալող ՕՀ-ներում: Լինի դա Ubuntu թե CentOS, միջավայրը միշտ նույնը կլինի: Բացի այդ, կոնտեյները մեկուսացված է հոսթից՝ օգտագործելով Linux միջուկում ներկառուցված մեխանիզմներ: Կոնտեյների հավելվածները չեն տեսնում ֆայլերը, հյուրընկալողի և հարևան կոնտեյներների գործընթացները: Հավելվածների այս մեկուսացումը հյուրընկալող ՕՀ-ից ապահովում է անվտանգության լրացուցիչ շերտ:

Կան բազմաթիվ գործիքներ, որոնք հասանելի են հյուրընկալողի վրա բեռնարկղերը կառավարելու համար: Դրանցից ամենահայտնին Docker-ն է։ Այն թույլ է տալիս ապահովել բեռնարկղերի կյանքի ամբողջական ցիկլը: Այնուամենայնիվ, այն աշխատում է միայն մեկ հոսթի վրա: Եթե ​​Ձեզ անհրաժեշտ է կառավարել կոնտեյներները մի քանի հոսթների միջոցով, Docker-ը կարող է կյանքը դժոխք դարձնել ինժեներների համար: Ահա թե ինչու ստեղծվեց Kubernetes-ը:

Kubernetes-ի պահանջարկը հենց պայմանավորված է մի քանի հոսթների վրա բեռնարկղերի խմբերը կառավարելու ունակությամբ, որպես առանձին միավորի: Համակարգի հանրաճանաչությունը հնարավորություն է տալիս ստեղծել DevOps կամ Development Operations, որոնցում Kubernetes-ն օգտագործվում է հենց այս DevOps-ի գործընթացները գործարկելու համար։

Նկար 1. Սխեմատիկ ներկայացում, թե ինչպես է աշխատում Kubernetes-ը

Ամբողջական ավտոմատացում

DevOps-ը հիմնականում մշակման գործընթացի ավտոմատացումն է: Կոպիտ ասած, մշակողները գրում են կոդ, որը վերբեռնվում է պահեստ: Այնուհետև այս կոդը կարող է ավտոմատ կերպով հավաքվել բոլոր գրադարաններով կոնտեյների մեջ, փորձարկվել և «գլորվել» հաջորդ փուլ՝ Բեմականացում, այնուհետև անմիջապես Արտադրություն:

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

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

Պլյուսներ, դրական կողմեր, դրական կողմեր

Եթե ​​խոսենք Kubernetes-ի առավելությունների մասին՝ որպես հարթակ, ապա այն զգալի առավելություններ ունի միկրոսերվիսային ճարտարապետության կառավարման տեսանկյունից։

• Բազմաթիվ կրկնօրինակների կառավարում: Ամենակարևորը բեռնարկղերի կառավարումն է բազմաթիվ հոսթների միջև: Ավելի կարևոր է, կառավարեք բազմաթիվ հավելվածների կրկնօրինակները բեռնարկղերում որպես մեկ միավոր: Դրա շնորհիվ ինժեներները կարիք չունեն անհանգստանալու յուրաքանչյուր առանձին կոնտեյների համար: Եթե ​​բեռնարկղերից մեկը խափանվի, Kubernetes-ը կտեսնի սա և նորից կվերագործարկի:
• Կլաստերային ցանց. Kubernetes-ն ունի նաև այսպես կոչված կլաստերային ցանց՝ իր հասցեների տարածությամբ։ Դրա շնորհիվ յուրաքանչյուր պատիճ ունի իր հասցեն: Ենթաբոդը հասկացվում է որպես կլաստերի նվազագույն կառուցվածքային միավոր, որտեղ կոնտեյներները ուղղակիորեն գործարկվում են: Բացի այդ, Kubernetes-ն ունի ֆունկցիոնալություն, որը համատեղում է բեռի հավասարակշռիչը և ծառայության հայտնաբերումը: Սա թույլ է տալիս ազատվել ձեռքով IP հասցեների կառավարումից և հանձնարարել այս առաջադրանքը Kubernetes-ին: Իսկ առողջության ավտոմատ ստուգումները կօգնեն հայտնաբերել խնդիրները և երթևեկությունը վերահղել դեպի աշխատանքային պատյաններ:
• Կազմաձևման կառավարում. Մեծ թվով հավելվածներ կառավարելիս դժվար է դառնում կառավարել հավելվածի կազմաձևումը: Այդ նպատակով Kubernetes-ն ունի ConfigMap-ի հատուկ ռեսուրսներ: Դրանք թույլ են տալիս կենտրոնականորեն պահել կոնֆիգուրացիաները և դրանք ցուցադրել հավելվածների գործարկման ժամանակ: Այս մեխանիզմը թույլ է տալիս երաշխավորել կոնֆիգուրացիայի հետևողականությունը առնվազն տասը կամ հարյուր կիրառական կրկնօրինակներում:
• Մշտական ​​ծավալներ. Կոնտեյներներն իրենց էությամբ անփոփոխ են, և երբ կոնտեյները դադարեցվի, ֆայլային համակարգում գրված բոլոր տվյալները կկործանվեն: Բայց որոշ հավելվածներ տվյալները պահում են անմիջապես սկավառակի վրա: Այս խնդիրը լուծելու համար Kubernetes-ն ունի սկավառակի պահպանման կառավարման գործառույթ՝ Persistent Volumes: Այս մեխանիզմն օգտագործում է տվյալների արտաքին պահեստավորում և կարող է մշտական ​​պահեստավորում, արգելափակում կամ ֆայլ տեղափոխել կոնտեյներներ: Այս լուծումը թույլ է տալիս աշխատողներից առանձին պահել տվյալները, ինչը կփրկի դրանք, եթե նույն աշխատողները փչանան:
• Load Balancer. Չնայած Kubernetes-ում մենք կառավարում ենք վերացական սուբյեկտներ, ինչպիսիք են Deployment-ը, StatefulSet-ը և այլն, ի վերջո կոնտեյներներն աշխատում են սովորական վիրտուալ մեքենաների կամ ապարատային սերվերների վրա: Նրանք կատարյալ չեն և ցանկացած պահի կարող են ընկնել: Kubernetes-ը կտեսնի սա և կուղղորդի ներքին տրաֆիկը դեպի այլ կրկնօրինակներ: Բայց ի՞նչ անել երթևեկության հետ, որը գալիս է դրսից: Եթե ​​դուք պարզապես ուղղորդում եք երթևեկությունը աշխատողներից մեկին, եթե այն խափանվի, ծառայությունն անհասանելի կդառնա: Այս խնդիրը լուծելու համար Kubernetes-ն ունի Load Balancer-ի նման ծառայություններ: Դրանք նախագծված են ավտոմատ կերպով կարգավորելու արտաքին ամպային հավասարակշռիչը կլաստերի բոլոր աշխատողների համար: Այս արտաքին հավասարակշռիչը ուղղորդում է արտաքին երթևեկությունը դեպի աշխատողներ և ինքն է վերահսկում նրանց կարգավիճակը: Եթե ​​մեկ կամ մի քանի աշխատող դառնում է անհասանելի, երթևեկությունը վերահղվում է մյուսներին: Սա թույլ է տալիս ստեղծել բարձր հասանելի ծառայություններ՝ օգտագործելով Kubernetes:

Kubernetes-ը լավագույնս աշխատում է միկրոսերվիսային ճարտարապետություններ գործարկելիս: Համակարգը դասական ճարտարապետության մեջ հնարավոր է ներդնել, բայց դա անիմաստ է։ Եթե ​​հավելվածը չի կարող աշխատել մի քանի կրկնօրինակների վրա, ապա ի՞նչ տարբերություն՝ Kubernetes-ում, թե ոչ:

Բաց կոդով Kubernetes

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

• Առաջինը ադմինիստրատորների և ինժեներների գիտելիքների և փորձի պահանջն է, ովքեր կտեղակայեն և կաջակցեն այս ամենին: Քանի որ հաճախորդը ստանում է կլաստերի գործողությունների լիակատար ազատություն, նա ինքն է պատասխանատվություն կրում կլաստերի կատարման համար: Եվ այստեղ ամեն ինչ կոտրելը շատ հեշտ է:
• Երկրորդը ինտեգրումների բացակայությունն է։ Եթե ​​դուք աշխատում եք Kubernetes-ն առանց հանրաճանաչ վիրտուալացման հարթակի, դուք չեք ստանա ծրագրի բոլոր առավելությունները: Ինչպես օրինակ՝ Persistent Volumes և Load balancer ծառայություններից օգտվելը:

Նկար 2. k8s ճարտարապետություն

Kubernetes-ը վաճառողից

Ամպային մատակարարի հետ ինտեգրումն ապահովում է երկու տարբերակ.

• Նախ, մարդը կարող է պարզապես սեղմել «ստեղծել կլաստեր» կոճակը և ստանալ արդեն կազմաձևված և օգտագործման համար պատրաստ կլաստեր:
• Երկրորդ, վաճառողն ինքն է տեղադրում կլաստերը և ինտեգրում ամպի հետ:

Ինչպես է դա տեղի ունենում այստեղ: Կլաստերը գործարկող ինժեները նշում է, թե քանի աշխատող է իրեն պետք և ինչ պարամետրերով (օրինակ՝ 5 աշխատող, յուրաքանչյուրը 10 պրոցեսորով, 16 ԳԲ օպերատիվ հիշողությամբ և, ասենք, 100 ԳԲ սկավառակով)։ Որից հետո այն մուտք է ստանում արդեն ձևավորված կլաստերին։ Այս դեպքում աշխատողները, որոնց վրա գործարկվում է բեռը, ամբողջությամբ փոխանցվում են հաճախորդին, բայց կառավարման ամբողջ հարթությունը մնում է վաճառողի պատասխանատվության ներքո (եթե ծառայությունը մատուցվում է կառավարվող ծառայության մոդելի համաձայն):

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

Նկար 3. Ամպային մատակարարից Kubernetes կլաստերի օրինակ

Ինչ ընտրել՝ բաց կոդով կամ վաճառող

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

Դե լավ կողմերն ակնհայտ են, դեմերն էլ՝ հայտնի։ Մի բան հաստատուն է՝ Kubernetes-ը լուծում է բազմաթիվ խնդիրներ՝ ավտոմատացնելով բազմաթիվ կոնտեյներների կառավարումը: Եվ որն ընտրել՝ բաց կոդով, թե վաճառող, յուրաքանչյուրն ինքն է որոշում կայացնում:

Հոդվածը պատրաստել է #CloudMTS մատակարարի Containerum ծառայության առաջատար ճարտարապետ Դմիտրի Կրասնովը։

Source: www.habr.com