Քանի որ սկսում եք ստեղծել ավելի ու ավելի շատ Kubernetes ծառայություններ, առաջադրանքները, որոնք ի սկզբանե պարզ են, սկսում են ավելի բարդանալ: Օրինակ, զարգացման թիմերը չեն կարող ստեղծել ծառայություններ կամ տեղակայումներ նույն անունով: Եթե դուք ունեք հազարավոր պատյաններ, դրանք պարզապես ցուցակագրելը շատ ժամանակ կխլի, էլ չեմ խոսում դրանց ճիշտ կառավարման մասին: Եվ սա միայն այսբերգի գագաթն է:
Եկեք տեսնենք, թե ինչպես է անվանատարածքը հեշտացնում Kubernetes-ի ռեսուրսների կառավարումը: Այսպիսով, ինչ է անվանատարածքը: Անունների տարածքը կարելի է համարել որպես վիրտուալ կլաստեր ձեր Kubernetes կլաստերի մեջ: Դուք կարող եք ունենալ մի քանի անվանատարածքներ, որոնք մեկուսացված են միմյանցից մեկ Kubernetes կլաստերի մեջ: Նրանք իսկապես կարող են օգնել ձեզ և ձեր թիմերին կազմակերպման, անվտանգության և նույնիսկ համակարգի աշխատանքի հարցում:
Kubernetes բաշխումների մեծ մասում կլաստերը դուրս է գալիս տուփից «default» կոչվող անվանատարածքով: Իրականում կան երեք անվանատարածքներ, որոնց հետ առնչվում է Kubernetes-ը` default, kube-system և kube-public: Ներկայումս Kube-public-ը այնքան էլ հաճախ չի օգտագործվում։
Kube անվանումների տարածքը մենակ թողնելը լավ գաղափար է, հատկապես Google Kubernetes Engine-ի նման կառավարվող համակարգում: Այն օգտագործում է «կանխադրված» անվանատարածքը՝ որպես ձեր ծառայությունների և հավելվածների ստեղծման վայր: Դրանում բացարձակապես ոչ մի առանձնահատուկ բան չկա, բացառությամբ, որ Kubernetes-ը կազմաձևված է այն օգտագործելու համար, և դուք չեք կարող հեռացնել այն: Սա հիանալի է սկսելու և ցածր կատարողական համակարգերի համար, բայց ես խորհուրդ չեմ տա օգտագործել լռելյայն անվանատարածքը մեծ արդյունահանման համակարգերում: Վերջին դեպքում ծրագրավորողներից մեկը կարող է հեշտությամբ վերաշարադրել ուրիշի կոդը և կոտրել մեկ այլ թիմի աշխատանքը՝ նույնիսկ չհասկանալով:
Հետևաբար, դուք պետք է ստեղծեք բազմաթիվ անունների տարածքներ և օգտագործեք դրանք՝ ձեր ծառայությունները կառավարելի միավորների բաժանելու համար: Անվանատարածք կարելի է ստեղծել մեկ հրամանով: Եթե ցանկանում եք ստեղծել թեստ անունով անվանատարածք, ապա օգտագործեք հրամանը $ kubectl create namespace test կամ պարզապես ստեղծեք YAML ֆայլ և օգտագործեք այն Kubernetes-ի ցանկացած այլ ռեսուրսի նման:
Դուք կարող եք դիտել բոլոր անվանատարածքները՝ օգտագործելով $ kubectl get namespace հրամանը:
Ավարտելուց հետո դուք կտեսնեք երեք ներկառուցված անվանատարածք և նոր անվանատարածք, որը կոչվում է «test»: Եկեք նայենք պարզ YAML ֆայլին՝ պատիճ ստեղծելու համար: Դուք կնկատեք, որ անվանական տարածքի մասին խոսք չկա։
Եթե դուք օգտագործում եք kubectl այս ֆայլը գործարկելու համար, այն կստեղծի mypod մոդուլը ներկայումս ակտիվ անվանատարածքում: Սա կլինի լռելյայն անվանատարածքը, քանի դեռ չեք փոխել այն: Գոյություն ունի 2 եղանակ՝ ասելու Kubernetes-ին, թե որ անվանատարածքում եք ցանկանում ստեղծել ձեր ռեսուրսը: Առաջին ճանապարհը ռեսուրս ստեղծելիս անվանատարածքի դրոշակ օգտագործելն է:
Երկրորդ ճանապարհը YAML հռչակագրում անվանատարածք նշելն է:
Եթե YAML-ում նշեք անվանատարածք, ռեսուրսը միշտ կստեղծվի այդ անվանատարածքում: Եթե դուք փորձեք օգտագործել այլ անվանատարածք՝ օգտագործելով անվանատարածքի դրոշակը, հրամանը չի հաջողվի: Այժմ, եթե փորձեք գտնել ձեր պատիճը, չեք կարողանա դա անել:
Դա տեղի է ունենում, քանի որ բոլոր հրամանները կատարվում են ներկայումս ակտիվ անվանատարածքից դուրս: Ձեր pod գտնելու համար դուք պետք է օգտագործեք անվանատարածքի դրոշակ, բայց դա արագ ձանձրալի է դառնում, հատկապես, եթե դուք թիմի մշակող եք, որն օգտագործում է իր սեփական անվանատարածքը և չի ցանկանում օգտագործել այդ դրոշը յուրաքանչյուր հրամանի համար: Տեսնենք, թե ինչպես կարող ենք դա շտկել:
Ձեր ակտիվ անվանատարածքը կոչվում է լռելյայն: Եթե YAML ռեսուրսում անունների տարածք չեք նշում, ապա Kubernetes-ի բոլոր հրամանները կօգտագործեն այս ակտիվ լռելյայն անվանատարածքը: Ցավոք, kubectl-ի միջոցով ակտիվ անվանատարածքը կառավարելու փորձը կարող է ձախողվել: Այնուամենայնիվ, կա մի շատ լավ գործիք, որը կոչվում է Kubens, որը շատ ավելի հեշտ է դարձնում այս գործընթացը: Երբ գործարկում եք kubens հրամանը, դուք տեսնում եք բոլոր անվանատարածքները, որոնց ակտիվ անվանատարածքը ընդգծված է:
Ակտիվ անվանատարածքը թեստային անվանատարածք փոխելու համար պարզապես գործարկում եք $kubens թեստային հրամանը: Եթե այնուհետև նորից գործարկեք $kubens հրամանը, կտեսնեք, որ այժմ հատկացվել է նոր ակտիվ անվանատարածք՝ test:
Սա նշանակում է, որ ձեզ անհրաժեշտ չէ անվանատարածքի դրոշակը՝ տեստային անվանատարածքում պատիճը տեսնելու համար:
Այս կերպ անունների տարածքները թաքցվում են միմյանցից, բայց չեն մեկուսացվում միմյանցից: Ծառայությունը մեկ անվանատարածքում կարող է բավականին հեշտությամբ շփվել մեկ այլ անվանատարածքի ծառայության հետ, որը հաճախ շատ օգտակար է: Տարբեր անվանատարածքներով հաղորդակցվելու հնարավորությունը նշանակում է, որ ձեր մշակողների ծառայությունը կարող է շփվել մեկ այլ մշակողի թիմի ծառայության հետ այլ անունների տարածքում:
Սովորաբար, երբ ձեր հավելվածը ցանկանում է մուտք գործել Kubernetes ծառայություն, դուք օգտագործում եք ներկառուցված DNS հայտնաբերման ծառայությունը և պարզապես տալիս եք ձեր հավելվածին ծառայության անվանումը: Այնուամենայնիվ, դրանով դուք կարող եք ստեղծել ծառայություն նույն անունով մի քանի անունների տարածություններում, ինչը անընդունելի է:
Բարեբախտաբար, դա հեշտ է շրջանցել՝ օգտագործելով DNS հասցեի ընդլայնված ձևը: Kubernetes-ի ծառայությունները բացահայտում են իրենց վերջնակետերը՝ օգտագործելով ընդհանուր DNS ձևանմուշ: Դա նման բան է թվում.
Որպես կանոն, ձեզ պարզապես անհրաժեշտ է ծառայության անունը, և DNS-ն ավտոմատ կերպով կորոշի ամբողջական հասցեն:
Այնուամենայնիվ, եթե ձեզ անհրաժեշտ է ծառայության մուտք գործել այլ անվանատարածք, պարզապես օգտագործեք ծառայության անունը գումարած անվանատարածքի անունը.
Օրինակ, եթե ցանկանում եք միանալ ծառայության տվյալների բազայի թեստային անվանատարածքում, կարող եք օգտագործել հասցեների տվյալների բազայի տվյալների բազան.test.
Եթե ցանկանում եք միանալ ծառայության տվյալների բազային prod namespace-ում, դուք օգտագործում եք database.prod:
Եթե դուք իսկապես ցանկանում եք մեկուսացնել և սահմանափակել անունների տարածքի հասանելիությունը, Kubernetes-ը թույլ է տալիս դա անել՝ օգտագործելով Kubernetes ցանցային քաղաքականությունը: Այս մասին կխոսեմ հաջորդ դրվագում:
Ինձ հաճախ հարց են տալիս՝ քանի՞ անվանատարածք պետք է ստեղծեմ և ի՞նչ նպատակով: Ի՞նչ է կառավարվող տվյալների բաժինը:
Եթե դուք ստեղծեք չափազանց շատ անունների տարածքներ, դրանք պարզապես կխանգարեն ձեր ճանապարհին: Եթե դրանք շատ քիչ լինեն, դուք կկորցնեք նման լուծման բոլոր առավելությունները: Կարծում եմ՝ կան չորս հիմնական փուլեր, որոնց միջով անցնում է յուրաքանչյուր ընկերություն իր կազմակերպչական կառուցվածքը ստեղծելիս։ Կախված ձեր նախագծի կամ ընկերության զարգացման փուլից, դուք կարող եք որդեգրել համապատասխան անվանատարածքի ռազմավարություն:
Պատկերացրեք, որ դուք փոքր թիմի մի մասն եք, որն աշխատում է 5-10 միկրոսերվիսների մշակման վրա, և կարող եք հեշտությամբ հավաքել բոլոր մշակողներին մեկ սենյակում: Այս իրավիճակում իմաստ ունի գործարկել բոլոր prod ծառայությունները լռելյայն անվանատարածքում: Իհարկե, ավելի ճկունության համար կարող եք օգտագործել 2 անվանատարածք՝ առանձին՝ prod-ի և dev-ի համար: Եվ, ամենայն հավանականությամբ, դուք փորձարկում եք ձեր զարգացումը ձեր տեղական համակարգչի վրա՝ օգտագործելով Minikube-ի նման մի բան:
Եկեք ասենք, որ ամեն ինչ փոխվում է, և դուք այժմ ունեք արագ աճող թիմ, որը միաժամանակ աշխատում է ավելի քան 10 միկրոծառայությունների վրա: Գալիս է մի պահ, երբ անհրաժեշտ է օգտագործել մի քանի կլաստերներ կամ անվանատարածքներ՝ առանձին prod-ի և dev-ի համար: Դուք կարող եք թիմը բաժանել մի քանի ենթախմբերի, որպեսզի նրանցից յուրաքանչյուրն ունենա իր միկրոծառայությունները, և այդ թիմերից յուրաքանչյուրը կարողանա ընտրել իր անվանատարածքը՝ հեշտացնելու ծրագրային ապահովման մշակման և թողարկման կառավարման գործընթացը:
Քանի որ թիմի յուրաքանչյուր անդամ պատկերացում է ստանում այն մասին, թե ինչպես է ամբողջ համակարգը աշխատում, ավելի ու ավելի դժվար է դառնում յուրաքանչյուր փոփոխություն համակարգել մյուս բոլոր մշակողների հետ: Ձեր տեղական մեքենայի վրա ամբողջ փաթեթը պտտելու փորձն օրեցօր ավելի դժվար է դառնում:
Խոշոր ընկերություններում մշակողները հիմնականում չգիտեն, թե կոնկրետ ով ինչի վրա է աշխատում: Թիմերը շփվում են ծառայության պայմանագրերի միջոցով կամ օգտագործում են սպասարկման ցանցի տեխնոլոգիա, որն ավելացնում է աբստրակցիոն շերտ ցանցի վրա, ինչպիսին է Istio կազմաձևման գործիքը: Ամբողջ փաթեթը լոկալ կերպով աշխատեցնելը պարզապես հնարավոր չէ: Ես խորհուրդ եմ տալիս օգտագործել շարունակական առաքման (CD) հարթակ, ինչպիսին է Spinnaker-ը Kubernetes-ում: Այսպիսով, գալիս է մի կետ, որտեղ յուրաքանչյուր հրամանի անպայման պետք է իր սեփական անվանատարածքը: Յուրաքանչյուր թիմ կարող է նույնիսկ ընտրել մի քանի անվանատարածքներ մշակողի միջավայրի և պրոդ միջավայրի համար:
Վերջապես, կան խոշոր ձեռնարկատիրական ընկերություններ, որոնցում ծրագրավորողների մի խումբ նույնիսկ չգիտի այլ խմբերի գոյության մասին։ Նման ընկերությունն ընդհանուր առմամբ կարող է վարձել երրորդ կողմի մշակողների, ովքեր համագործակցում են դրա հետ լավ փաստաթղթավորված API-ների միջոցով: Յուրաքանչյուր նման խումբ պարունակում է մի քանի թիմեր և մի քանի միկրոծառայություններ: Այս դեպքում դուք պետք է օգտագործեք բոլոր այն գործիքները, որոնց մասին ես ավելի վաղ խոսեցի:
Ծրագրավորողները չպետք է ձեռքով գործարկեն ծառայություններ և չպետք է մուտք ունենան իրենց չվերաբերող անունների տարածքներ: Այս փուլում նպատակահարմար է ունենալ մի քանի կլաստերներ՝ վատ կազմաձևված հավելվածների «պայթյունի շառավիղը» նվազեցնելու, վճարային գործընթացները և ռեսուրսների կառավարումը պարզեցնելու համար:
Այսպիսով, ձեր կազմակերպության կողմից անվանատարածքների ճիշտ օգտագործումը թույլ է տալիս Kubernetes-ը դարձնել ավելի կառավարելի, կառավարելի, անվտանգ և ճկուն:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com