Նշում. թարգմ.Այս նյութը ուսումնական նախագծից է Kubernetes-ի վրա հիմնված ենթակառուցվածքի նախագծման ժամանակ տարածված հարցի պատասխանն է: Հուսով ենք, որ յուրաքանչյուր տարբերակի դրական և բացասական կողմերի բավականին մանրամասն նկարագրությունը կօգնի ձեզ կատարել լավագույն ընտրությունը ձեր նախագծի համար:
TL. DRԱշխատանքային բեռների նույն փաթեթը կարող է գործարկվել մի քանի խոշոր կլաստերների վրա (յուրաքանչյուր կլաստեր կունենա մեծ թվով ծանրաբեռնվածություն) կամ շատ փոքրերի վրա (յուրաքանչյուր կլաստերում փոքր քանակությամբ ծանրաբեռնվածություններով):
Ստորև բերված է աղյուսակ, որը գնահատում է յուրաքանչյուր մոտեցման դրական և բացասական կողմերը.
Kubernetes-ը որպես հավելվածների գործարկման հարթակ օգտագործելիս մի քանի հիմնարար հարցեր հաճախ են առաջանում կլաստերների ստեղծման բարդությունների վերաբերյալ.
- Քանի՞ կլաստեր պետք է օգտագործեմ:
- Որքա՞ն մեծ պետք է դարձնեմ դրանք:
- Ի՞նչ պետք է ներառի յուրաքանչյուր կլաստեր:
Այս հոդվածում ես կփորձեմ պատասխանել այս բոլոր հարցերին՝ վերլուծելով յուրաքանչյուր մոտեցման դրական և բացասական կողմերը:
Հարցի հայտարարություն
Որպես ծրագրաշարի մշակող, դուք, հավանաբար, միաժամանակ մշակում և գործարկում եք բազմաթիվ հավելվածներ:
Բացի այդ, այս հավելվածների շատ օրինակներ, հավանաբար, կաշխատեն տարբեր միջավայրերում, օրինակ, դրանք կարող են լինել դավ, փորձարկում и արտադրել.
Արդյունքը հավելվածների և միջավայրերի մի ամբողջ մատրիցա է.
Ծրագրեր և միջավայրեր
Վերոնշյալ օրինակը ներկայացնում է 3 հավելված և 3 միջավայր, ինչը հանգեցնում է ընդհանուր 9 հնարավոր տարբերակի:
Հավելվածի յուրաքանչյուր օրինակ իրենից ներկայացնում է ինքնուրույն տեղակայման միավոր, որի հետ կարելի է աշխատել անկախ ուրիշներից:
Խնդրում ենք նկատի ունենալ, որ դիմումի օրինակ կարող է բաղկացած լինել շատերից բաղադրիչներ, ինչպիսիք են ճակատը, հետնամասը, տվյալների բազան և այլն: Միկրոծառայությունների հավելվածի դեպքում օրինակը կներառի բոլոր միկրոծառայությունները:
Արդյունքում Kubernetes-ի օգտատերերը մի քանի հարց ունեն.
- Արդյո՞ք բոլոր հավելվածների օրինակները պետք է տեղադրվեն մեկ կլաստերում:
- Արժե՞ արդյոք ունենալ առանձին կլաստեր յուրաքանչյուր հավելվածի օրինակի համար:
- Կամ գուցե վերը նշված մոտեցումների համակցությո՞ւնը պետք է օգտագործվի:
Այս բոլոր տարբերակները բավականին կենսունակ են, քանի որ Kubernetes-ը ճկուն համակարգ է, որը չի սահմանափակում օգտատիրոջ հնարավորությունները։
Ահա մի քանի հնարավոր ուղիներ.
- մեկ մեծ ընդհանուր կլաստեր;
- շատ փոքր բարձր մասնագիտացված կլաստերներ;
- մեկ կլաստեր մեկ դիմումի համար;
- մեկ կլաստեր յուրաքանչյուր միջավայրում:
Ինչպես ցույց է տրված ստորև, առաջին երկու մոտեցումները գտնվում են տարբերակների սանդղակի հակառակ ծայրերում.
Մի քանի մեծ կլաստերներից (ձախից) մինչև շատ փոքր (աջ)
Ընդհանուր առմամբ, մի կլաստերը համարվում է «ավելի մեծ», քան մյուսը, եթե այն ունի ավելի մեծ քանակությամբ հանգույցներ և պատյաններ: Օրինակ, 10 հանգույցներով և 100 բլոկներով կլաստերն ավելի մեծ է, քան 1 հանգույց և 10 բլոկ ունեցող կլաստերը:
Դե, եկեք սկսենք:
1. Մեկ մեծ ընդհանուր կլաստեր
Առաջին տարբերակն այն է, որ բոլոր ծանրաբեռնվածությունները տեղադրվեն մեկ կլաստերում.
Մեկ մեծ կլաստեր
Այս մոտեցման շրջանակներում կլաստերը օգտագործվում է որպես ունիվերսալ ենթակառուցվածքային հարթակ - Դուք պարզապես տեղակայում եք այն ամենը, ինչ ձեզ անհրաժեշտ է գոյություն ունեցող Kubernetes կլաստերում:
Kubernetes-ը թույլ է տալիս կլաստերի մասերը տրամաբանորեն առանձնացնել միմյանցից, այնպես որ յուրաքանչյուր հավելվածի օրինակ կարող է ունենալ իր անվանատարածքը։
Եկեք նայենք այս մոտեցման դրական և բացասական կողմերին:
+ Ռեսուրսների արդյունավետ օգտագործում
Մեկ կլաստերի դեպքում ձեզ անհրաժեշտ է բոլոր ռեսուրսների միայն մեկ պատճենը, որոնք անհրաժեշտ են Kubernetes կլաստերը գործարկելու և կառավարելու համար:
Օրինակ, սա ճիշտ է հիմնական հանգույցների համար: Որպես կանոն, յուրաքանչյուր Kubernetes կլաստերի ունի 3 հիմնական հանգույց, ուստի մեկ կլաստերի համար նրանց թիվը կմնա այդպիսին (համեմատության համար 10 կլաստերների համար անհրաժեշտ կլինի 30 հիմնական հանգույց):
Վերոնշյալ նրբությունը վերաբերում է նաև այլ ծառայություններին, որոնք գործում են ամբողջ կլաստերի վրա, ինչպիսիք են բեռնաչափերը, Ingress կարգավորիչները, նույնականացման, գրանցման և մոնիտորինգի համակարգերը:
Մեկ կլաստերում այս բոլոր ծառայությունները կարող են օգտագործվել միանգամից բոլոր ծանրաբեռնվածությունների համար (կարիք չկա ստեղծել դրանց պատճենները, ինչպես դա տեղի է ունենում մի քանի կլաստերների դեպքում):
+ Էժան
Վերոնշյալի հետևանքով ավելի քիչ կլաստերներ սովորաբար ավելի էժան են, քանի որ չկան վերադիր ծախսեր:
Սա հատկապես ճիշտ է հիմնական հանգույցների համար, որոնք կարող են զգալի գումար արժենալ՝ անկախ նրանից, թե ինչպես են դրանք հյուրընկալվել (տարածքում կամ ամպի մեջ):
Որոշ կառավարվող Kubernetes ծառայություններ, ինչպիսիք են կամ , անվճար տրամադրեք կառավարման շերտը։ Այս դեպքում ծախսերի խնդիրն ավելի քիչ սուր է:
Կան նաև կառավարվող ծառայություններ, որոնք ֆիքսված վճար են գանձում Kubernetes-ի յուրաքանչյուր կլաստերի աշխատանքի համար (օրինակ. ).
+ Արդյունավետ կառավարում
Մեկ կլաստերի կառավարումն ավելի հեշտ է, քան մի քանիսը:
Կառավարումը կարող է ներառել հետևյալ խնդիրները.
- Kubernetes տարբերակի թարմացում;
- CI/CD խողովակաշարի տեղադրում;
- CNI plugin-ի տեղադրում;
- օգտագործողի վավերացման համակարգի ստեղծում;
- մուտքի վերահսկիչի տեղադրում;
և շատ ուրիշներ…
Մեկ կլաստերի դեպքում այս ամենը ստիպված կլինեք անել միայն մեկ անգամ։
Շատ կլաստերների համար գործողությունները պետք է կրկնվեն բազմիցս, ինչը, հավանաբար, կպահանջի գործընթացների և գործիքների որոշակի ավտոմատացում՝ գործընթացում հետևողականություն և հետևողականություն ապահովելու համար:
Իսկ հիմա մի քանի խոսք մինուսների մասին։
- ձախողման մեկ կետ
Մերժման դեպքում միակը կլաստերը անմիջապես կդադարի աշխատել բոլորը ծանրաբեռնվածություն!
Կան բազմաթիվ եղանակներ, որոնք կարող են սխալ լինել.
- Kubernetes-ի թարմացումը հանգեցնում է անսպասելի կողմնակի ազդեցությունների.
- Կլաստերային ամբողջ բաղադրիչը (օրինակ՝ CNI plugin) սկսում է չաշխատել այնպես, ինչպես սպասվում էր.
- կլաստերի բաղադրիչներից մեկը ճիշտ կազմաձևված չէ.
- հիմքում ընկած ենթակառուցվածքի ձախողում.
Նման միջադեպերից մեկը կարող է լուրջ վնաս հասցնել բոլոր աշխատանքային բեռներին, որոնք տեղակայված են ընդհանուր կլաստերում:
- Ոչ կոշտ մեկուսացում
Համօգտագործվող կլաստերի մեջ աշխատելը նշանակում է, որ հավելվածները կիսում են սարքաշարը, ցանցային հնարավորությունները և օպերացիոն համակարգը կլաստերի հանգույցների վրա:
Ինչ-որ իմաստով, երկու կոնտեյներներ երկու տարբեր հավելվածներով, որոնք աշխատում են նույն հանգույցում, նման են երկու գործընթացների, որոնք աշխատում են նույն մեքենայի վրա, որոնք աշխատում են նույն ՕՀ միջուկը:
Linux-ի կոնտեյներները ապահովում են մեկուսացման որոշակի ձև, բայց այն գրեթե այնքան ուժեղ չէ, որքան, ասենք, վիրտուալ մեքենաների տրամադրածը: Ըստ էության, բեռնարկղում գտնվող գործընթացը նույն գործընթացն է, որն աշխատում է հյուրընկալող օպերացիոն համակարգում:
Սա կարող է անվտանգության խնդիր լինել. այս պայմանավորվածությունը տեսականորեն թույլ է տալիս կապ չունեցող հավելվածներին հաղորդակցվել միմյանց հետ (կամ դիտավորյալ կամ պատահաբար):
Բացի այդ, Kubernetes կլաստերի բոլոր ծանրաբեռնվածությունները կիսում են կլաստերի մի շարք ծառայություններ, ինչպիսիք են. - սա թույլ է տալիս հավելվածներին գտնել կլաստերի այլ հավելվածների ծառայությունները:
Վերոնշյալ բոլոր կետերը կարող են տարբեր նշանակություն ունենալ՝ կախված հավելվածի անվտանգության պահանջներից:
Kubernetes-ը տրամադրում է տարբեր գործիքներ՝ կանխելու անվտանգության խնդիրները, ինչպիսիք են и . Այնուամենայնիվ, դրանց ճիշտ տեղադրումը որոշակի փորձ է պահանջում, բացի այդ, նրանք չեն կարողանում բացարձակապես փակել անվտանգության բոլոր անցքերը:
Կարևոր է միշտ հիշել, որ Kubernetes-ն ի սկզբանե նախատեսված է եղել կիսվելով, ոչ թե համար մեկուսացում և անվտանգություն.
− Խիստ բազմավարձակալության բացակայություն
Հաշվի առնելով Kubernetes կլաստերի ընդհանուր ռեսուրսների առատությունը, կան բազմաթիվ եղանակներ, որոնցով տարբեր հավելվածներ կարող են միմյանց ոտքի վրա դնել:
Օրինակ, հավելվածը կարող է մոնոպոլիզացնել ընդհանուր ռեսուրսը (օրինակ՝ պրոցեսորը կամ հիշողությունը) և մերժել նույն հանգույցի վրա աշխատող այլ հավելվածների մուտքը դրան:
Kubernetes-ը տրամադրում է այս վարքագիծը վերահսկելու տարբեր մեխանիզմներ, ինչպիսիք են (տե՛ս նաև հոդվածը «- մոտ. թարգմ.), и . Այնուամենայնիվ, ինչպես անվտանգության դեպքում, դրանց կոնֆիգուրացիան բավականին աննշան է, և նրանք ի վիճակի չեն կանխել բացարձակապես բոլոր չնախատեսված կողմնակի ազդեցությունները:
- Մեծ թվով օգտվողներ
Մեկ կլաստերի դեպքում դուք պետք է բացեք դրա մուտքը շատ մարդկանց համար: Եվ որքան մեծ է նրանց թիվը, այնքան մեծ է ռիսկը, որ նրանք ինչ-որ բան «կոտրեն»:
Կլաստերի ներսում դուք կարող եք վերահսկել, թե ով ինչ կարող է անել՝ օգտագործելով (տես հոդվածը»- մոտ. թարգմ.). Այնուամենայնիվ, դա չի խանգարի օգտվողներին ինչ-որ բան «կոտրել» իրենց պատասխանատվության տարածքի սահմաններում:
− Կլաստերները չեն կարող անվերջ աճել
Կլաստերը, որն օգտագործվում է բոլոր աշխատանքային ծանրաբեռնվածության համար, հավանաբար բավականին մեծ կլինի (հանգույցների և պատյանների քանակի առումով):
Բայց այստեղ մեկ այլ խնդիր է առաջանում՝ կլաստերները Kubernetes-ում չեն կարող անվերջ աճել։
Կլաստերի չափի տեսական սահմանափակում կա: Կուբերնետեսում մոտավորապես .
Այնուամենայնիվ, իրական կյանքում խնդիրները կարող են սկսվել շատ ավելի վաղ, օրինակ, պարզապես .
Փաստն այն է, որ մեծ կլաստերները մեծ բեռ են դնում Kubernetes-ի կառավարման շերտի վրա։ Այլ կերպ ասած, կլաստերի արդյունավետ գործարկումը պահանջում է զգույշ թյունինգ:
Այս հարցը ուսումնասիրված է բնօրինակ բլոգի համապատասխան հոդվածում, որը կոչվում է «.
Բայց եկեք դիտարկենք հակառակ մոտեցումը՝ շատ փոքր կլաստերներ:
2. Շատ փոքր, մասնագիտացված կլաստերներ
Այս մոտեցմամբ դուք օգտագործում եք առանձին կլաստեր յուրաքանչյուր տարրի համար, որը տեղադրում եք.
Շատ փոքր կլաստերներ
Սույն հոդվածի նպատակների համար, տակ տեղակայվող տարր վերաբերում է հավելվածի օրինակին, օրինակ՝ առանձին հավելվածի մշակված տարբերակին:
Այս ռազմավարությունը օգտագործում է Kubernetes-ը որպես մասնագիտացված գործարկման ժամանակը անհատական դիմումների համար:
Եկեք նայենք այս մոտեցման դրական և բացասական կողմերին:
+ Սահմանափակ «պայթյունի շառավիղ»
Երբ կլաստերը ձախողվում է, բացասական հետևանքները սահմանափակվում են միայն այն ծանրաբեռնվածությամբ, որոնք տեղակայվել են այդ կլաստերում: Մնացած բոլոր ծանրաբեռնվածությունները մնում են անձեռնմխելի:
+ Մեկուսացում
Առանձին կլաստերներում տեղակայված աշխատանքային բեռները չեն կիսում ռեսուրսները, ինչպիսիք են պրոցեսորը, հիշողությունը, օպերացիոն համակարգը, ցանցը կամ այլ ծառայություններ:
Արդյունքը ամուր մեկուսացում է կապ չունեցող հավելվածների միջև, ինչը կարող է շահավետ լինել դրանց անվտանգության համար:
+ Օգտագործողների փոքր քանակություն
Հաշվի առնելով, որ յուրաքանչյուր կլաստեր պարունակում է միայն սահմանափակ աշխատանքային ծանրաբեռնվածություն, դրան հասանելիություն ունեցող օգտատերերի թիվը կրճատվում է:
Որքան քիչ մարդիկ ունենան կլաստերի հասանելիություն, այնքան ցածր է ռիսկը, որ ինչ-որ բան «կոտրվի»:
Եկեք նայենք մինուսներին:
− ռեսուրսների անարդյունավետ օգտագործում
Ինչպես նշվեց ավելի վաղ, Kubernetes-ի յուրաքանչյուր կլաստեր պահանջում է կառավարման ռեսուրսների որոշակի փաթեթ՝ հիմնական հանգույցներ, կառավարման շերտի բաղադրիչներ, մոնիտորինգ և գրանցման լուծումներ:
Մեծ թվով փոքր կլաստերների դեպքում կառավարմանը պետք է հատկացվի ռեսուրսների ավելի մեծ բաժին:
- Թանկ
Ռեսուրսների անարդյունավետ օգտագործումը ինքնաբերաբար բարձր ծախսեր է առաջացնում:
Օրինակ, նույն հաշվողական հզորությամբ երեքի փոխարեն 30 հիմնական հանգույցների պահպանումը անպայմանորեն կազդի ծախսերի վրա:
- Կառավարման դժվարություններ
Kubernetes-ի մի քանի կլաստերների կառավարումը շատ ավելի դժվար է, քան միայն մեկի կառավարումը:
Օրինակ, դուք պետք է կազմաձևեք նույնականացումը և թույլտվությունը յուրաքանչյուր կլաստերի համար: Kubernetes-ի տարբերակը նույնպես պետք է մի քանի անգամ թարմացվի։
Դուք, հավանաբար, պետք է օգտագործեք ավտոմատացում՝ այս բոլոր առաջադրանքները ավելի արդյունավետ դարձնելու համար:
Հիմա եկեք նայենք ոչ այնքան ծայրահեղ սցենարներին:
3. Մեկ կլաստեր մեկ դիմումի համար
Այս մոտեցմամբ դուք ստեղծում եք առանձին կլաստեր որոշակի հավելվածի բոլոր օրինակների համար.
Կլաստեր մեկ դիմումի համար
Այս ճանապարհը կարելի է համարել որպես սկզբունքի ընդհանրացում.առանձին կլաստեր յուրաքանչյուր թիմի համար», քանի որ սովորաբար ինժեներների թիմը մշակում է մեկ կամ մի քանի հավելված:
Եկեք նայենք այս մոտեցման դրական և բացասական կողմերին:
+ Կլաստերը կարող է հարմարեցվել հավելվածին
Եթե հավելվածն ունի հատուկ կարիքներ, դրանք կարող են իրականացվել կլաստերի մեջ՝ չազդելով այլ կլաստերների վրա:
Նման կարիքները կարող են ներառել GPU աշխատողներ, որոշակի CNI պլագիններ, սպասարկման ցանց կամ որևէ այլ ծառայություն:
Յուրաքանչյուր կլաստեր կարող է հարմարեցվել դրանում աշխատող հավելվածին, որպեսզի այն պարունակի միայն այն, ինչ անհրաժեշտ է:
− Տարբեր միջավայրեր մեկ կլաստերում
Այս մոտեցման թերությունն այն է, որ տարբեր միջավայրերից կիրառական օրինակներ գոյակցում են նույն կլաստերում:
Օրինակ, հավելվածի պրոդ տարբերակն աշխատում է նույն կլաստերում, ինչ մշակողի տարբերակը: Սա նաև նշանակում է, որ մշակողները գործում են նույն կլաստերում, որտեղ գործում է հավելվածի արտադրական տարբերակը:
Եթե մշակողների գործողությունների կամ ծրագրային տարբերակի խափանումների պատճառով կլաստերում տեղի է ունենում ձախողում, ապա պրոդ տարբերակը նույնպես կարող է տուժել՝ այս մոտեցման հսկայական թերություն:
Եվ վերջապես, մեր ցուցակի վերջին սցենարը.
4. Մեկ կլաստեր յուրաքանչյուր միջավայրում
Այս սցենարը ներառում է յուրաքանչյուր միջավայրի համար առանձին կլաստերի հատկացում.
Մեկ կլաստեր յուրաքանչյուր միջավայրում
Օրինակ, դուք կարող եք ունենալ կլաստերներ դավ, փորձարկում и արտադրել, որում դուք կգործարկեք հավելվածի բոլոր օրինակները՝ նվիրված կոնկրետ միջավայրին։
Ահա այս մոտեցման դրական և բացասական կողմերը:
+ Արտադրված միջավայրի մեկուսացում
Այս մոտեցման շրջանակներում բոլոր միջավայրերը մեկուսացված են միմյանցից: Այնուամենայնիվ, գործնականում դա հատկապես կարևոր է արդյունահանվող միջավայրում:
Հավելվածի արտադրական տարբերակներն այժմ անկախ են այն բանից, թե ինչ է կատարվում այլ կլաստերներում և միջավայրերում:
Այս կերպ, եթե հանկարծակի խնդիր առաջանա dev կլաստերում, հավելվածների prod տարբերակները կշարունակեն աշխատել այնպես, կարծես ոչինչ չի եղել:
+ Կլաստերը կարող է հարմարեցվել շրջակա միջավայրին
Յուրաքանչյուր կլաստեր կարող է հարմարեցվել իր միջավայրին: Օրինակ, դուք կարող եք.
- տեղադրել գործիքներ մշակման և վրիպազերծման համար մշակողների կլաստերում;
- տեղադրել թեստային շրջանակներ և գործիքներ կլաստերում փորձարկում;
- օգտագործել ավելի հզոր ապարատային և ցանցային ալիքներ կլաստերում արտադրել.
Սա թույլ է տալիս բարձրացնել ինչպես հավելվածների մշակման, այնպես էլ շահագործման արդյունավետությունը:
+ Արտադրական կլաստերի մուտքի սահմանափակում
Արդյունքների կլաստերի հետ ուղղակիորեն աշխատելու անհրաժեշտությունը հազվադեպ է առաջանում, այնպես որ կարող եք զգալիորեն սահմանափակել այն մարդկանց շրջանակը, ովքեր հասանելի են դրան:
Դուք կարող եք ավելի հեռուն գնալ և ընդհանրապես արգելել մարդկանց մուտքը այս կլաստերին և կատարել բոլոր տեղակայումները՝ օգտագործելով ավտոմատացված CI/CD գործիք: Նման մոտեցումը նվազագույնի կհասցնի մարդկային սխալների ռիսկը հենց այնտեղ, որտեղ դա առավել կարևոր է:
Իսկ հիմա մի քանի խոսք մինուսների մասին։
- Ոչ մի մեկուսացում հավելվածների միջև
Մոտեցման հիմնական թերությունը հավելվածների միջև ապարատային և ռեսուրսների մեկուսացման բացակայությունն է:
Չկապված հավելվածները կիսում են կլաստերային ռեսուրսները՝ համակարգի միջուկը, պրոցեսորը, հիշողությունը և որոշ այլ ծառայություններ:
Ինչպես նշվեց, դա կարող է պոտենցիալ վտանգավոր լինել:
− Հավելվածի կախվածությունը տեղայնացնելու անկարողություն
Եթե դիմումն ունի հատուկ պահանջներ, ապա դրանք պետք է բավարարվեն բոլոր կլաստերներում:
Օրինակ, եթե հավելվածը պահանջում է GPU, ապա յուրաքանչյուր կլաստեր պետք է պարունակի GPU ունեցող առնվազն մեկ աշխատող (նույնիսկ եթե այն օգտագործվում է միայն այդ հավելվածի կողմից):
Արդյունքում մենք վտանգում ենք ավելի մեծ ծախսեր և ռեսուրսների անարդյունավետ օգտագործում:
Ամփոփում
Եթե դուք ունեք հավելվածների որոշակի փաթեթ, դրանք կարող են տեղադրվել մի քանի խոշոր կլաստերներում կամ շատ փոքրերում:
Հոդվածում քննարկվում են տարբեր մոտեցումների դրական և բացասական կողմերը՝ սկսած մեկ գլոբալ կլաստերից մինչև մի քանի փոքր և բարձր մասնագիտացված մոտեցումներ.
- մեկ մեծ ընդհանուր կլաստեր;
- շատ փոքր բարձր մասնագիտացված կլաստերներ;
- մեկ կլաստեր մեկ դիմումի համար;
- մեկ կլաստեր յուրաքանչյուր միջավայրում:
Այսպիսով, ո՞ր մոտեցումը պետք է որդեգրեք:
Ինչպես միշտ, պատասխանը կախված է օգտագործման դեպքից՝ պետք է կշռել տարբեր մոտեցումների դրական և բացասական կողմերը և ընտրել ամենաօպտիմալ տարբերակը:
Այնուամենայնիվ, ընտրությունը չի սահմանափակվում վերը նշված օրինակներով. կարող եք օգտագործել դրանց ցանկացած համակցություն:
Օրինակ, յուրաքանչյուր թիմի համար կարող եք կազմակերպել մի քանի կլաստերներ՝ զարգացման կլաստեր (որում կլինեն միջավայրեր դավ и փորձարկում) և կլաստերի համար արտադրություն (որտեղ կգտնվի արտադրական միջավայրը):
Այս հոդվածում ներկայացված տեղեկատվության հիման վրա դուք կարող եք համապատասխանաբար օպտիմալացնել դրական և բացասական կողմերը կոնկրետ սցենարի համար: Հաջողություն!
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «.
Source: www.habr.com