Ղեկի անվտանգություն

Kubernetes-ի համար ամենահայտնի փաթեթների մենեջերի մասին պատմության էությունը կարելի է պատկերել emoji-ի միջոցով.

• տուփը Helm է (որը ամենամոտն է Emoji-ի վերջին թողարկմանը);
• կողպեք - անվտանգություն;
• փոքրիկ մարդը խնդրի լուծումն է.

Իրականում ամեն ինչ մի փոքր ավելի բարդ է լինելու, և պատմությունը լի է տեխնիկական մանրամասներով Ինչպես դարձնել Helm անվտանգ.

• Համառոտ, թե ինչ է Helm-ը, եթե դուք չգիտեիք կամ մոռացել եք: Ի՞նչ խնդիրներ է այն լուծում և որտեղ է գտնվում էկոհամակարգում։
• Եկեք նայենք Հելմի ճարտարապետությանը: Անվտանգության և գործիքը կամ լուծումն ավելի անվտանգ դարձնելու մասին ոչ մի խոսակցություն ամբողջական չէ՝ առանց բաղադրիչի ճարտարապետությունը հասկանալու:
• Եկեք քննարկենք «Helm»-ի բաղադրիչները:
• Ամենաբորբոքված հարցը ապագան է՝ Helm 3-ի նոր տարբերակը: 

Այս հոդվածում ամեն ինչ վերաբերում է Helm 2-ին: Այս տարբերակը ներկայումս արտադրվում է և, ամենայն հավանականությամբ, այն է, որը դուք ներկայումս օգտագործում եք, և դա այն տարբերակն է, որը պարունակում է անվտանգության ռիսկեր:

Բանախոսի մասին. Ալեքսանդր Խայորով (allexx) զարգանում է արդեն 10 տարի՝ նպաստելով բովանդակության բարելավմանը Մոսկվայի Python Conf++ և անդամագրվել է կոմիտեին Helm Summit. Այժմ նա աշխատում է Chainstack-ում որպես զարգացման առաջատար. սա հիբրիդ է զարգացման մենեջերի և այն անձի միջև, ով պատասխանատու է վերջնական թողարկումների մատուցման համար: Այսինքն՝ այն գտնվում է մարտի դաշտում, որտեղ ամեն ինչ տեղի է ունենում ապրանքի ստեղծումից մինչև դրա գործարկումը։

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

սաղավարտ

Սա փաթեթի (գծապատկեր) կառավարիչ է Kubernetes-ի համար: Ամենաինտուիտիվ և ունիվերսալ միջոցը՝ հավելվածները Kubernetes կլաստերին բերելու համար:

Մենք, իհարկե, խոսում ենք ավելի կառուցվածքային և արդյունաբերական մոտեցման մասին, քան ձեր սեփական YAML մանիֆեստներ ստեղծելը և փոքր կոմունալ ծառայություններ գրելը:

Helm-ը լավագույնն է, որը ներկայումս հասանելի է և հայտնի:

Ինչու՞ Հելմը: Հիմնականում այն ​​պատճառով, որ այն աջակցվում է CNCF-ի կողմից: Cloud Native-ը խոշոր կազմակերպություն է և հանդիսանում է Kubernetes, etcd, Fluentd և այլ նախագծերի մայր ընկերություն:

Մեկ այլ կարևոր փաստ այն է, որ Helm-ը շատ սիրված նախագիծ է: Երբ 2019 թվականի հունվարին սկսեցի խոսել այն մասին, թե ինչպես Հելմը անվտանգ դարձնել, նախագիծն ուներ հազար աստղ GitHub-ում: մայիսին նրանց թիվը 12 հազար էր։

Շատերը հետաքրքրված են Helm-ով, այնպես որ, նույնիսկ եթե դեռ չեք օգտագործում այն, դուք կշահեք դրա անվտանգության մասին իմանալուց: Անվտանգությունը կարևոր է։

Հիմնական Helm թիմը աջակցվում է Microsoft Azure-ի կողմից և, հետևաբար, բավականին կայուն նախագիծ է, ի տարբերություն շատերի: Հուլիսի կեսերին Helm 3 Alpha 2-ի թողարկումը ցույց է տալիս, որ նախագծի վրա բավականին շատ մարդիկ են աշխատում, և նրանք ցանկություն և էներգիա ունեն զարգացնելու և կատարելագործելու Helm-ը:

Helm-ը լուծում է հավելվածների կառավարման մի քանի հիմնախնդիր Kubernetes-ում:

• Դիմումի փաթեթավորում. Նույնիսկ WordPress-ի «Բարև, աշխարհ» հավելվածն արդեն բաղկացած է մի քանի ծառայություններից, և դուք ցանկանում եք դրանք փաթեթավորել միասին:
• Այս հավելվածների կառավարման հետ կապված բարդության կառավարում:
• Կյանքի ցիկլ, որը չի ավարտվում հավելվածի տեղադրումից կամ գործարկումից հետո: Այն շարունակում է ապրել, այն պետք է թարմացվի, և Հելմը օգնում է դրան և փորձում է ճիշտ միջոցներ և քաղաքականություն ձեռնարկել դրա համար:

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

Բարդության կառավարում. Եթե ​​ունեք նույն տիպի բազմաթիվ հավելվածներ, ապա պարամետրացում է անհրաժեշտ: Կաղապարները գալիս են դրանից, բայց որպեսզի չառաջարկեք ձևանմուշներ ստեղծելու ձեր սեփական ձևը, կարող եք օգտագործել այն, ինչ Helm-ն առաջարկում է առանց տուփի:

Հավելվածի կյանքի ցիկլի կառավարում -Իմ կարծիքով՝ սա ամենահետաքրքիր ու չլուծված հարցն է։ Ահա թե ինչու ես այն օրը եկա Հելմ: Մենք պետք է հետևեինք հավելվածի կյանքի ցիկլին և ցանկանում էինք տեղափոխել մեր CI/CD և կիրառման ցիկլերը այս պարադիգմում:

Helm-ը թույլ է տալիս.

• կառավարել տեղակայումները, ներկայացնում է կոնֆիգուրացիայի և վերանայման հայեցակարգը.
• հաջողությամբ իրականացնել հետադարձ կապ;
• օգտագործել կեռիկներ տարբեր իրադարձությունների համար;
• ավելացնել հավելվածների լրացուցիչ ստուգումներ և արձագանքել դրանց արդյունքներին:

Դեռ ավելին Սաղավարտն ունի «մարտկոցներ» - հսկայական քանակությամբ համեղ բաներ, որոնք կարող են ներառվել պլագինների տեսքով՝ հեշտացնելով ձեր կյանքը: Փլագինները կարող են գրվել ինքնուրույն, դրանք բավականին մեկուսացված են և ներդաշնակ ճարտարապետություն չեն պահանջում։ Եթե ​​ցանկանում եք ինչ-որ բան իրականացնել, ես խորհուրդ եմ տալիս դա անել որպես plugin, այնուհետև հնարավոր է ներառել հոսանքին հակառակ:

Helm-ը հիմնված է երեք հիմնական հասկացությունների վրա.

• Chart Repo — Ձեր մանիֆեստի համար հնարավոր պարամետրերի նկարագրություն և զանգված: 
• Config -այսինքն այն արժեքները, որոնք կկիրառվեն (տեքստ, թվային արժեքներ և այլն):
• Ազատ հավաքում է երկու վերին բաղադրիչները, և դրանք միասին վերածվում են Release-ի: Թողարկումները կարող են տարբերակվել՝ դրանով իսկ հասնելով կազմակերպված կյանքի ցիկլի՝ փոքր տեղադրման պահին և մեծ՝ արդիականացման, իջեցման կամ վերադարձի ժամանակ:

Սաղավարտի ճարտարապետություն

Դիագրամը կոնցեպտուալ կերպով պատկերում է Հելմի բարձր մակարդակի ճարտարապետությունը:

Հիշեցնեմ, որ Հելմը Կուբերնետեսի հետ կապված մի բան է։ Հետևաբար, մենք չենք կարող անել առանց Kubernetes կլաստերի (ուղղանկյուն): Kube-apiserver բաղադրիչը գտնվում է վարպետի վրա: Առանց Helm մենք ունենք Kubeconfig: Helm-ը բերում է մեկ փոքր երկուական, եթե կարելի է այդպես անվանել, Helm CLI կոմունալ, որը տեղադրված է համակարգչի, նոութբուքի, հիմնական սարքի վրա՝ ցանկացած բանի վրա:

Բայց սա բավարար չէ։ Helm-ն ունի սերվերի բաղադրիչ, որը կոչվում է Tiller: Այն ներկայացնում է Helm-ի շահերը կլաստերի ներսում, այն հավելված է Kubernetes կլաստերի ներսում, ինչպես ցանկացած այլ:

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

Փոխազդեցություն

Եկեք նայենք, թե ինչպես են փոխազդում ճարտարապետության բաղադրիչները, երբ մենք ցանկանում ենք տեղադրել հավելված՝ օգտագործելով Helm-ը:

• Մենք խոսում ենք Helm install, մուտք գործեք պահեստ (Chart Repo) և ստացեք Helm աղյուսակը:

• Helm utility-ը (Helm CLI) փոխազդում է Kubeconfig-ի հետ՝ պարզելու, թե որ կլաստերին կապվել: 
• Ստանալով այս տեղեկությունը՝ կոմունալը որպես հավելված դիմում է Tiller-ին, որը գտնվում է մեր կլաստերում: 
• Թիլերը կանչում է Kube-apiserver-ին Kubernetes-ում գործողություններ կատարելու, որոշ օբյեկտներ ստեղծելու համար (ծառայություններ, պատիճներ, կրկնօրինակներ, գաղտնիքներ և այլն):

Հաջորդը, մենք կբարդացնենք դիագրամը՝ տեսնելու հարձակման վեկտորը, որին կարող է ենթարկվել ամբողջ Helm ճարտարապետությունը, որպես ամբողջություն: Եվ հետո մենք կփորձենք պաշտպանել նրան:

Հարձակման վեկտոր

Առաջին պոտենցիալ թույլ կետն է արտոնյալ API-օգտագործողը. Որպես սխեմայի մաս, սա հաքեր է, ով ստացել է ադմինիստրատորի մուտք դեպի Helm CLI:

Ոչ արտոնյալ API օգտվող կարող է նաև վտանգ ներկայացնել, եթե այն գտնվում է մոտակայքում: Նման օգտվողը կունենա այլ համատեքստ, օրինակ, նա կարող է ֆիքսվել մեկ կլաստերային անվանատարածքում՝ Kubeconfig կարգավորումներում։

Ամենահետաքրքիր հարձակման վեկտորը կարող է լինել մի գործընթաց, որը գտնվում է կլաստերի մեջ ինչ-որ տեղ Թիլերի մոտ և կարող է մուտք գործել դրան: Սա կարող է լինել վեբ սերվեր կամ միկրոսերվիս, որը տեսնում է կլաստերի ցանցային միջավայրը:

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

Փորձենք զսպել հարձակումները բոլոր այս չորս կողմերից և պարզել, թե որտեղ կան խնդիրներ Helm ճարտարապետության մեջ, և որտեղ, հավանաբար, չկան:

Եկեք մեծացնենք դիագրամը, ավելացնենք ավելի շատ տարրեր, բայց պահպանենք բոլոր հիմնական բաղադրիչները:

Helm CLI-ը շփվում է Chart Repo-ի հետ, փոխազդում է Kubeconfig-ի հետ, և աշխատանքը տեղափոխվում է կլաստեր՝ Tiller բաղադրիչ:

Թիլլերը ներկայացված է երկու առարկայով.

• Tiller-deploy svc, որը բացահայտում է որոշակի ծառայություն;
• Tiller-deploy pod (գծապատկերում մեկ օրինակով մեկ կրկնօրինակում), որի վրա աշխատում է ամբողջ բեռը, որը մուտք է գործում կլաստեր:

Փոխազդեցության համար օգտագործվում են տարբեր արձանագրություններ և սխեմաներ: Անվտանգության տեսանկյունից մեզ ամենից շատ հետաքրքրում է.

• Մեխանիզմը, որով Helm CLI-ն մուտք է գործում գծապատկերային ռեպո. ի՞նչ արձանագրություն, կա՞ արդյոք նույնականացում և ինչ կարելի է անել դրա հետ:
• Արձանագրությունը, որով Helm CLI-ն, օգտագործելով kubectl, շփվում է Թիլերի հետ։ Սա RPC սերվեր է, որը տեղադրված է կլաստերի ներսում:
• Tiller-ն ինքնին հասանելի է միկրոծառայությունների համար, որոնք բնակվում են կլաստերում և փոխազդում են Kube-apiserver-ի հետ:

Եկեք քննարկենք այս բոլոր ոլորտները հերթականությամբ:

RBAC

Անիմաստ է խոսել Helm-ի կամ կլաստերի ներսում որևէ այլ ծառայության անվտանգության մասին, քանի դեռ RBAC-ը միացված չէ:

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

https://rbac.dev/ — կայքի իրավաբան RBAC-ի համար: Այն պարունակում է հսկայական քանակությամբ հետաքրքիր նյութեր, որոնք կօգնեն ձեզ ստեղծել RBAC, ցույց տալ, թե ինչու է այն լավ և ինչպես հիմնականում ապրել դրա հետ արտադրության մեջ:

Ես կփորձեմ բացատրել, թե ինչպես են աշխատում Tiller-ը և RBAC-ը: Tiller-ն աշխատում է կլաստերի ներսում որոշակի սպասարկման հաշվի ներքո: Սովորաբար, եթե RBAC-ը կազմաձևված չէ, սա կլինի գերօգտագործողը: Հիմնական կազմաձևում Tiller-ը կլինի ադմինիստրատոր: Ահա թե ինչու է հաճախ ասում, որ Tiller-ը SSH թունել է ձեր կլաստերի համար: Իրականում, դա ճիշտ է, այնպես որ դուք կարող եք օգտագործել առանձին հատուկ սպասարկման հաշիվ վերևի դիագրամում նշված Կանխադրված ծառայության հաշվի փոխարեն:

Երբ դուք սկզբնավորում եք Helm-ը և այն տեղադրում սերվերի վրա առաջին անգամ, կարող եք կարգավորել ծառայության հաշիվը՝ օգտագործելով --service-account. Սա թույլ կտա Ձեզ օգտվել նվազագույն պահանջվող իրավունքների փաթեթով օգտվողից: Ճիշտ է, դուք ստիպված կլինեք ստեղծել այսպիսի «ծաղկեպսակ»՝ Role and RoleBinding:

Ցավոք, Հելմը դա չի անի ձեզ համար: Դուք կամ ձեր Kubernetes կլաստերի ադմինիստրատորը պետք է նախօրոք պատրաստեք Roles-ի և RoleBindings-ի մի շարք ծառայության հաշվի համար, որպեսզի անցնեք Helm-ը:

Հարց է առաջանում՝ ո՞րն է տարբերությունը Role-ի և ClusterRole-ի միջև։ Տարբերությունն այն է, որ ClusterRole-ն աշխատում է բոլոր անվանատարածքների համար, ի տարբերություն սովորական Roles-ի և RoleBindings-ի, որոնք աշխատում են միայն մասնագիտացված անվանատարածքի համար։ Դուք կարող եք կարգավորել քաղաքականություններ ամբողջ կլաստերի և բոլոր անվանատարածքների համար, կամ անհատականացնել յուրաքանչյուր անվանատարածքի համար առանձին:

Հարկ է նշել, որ RBAC-ը լուծում է ևս մեկ մեծ խնդիր. Շատերը բողոքում են, որ Հելմը, ցավոք, բազմատենասություն չէ (չի աջակցում բազմատենչությանը): Եթե ​​մի քանի թիմեր օգտագործում են կլաստերը և օգտագործում են Helm-ը, հիմնականում անհնար է ստեղծել քաղաքականություն և սահմանափակել նրանց մուտքն այս կլաստերի ներսում, քանի որ կա որոշակի ծառայության հաշիվ, որի տակ աշխատում է Helm-ը, և այն ստեղծում է կլաստերի բոլոր ռեսուրսները դրա տակից: , որը երբեմն շատ անհարմար է: Սա ճիշտ է, ինչպես ինքնին երկուական ֆայլը, ինչպես գործընթացը, Հելմ Թիլլերը բազմավարձակալության գաղափար չունի.

Այնուամենայնիվ, կա հիանալի միջոց, որը թույլ է տալիս մի քանի անգամ գործարկել Tiller-ը կլաստերի մեջ: Սրա հետ կապված խնդիր չկա, Tiller-ը կարող է գործարկվել յուրաքանչյուր անվանատարածքում: Այսպիսով, դուք կարող եք օգտագործել RBAC-ը, Kubeconfig-ը որպես համատեքստ և սահմանափակել մուտքը դեպի հատուկ Helm:

Այն այսպիսի տեսք կունենա.

Օրինակ, կան երկու Kubeconfig՝ տարբեր թիմերի համար համատեքստով (երկու անվանատարածք). Ադմինիստրատորի կլաստերն ունի իր լայն Tiller-ը, որը գտնվում է Kube-system namespace-ում՝ համապատասխանաբար առաջադեմ սպասարկման հաշիվ: Եվ մշակողների թիմի համար առանձին անվանատարածք, նրանք կկարողանան տեղակայել իրենց ծառայությունները հատուկ անվանատարածքում:

Սա գործունակ մոտեցում է, Թիլլերը այնքան էլ ուժասպառ չէ, որ դա մեծապես ազդի ձեր բյուջեի վրա: Սա արագ լուծումներից մեկն է։

Ազատորեն կարգավորեք Tiller-ը առանձին և տրամադրեք Kubeconfig-ին համատեքստ թիմի, կոնկրետ մշակողի կամ շրջակա միջավայրի համար՝ Dev, Staging, Production (կասկածելի է, որ ամեն ինչ կլինի նույն կլաստերի վրա, այնուամենայնիվ, դա հնարավոր է անել):

Շարունակելով մեր պատմությունը՝ եկեք անցնենք RBAC-ից և խոսենք ConfigMaps-ի մասին:

ConfigMaps

Helm-ն օգտագործում է ConfigMaps-ը որպես տվյալների պահեստ: Երբ մենք խոսում էինք ճարտարապետության մասին, ոչ մի տեղ չկար տվյալների բազա, որը կպահեր տեղեկատվություն թողարկումների, կոնֆիգուրացիաների, հետադարձումների և այլնի մասին: Դրա համար օգտագործվում է ConfigMaps-ը:

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

Սա արվում է շատ պարզ. Անտեսեք Tiller-ի կարգավորումը և նշեք, որ պահեստը գաղտնիք է լինելու: Այնուհետև յուրաքանչյուր տեղակայման համար դուք կստանաք ոչ թե ConfigMap, այլ գաղտնիք:

Դուք կարող եք պնդել, որ գաղտնիքներն ինքնին տարօրինակ հասկացություն են և ոչ այնքան ապահով: Այնուամենայնիվ, արժե հասկանալ, որ Kubernetes-ի մշակողները իրենք են դա անում: Սկսած 1.10 տարբերակից, այսինքն. Արդեն բավական ժամանակ է, ինչ հնարավոր է եղել, գոնե հանրային ամպերում, ճիշտ պահեստը միացնել գաղտնիքները պահելուն: Թիմն այժմ աշխատում է գաղտնիքների, անհատական ​​պատյանների կամ այլ օբյեկտների հասանելիությունը ավելի լավ բաշխելու ուղիների վրա:

Ավելի լավ է Storage Helm-ը փոխանցել գաղտնիքներին, և դրանք, իրենց հերթին, ապահովված են կենտրոնական մասում:

Իհարկե կմնա տվյալների պահպանման սահմանաչափը 1 ՄԲ. Helm-ն այստեղ օգտագործում է etcd-ը որպես ConfigMaps-ի բաշխված պահեստ: Եվ այնտեղ նրանք համարեցին, որ սա համապատասխան տվյալների կտոր է կրկնօրինակման համար և այլն։ Այս մասին հետաքրքիր քննարկում կա Reddit-ում, խորհուրդ եմ տալիս գտնել այս զվարճալի ընթերցումը հանգստյան օրերին կամ կարդալ հատվածը այստեղ.

Chart Repos

Գծապատկերները սոցիալապես ամենախոցելիներն են և կարող են դառնալ «Մի մեջտեղում գտնվող մարդը», հատկապես եթե դուք օգտագործում եք ֆոնդային լուծում: Առաջին հերթին, մենք խոսում ենք HTTP-ի միջոցով բացահայտված պահոցների մասին:

Դուք անպայման պետք է բացահայտեք Helm Repo-ն HTTPS-ի միջոցով. սա լավագույն տարբերակն է և էժան:

Ուշադրություն դարձրեք գծապատկերի ստորագրման մեխանիզմ. Տեխնոլոգիան դժոխքի պես պարզ է: Սա նույն բանն է, ինչ դուք օգտագործում եք GitHub-ում՝ սովորական PGP մեքենա՝ հանրային և մասնավոր ստեղներով: Ստեղծեք և համոզվեք, ունենալով անհրաժեշտ բանալիները և ստորագրելով ամեն ինչ, որ սա իսկապես ձեր աղյուսակն է:

Բացի այդ, Helm հաճախորդը աջակցում է TLS-ին (ոչ թե սերվերի կողմից HTTP իմաստով, այլ փոխադարձ TLS): Շփվելու համար կարող եք օգտագործել սերվերի և հաճախորդի ստեղները: Անկեղծ ասած, ես նման մեխանիզմ չեմ կիրառում, քանի որ չեմ սիրում փոխադարձ վկայականներ։ Հիմնականում, քարտեզ թանգարան - Helm Repo-ի ստեղծման հիմնական գործիքը Helm 2-ի համար - նաև աջակցում է հիմնական վավերացմանը: Դուք կարող եք օգտագործել հիմնական վավերացումը, եթե դա ավելի հարմար է և հանգիստ:

Կա նաև plugin ղեկ-gcs, որը թույլ է տալիս հյուրընկալել Chart Repos-ը Google Cloud Storage-ում: Սա բավականին հարմար է, հիանալի է աշխատում և բավականին անվտանգ է, քանի որ նկարագրված բոլոր մեխանիզմները վերամշակվում են:

Եթե ​​միացնեք HTTPS-ը կամ TLS-ը, օգտագործեք mTLS և միացնեք հիմնական հաստատումը ռիսկերը հետագայում նվազեցնելու համար, դուք կստանաք ապահով հաղորդակցման ալիք Helm CLI-ի և Chart Repo-ի հետ:

gRPC API

Հաջորդ քայլը շատ կարևոր է՝ ապահովել Tiller-ը, որը գտնվում է կլաստերի մեջ և մի կողմից սերվեր է, մյուս կողմից՝ նա ինքն է մուտք գործում այլ բաղադրիչներ և փորձում է ինչ-որ մեկը ձևանալ։

Ինչպես արդեն ասացի, Tiller-ը ծառայություն է, որը բացահայտում է gRPC-ն, Helm-ի հաճախորդը գալիս է դրան gRPC-ի միջոցով: Լռելյայն, իհարկե, TLS-ն անջատված է: Ինչու դա արվեց, վիճելի հարց է, ինձ թվում է, որ սկզբից պարզեցնում եմ կարգավորումը:

Արտադրության և նույնիսկ բեմադրության համար խորհուրդ եմ տալիս միացնել TLS-ը gRPC-ում:

Իմ կարծիքով, ի տարբերություն mTLS գծապատկերների, սա տեղին է այստեղ և արվում է շատ պարզ՝ ստեղծել PQI ենթակառուցվածք, ստեղծել վկայագիր, գործարկել Tiller, փոխանցել վկայագիրը սկզբնավորման ժամանակ։ Դրանից հետո դուք կարող եք կատարել Helm-ի բոլոր հրամանները՝ ներկայացնելով ձեզ գեներացված վկայականը և անձնական բանալին:

Այս կերպ դուք կպաշտպանեք ձեզ կլաստերի դրսից Թիլլերին ուղղված բոլոր խնդրանքներից:

Այսպիսով, մենք ապահովել ենք միացման ալիքը Tiller-ին, մենք արդեն քննարկել ենք RBAC-ը և ճշգրտել Kubernetes apiserver-ի իրավունքները՝ նվազեցնելով այն տիրույթը, որի հետ այն կարող է փոխազդել։

Պաշտպանված ղեկ

Եկեք նայենք վերջնական դիագրամին: Նույն ճարտարապետությունն է՝ նույն սլաքներով:

Բոլոր կապերն այժմ կարող են ապահով կերպով գծվել կանաչ գույնով.

• Chart Repo-ի համար մենք օգտագործում ենք TLS կամ mTLS և հիմնական վավերացում;
• mTLS Tiller-ի համար, և այն ցուցադրվում է որպես gRPC ծառայություն TLS-ով, մենք օգտագործում ենք վկայագրեր.
• կլաստերը օգտագործում է հատուկ ծառայության հաշիվ Role-ի և RoleBinding-ի հետ: 

Մենք զգալիորեն ապահովեցինք կլաստերը, բայց ինչ-որ խելացի ասաց.

«Կարող է լինել միայն մեկ բացարձակապես անվտանգ լուծում՝ անջատված համակարգիչը, որը գտնվում է բետոնե տուփի մեջ և պահպանվում է զինվորների կողմից»։

Տվյալները շահարկելու և հարձակման նոր վեկտորներ գտնելու տարբեր եղանակներ կան: Այնուամենայնիվ, ես վստահ եմ, որ այս առաջարկությունները կհասնեն անվտանգության հիմնական արդյունաբերության ստանդարտին:

Շահութաբաժին

Այս մասն անմիջականորեն կապված չէ անվտանգության հետ, բայց նաև օգտակար կլինի։ Ես ձեզ ցույց կտամ մի քանի հետաքրքիր բաներ, որոնց մասին քչերը գիտեն: Օրինակ՝ ինչպես որոնել գծապատկերներ՝ պաշտոնական և ոչ պաշտոնական:

Պահեստում github.com/helm/charts Այժմ կա մոտ 300 գծապատկեր և երկու հոսք՝ կայուն և ինկուբատոր։ Յուրաքանչյուր ոք, ով նպաստում է, լավ գիտի, թե որքան դժվար է ինկուբատորից ախոռ հասնելը և որքան հեշտ է թռչել ախոռից: Այնուամենայնիվ, սա Prometheus-ի և ցանկացած այլ ցանկի համար գծապատկերներ որոնելու լավագույն գործիքը չէ, մի պարզ պատճառով. դա պորտալ չէ, որտեղ դուք կարող եք հարմար որոնել փաթեթներ:

Բայց կա ծառայություն hub.helm.sh, ինչը շատ ավելի հարմար է դարձնում գծապատկերներ գտնելը: Ամենակարևորն այն է, որ կան շատ ավելի շատ արտաքին պահոցներ և հասանելի գրեթե 800 հմայք: Բացի այդ, դուք կարող եք միացնել ձեր պահեստը, եթե ինչ-ինչ պատճառներով չեք ցանկանում ուղարկել ձեր գծապատկերները կայուն:

Փորձեք hub.helm.sh-ը և եկեք զարգացնենք այն միասին: Այս ծառայությունը գտնվում է Helm նախագծի ներքո, և դուք կարող եք նույնիսկ նպաստել դրա միջերեսին, եթե դուք առաջնային ծրագրավորող եք և պարզապես ցանկանում եք բարելավել արտաքինը:

Կցանկանայի նաև ձեր ուշադրությունը հրավիրել Open Service Broker API-ի ինտեգրում. Այն հնչում է ծանր ու անհասկանալի, բայց լուծում է այն խնդիրները, որոնց բախվում են բոլորը: Պարզ օրինակով բացատրեմ.

Կա Kubernetes կլաստեր, որում մենք ցանկանում ենք գործարկել դասական հավելված՝ WordPress: Ընդհանուր առմամբ, ամբողջական ֆունկցիոնալության համար անհրաժեշտ է տվյալների բազա: Կան բազմաթիվ տարբեր լուծումներ, օրինակ՝ կարող եք գործարկել ձեր սեփական պետական ​​ծառայությունը: Սա այնքան էլ հարմար չէ, բայց շատերն են դա անում։

Մյուսները, ինչպես մենք Chainstack-ում, օգտագործում են կառավարվող տվյալների բազաներ, ինչպիսիք են MySQL-ը կամ PostgreSQL-ն իրենց սերվերների համար: Ահա թե ինչու մեր տվյալների բազաները գտնվում են ինչ-որ տեղ ամպի մեջ:

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

Դա շատ պարզ է. Դուք կարող եք հարցումներ կատարել, օրինակ, Managed MySQL-ը Azure-ում բազային մակարդակով (սա կարող է կազմաձևվել): Օգտագործելով Azure API-ն, տվյալների բազան կստեղծվի և կպատրաստվի օգտագործման համար: Պետք չէ դրան խանգարել, դրա համար պատասխանատու է plugin-ը: Օրինակ, OSBA-ն (Azure plugin) կվերադարձնի հավատարմագրերը ծառայությանը և կփոխանցի այն Helm-ին: Դուք կկարողանաք օգտագործել WordPress-ը ամպային MySQL-ով, ընդհանրապես չզբաղվել կառավարվող տվյալների բազաներով և չանհանգստանալ ներսում գտնվող պետական ​​ծառայությունների համար:

Կարելի է ասել, որ Helm-ը գործում է որպես սոսինձ, որը մի կողմից թույլ է տալիս տեղակայել ծառայություններ, իսկ մյուս կողմից՝ սպառել ամպային մատակարարների ռեսուրսները։

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

Մեկ այլ գտածո, որը ես արդեն նշեցի, սա է helm-gcs plugin, որը թույլ է տալիս օգտագործել Google-buckets (օբյեկտների պահեստավորում)՝ Helm գծապատկերները պահելու համար։

Այն օգտագործելու համար անհրաժեշտ է ընդամենը չորս հրաման.

1. տեղադրել plugin;
2. նախաձեռնել այն;
3. սահմանեք ուղին դեպի դույլ, որը գտնվում է gcp-ում;
4. հրապարակել գծապատկերները ստանդարտ ձևով:

Գեղեցկությունն այն է, որ թույլտվության համար կօգտագործվի հայրենի gcp մեթոդը: Դուք կարող եք օգտագործել ծառայության հաշիվը, մշակողի հաշիվը, ինչ ուզում եք: Այն շատ հարմար է և գործելու համար ոչինչ չի պահանջում: Եթե ​​դուք, ինչպես և ես, առաջ եք մղում անպարկեշտ փիլիսոփայությունը, ապա սա շատ հարմար կլինի հատկապես փոքր թիմերի համար:

Այլընտրանքները

Helm-ը ծառայության կառավարման միակ լուծումը չէ: Դրա հետ կապված շատ հարցեր կան, ինչի պատճառով էլ երեւի երրորդ տարբերակը հայտնվեց այդքան արագ։ Իհարկե, կան այլընտրանքներ։

Դրանք կարող են լինել մասնագիտացված լուծումներ, օրինակ՝ Ksonnet կամ Metaparticle: Դուք կարող եք օգտագործել ձեր դասական ենթակառուցվածքի կառավարման գործիքները (Ansible, Terraform, Chef և այլն) նույն նպատակների համար, որոնց մասին ես խոսեցի:

Վերջապես կա լուծում Օպերատորի շրջանակ, որի ժողովրդականությունը գնալով աճում է։

Operator Framework-ը Helm-ի լավագույն այլընտրանքն է, որը պետք է դիտարկել:

Այն ավելի հարազատ է CNCF-ի և Kubernetes-ի համար, բայց մուտքի արգելքը շատ ավելի բարձր է, պետք է ավելի շատ ծրագրավորել և ավելի քիչ նկարագրել մանիֆեստները:

Կան տարբեր հավելումներ, ինչպիսիք են Draft, Scaffold: Նրանք կյանքը շատ ավելի հեշտացնում են, օրինակ՝ պարզեցնում են Helm-ի ուղարկման և գործարկման ցիկլը ծրագրավորողների համար՝ փորձարկման միջավայր տեղադրելու համար: Ես նրանց կանվանեի հզորացնողներ:

Ահա տեսողական աղյուսակը, թե որտեղ է ամեն ինչ:

X առանցքի վրա ձեր անձնական վերահսկողության մակարդակն է, թե ինչ է կատարվում, y առանցքի վրա՝ Կուբերնետեսի հարազատության մակարդակը: Ղեկավար տարբերակը 2-ն ընկնում է ինչ-որ տեղ մեջտեղում: 3-րդ տարբերակում ոչ թե ահռելի չափով, այլ բարելավվել է և՛ վերահսկողությունը, և՛ հայրենականության մակարդակը: Ksonnet մակարդակի լուծումները դեռևս զիջում են նույնիսկ Helm 2-ին: Այնուամենայնիվ, դրանք արժե նայել՝ իմանալու համար, թե ուրիշ ինչ կա այս աշխարհում: Իհարկե, ձեր կոնֆիգուրացիայի կառավարիչը կլինի ձեր վերահսկողության տակ, բայց դա բացարձակապես բնիկ չէ Kubernetes-ում:

Operator Framework-ը բացարձակապես հարազատ է Kubernetes-ին և թույլ է տալիս կառավարել այն շատ ավելի նրբագեղ և մանրակրկիտ (բայց հիշեք մուտքի մակարդակը): Ավելի շուտ, սա հարմար է մասնագիտացված հավելվածի և դրա համար կառավարման ստեղծման համար, այլ ոչ թե զանգվածային բերքահավաքի համար՝ Helm-ի միջոցով հսկայական թվով հավելվածներ փաթեթավորելու համար:

Ընդլայնողները պարզապես մի փոքր բարելավում են հսկողությունը, լրացնում են աշխատանքային ընթացքը կամ կտրում են անկյունները CI/CD խողովակաշարերի վրա:

Հելմի ապագան

Լավ նորությունն այն է, որ գալիս է Helm 3. Helm 3.0.0-alpha.2-ի ալֆա տարբերակը արդեն թողարկվել է, կարող եք փորձել: Այն բավականին կայուն է, բայց ֆունկցիոնալությունը դեռևս սահմանափակ է:

Ինչու՞ է ձեզ հարկավոր Helm 3-ը: Առաջին հերթին սա պատմություն է Թիլերի անհետացումը, որպես բաղադրիչ։ Սա, ինչպես արդեն հասկացաք, հսկայական առաջընթաց է, քանի որ ճարտարապետության անվտանգության տեսանկյունից ամեն ինչ պարզեցված է։

Երբ ստեղծվեց Helm 2-ը, որը մոտավորապես Kubernetes 1.8-ի ժամանակ էր կամ նույնիսկ ավելի վաղ, հասկացություններից շատերը դեռ հասուն չէին: Օրինակ, CRD հայեցակարգն այժմ ակտիվորեն իրականացվում է, և Հելմը կկատարի օգտագործել CRDկառույցներ պահելու համար. Հնարավոր կլինի օգտագործել միայն հաճախորդը և չպահպանել սերվերի մասը։ Համապատասխանաբար, օգտագործեք հայրենի Kubernetes հրամանները կառույցների և ռեսուրսների հետ աշխատելու համար: Սա հսկայական առաջընթաց է:

Կհայտնվի աջակցություն հայրենի OCI պահեստներին (Open Container Initiative): Սա հսկայական նախաձեռնություն է, և Հելմը շահագրգռված է առաջին հերթին իր աղյուսակները տեղադրելու համար: Բանը հասնում է նրան, որ, օրինակ, Docker Hub-ն աջակցում է OCI-ի շատ ստանդարտների: Ես չեմ կռահում, բայց, հավանաբար, դասական Docker պահեստի մատակարարները կսկսեն ձեզ հնարավորություն ընձեռնել հյուրընկալելու ձեր Helm աղյուսակները:

Ինձ համար հակասական պատմությունն է Լուա աջակցություն, որպես կաղապարային շարժիչ՝ սցենարներ գրելու համար։ Ես Լուայի մեծ երկրպագու չեմ, բայց սա լրիվ ընտրովի հատկանիշ կլիներ: Ես սա ստուգել եմ 3 անգամ. Լուա օգտագործելն անհրաժեշտ չի լինի: Հետևաբար, նրանք, ովքեր ցանկանում են օգտվել Lua-ից, ովքեր սիրում են Go-ն, միանում են մեր հսկայական ճամբարին և դրա համար օգտագործում են go-tmpl։

Ի վերջո, այն, ինչ ես հաստատ պակասում էի, դա էր սխեմայի առաջացում և տվյալների տիպի վավերացում. Այլևս խնդիրներ չեն լինի int-ի կամ string-ի հետ, կարիք չկա զրոյին փաթաթել կրկնակի չակերտներով: JSONS սխեման կհայտնվի, որը թույլ կտա ձեզ հստակ նկարագրել սա արժեքների համար:

Խիստ կվերամշակվի իրադարձությունների վրա հիմնված մոդել. Այն արդեն կոնցեպտուալ նկարագրված է։ Նայեք Helm 3 ճյուղին և կտեսնեք, թե որքան իրադարձություններ, կեռիկներ և այլ բաներ են ավելացվել, ինչը մեծապես կպարզեցնի և, մյուս կողմից, կավելացնի վերահսկողություն տեղակայման գործընթացների և դրանց արձագանքների նկատմամբ:

Helm 3-ն ավելի պարզ, անվտանգ և զվարճալի կլինի ոչ թե այն պատճառով, որ մենք չենք սիրում Helm 2-ը, այլ այն պատճառով, որ Kubernetes-ը դառնում է ավելի առաջադեմ: Համապատասխանաբար, Հելմը կարող է օգտագործել Kubernetes-ի զարգացումները և դրա վրա ստեղծել հիանալի մենեջերներ Kubernetes-ի համար։

Մեկ այլ լավ նորություն էլ այն է DevOpsConf Ալեքսանդր Խայորովը ձեզ կասի. կարո՞ղ են բեռնարկղերը անվտանգ լինել: Հիշեցնենք, որ մշակման, փորձարկման և շահագործման գործընթացների ինտեգրմանը նվիրված համաժողովը կանցկացվի Մոսկվայում սեպտեմբերի 30-ին և հոկտեմբերի 1-ին. Դուք դեռ կարող եք դա անել մինչև օգոստոսի 20-ը հաշվետվություն ներկայացնել և պատմեք մեզ լուծման հետ կապված ձեր փորձի մասին շատերից մեկը DevOps մոտեցման առաջադրանքները:

Հետևեք կոնֆերանսի անցակետերին և նորություններին փոստային ցուցակում и հեռագրային ալիք.

Source: www.habr.com