Kustomize-ի համառոտ ներածություն

Նշում. թարգմ.Հոդվածը գրվել է ՏՏ ոլորտում մեծ փորձ ունեցող ինժեներ Սքոթ Լոուի կողմից, որը յոթ տպագիր գրքերի հեղինակ/համահեղինակ է (հիմնականում VMware vSphere-ի վրա): Այժմ նա աշխատում է իր VMware դուստր Heptio-ում (ձեռք է բերվել 2016 թվականին)՝ մասնագիտանալով ամպային հաշվարկների և Kubernetes-ի ոլորտում: Տեքստն ինքնին ծառայում է որպես տեխնոլոգիայի օգտագործմամբ Kubernetes-ի համար կազմաձևման կառավարման հակիրճ և հեշտ հասկանալի ներածություն Անհատականացնել, որը վերջերս դարձավ K8-ի մի մասը։

Kustomize-ը գործիք է, որը թույլ է տալիս օգտվողներին «հարմարեցնել պարզ, առանց ձևանմուշների YAML ֆայլերը տարբեր նպատակների համար՝ թողնելով բնօրինակ YAML-ը անձեռնմխելի և օգտագործելի» (նկարագրությունը փոխառված է անմիջապես kustomize պահոցը GitHub-ում) Kustomize-ը կարող է ուղղակիորեն գործարկվել կամ, ըստ Kubernetes 1.14-ի, օգտագործել kubectl -k դրա ֆունկցիոնալությունը մուտք գործելու համար (չնայած Kubernetes 1.15-ի դրությամբ առանձին երկուականը ավելի նոր է, քան kubectl-ում ներկառուցված հնարավորությունները): (Նշում. թարգմ.Եվ վերջին թողարկումով Կուբերնեթ 1.16 հարմարեցնել աջակցությամբ ՝ նաև kubeadm կոմունալում։) Այս գրառման մեջ ես ուզում եմ ընթերցողներին ծանոթացնել kustomize-ի հիմունքներին:

Իր ամենապարզ ձևով/հավելվածով kustomize-ը պարզապես ռեսուրսների հավաքածու է (YAML ֆայլեր, որոնք սահմանում են Kubernetes-ի օբյեկտները. տեղակայումներ, ծառայություններ և այլն), գումարած այդ ռեսուրսներում կատարվող փոփոխությունների հրահանգների ցանկ: Ճիշտ այնպես, ինչպես make-ն օգտագործում է պարունակվող հրահանգների հավաքածուն Makefile, և Docker-ը կառուցում է կոնտեյները՝ հիմնվելով հրահանգների վրա Dockerfile, հարմարեցնել օգտագործումը kustomization.yaml հրահանգներ պահել այն մասին, թե ինչ փոփոխություններ է օգտատերը ցանկանում կատարել ռեսուրսների մի շարքում:

Ահա մի օրինակ ֆայլ kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Չեմ փորձի խոսել ֆայլի բոլոր հնարավոր դաշտերի մասին։ kustomization.yaml (սրա մասին լավ է գրված այստեղ), բայց կոնկրետ օրինակի հակիրճ բացատրությունը կտամ.

• Դաշտ resources ցույց է տալիս, թե ինչ (որ ռեսուրսները) kustomize-ը կփոխվի: Այս դեպքում այն ​​կփնտրի ռեսուրսներ ֆայլերում deployment.yaml и service.yaml ձեր գրացուցակում (անհրաժեշտության դեպքում կարող եք նշել ամբողջական կամ հարաբերական ուղիները):
• Դաշտ namePrefix հանձնարարում է kustomize-ին ավելացնել որոշակի նախածանց (այս դեպքում՝ dev-) վերագրել name ոլորտում սահմանված բոլոր ռեսուրսները resources. Այսպիսով, եթե տեղակայումն ունի name արժեքով nginx-deployment, հարմարեցնելը կդարձնի այն dev-nginx-deployment.
• Դաշտ namespace հանձնարարում է kustomize-ին ավելացնել տվյալ անվանատարածքը բոլոր ռեսուրսներին: Այս դեպքում Deployment and Service-ը կընկնի անվանատարածք development.
• Վերջապես, դաշտը commonLabels պարունակում է մի շարք պիտակներ, որոնք կավելացվեն բոլոր ռեսուրսներին: Մեր օրինակում kustomize-ը ռեսուրսներին պիտակ կհատկացնի անունով environment և իմաստը development.

Եթե ​​օգտագործողը անում է kustomize build . ֆայլով գրացուցակում kustomization.yaml և անհրաժեշտ ռեսուրսները (այսինքն՝ ֆայլեր deployment.yaml и service.yaml), այնուհետև ելքում այն ​​կստանա տեքստ՝ նշված փոփոխություններով kustomization.yaml.

Նշում. թարգմ.Նկարազարդում նախագծային փաստաթղթերից kustomize-ի «պարզ» օգտագործման վերաբերյալ

Արդյունքը կարող է վերահղվել, եթե անհրաժեշտ է փոփոխություններ կատարել.

kustomize build . > custom-config.yaml

Ելքային տվյալները դետերմինիստական ​​են (միևնույն մուտքային տվյալները կտան նույն ելքային արդյունքները), այնպես որ դուք ստիպված չեք լինի արդյունքը պահել ֆայլում: Փոխարենը, այն կարող է ուղղակիորեն փոխանցվել մեկ այլ հրամանի.

kustomize build . | kubectl apply -f -

Kustomize-ի առանձնահատկությունները կարող են հասանելի լինել նաև միջոցով kubectl -k (քանի որ Kubernetes տարբերակը 1.14): Այնուամենայնիվ, հիշեք, որ ինքնուրույն kustomize փաթեթը թարմացվում է ավելի արագ, քան ինտեգրված kubectl փաթեթը (համենայն դեպս այդպես է Kubernetes 1.15 թողարկման դեպքում):

Ընթերցողները կարող են հարցնել. «Ինչո՞ւ է այսքան բարդությունը, եթե դուք կարող եք ուղղակիորեն խմբագրել ֆայլերը»: Հիանալի հարց. Մեր օրինակում իսկապես կարելի փոփոխել ֆայլերը deployment.yaml и service.yaml ուղղակիորեն, բայց ի՞նչ, եթե դրանք ուրիշի նախագծի պատառաքաղն են: Ֆայլերի փոփոխությունն ուղղակիորեն դժվարացնում է (եթե ոչ անհնարին) պատառաքաղի վերահիմնավորումը, երբ փոփոխություններ են կատարվում սկզբնաղբյուրում/աղբյուրում: Kustomize-ի օգտագործումը թույլ է տալիս կենտրոնացնել այս փոփոխությունները ֆայլում kustomization.yaml, բնօրինակ ֆայլերը թողնելով անփոփոխ և այդպիսով հեշտացնելով անհրաժեշտության դեպքում բնօրինակ ֆայլերի վերահիմնավորումը:

Kustomize-ի առավելություններն ակնհայտ են դառնում ավելի բարդ օգտագործման դեպքերում: Վերոնշյալ օրինակում kustomization.yaml և ռեսուրսները գտնվում են նույն գրացուցակում: Այնուամենայնիվ, kustomize-ն աջակցում է օգտագործման դեպքերը, երբ կա բազային կազմաձև և դրա բազմաթիվ տարբերակներ, որոնք նաև հայտնի են որպես երեսապատում. Օրինակ, օգտվողը ցանկանում էր վերցնել Deployment and Service nginx-ի համար, որը ես օգտագործել եմ որպես օրինակ, և ստեղծել այդ ֆայլերի մշակման, բեմադրության և արտադրության տարբերակները (կամ տարբերակները): Դա անելու համար նրան անհրաժեշտ կլինեն վերը նշված ծածկույթները և, փաստորեն, հենց իրենք՝ հիմնական ռեսուրսները։

Ծածկույթների և հիմքում ընկած ռեսուրսների գաղափարը լուսաբանելու համար (բազային ռեսուրսներ), ենթադրենք, որ դիրեկտորիաներն ունեն հետևյալ կառուցվածքը.

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

Ֆայլում base/kustomization.yaml դաշտն օգտագործող օգտվողներ resources պարզապես հայտարարեք այն ռեսուրսները, որոնք պետք է ներառի kustomize-ը:

Ֆայլերից յուրաքանչյուրում overlays/{dev,staging,prod}/kustomization.yaml օգտվողները վերաբերում են դաշտում առկա բազային կազմաձևին resources, այնուհետև նշեք հատուկ փոփոխությունները տվյալ միջավայրը. Օրինակ՝ ֆայլ overlays/dev/kustomization.yaml կարող է նմանվել ավելի վաղ տրված օրինակին.

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Այս դեպքում ֆայլը overlays/prod/kustomization.yaml կարող է լինել բոլորովին այլ՝

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Երբ օգտվողը աշխատում է kustomize build . կատալոգում overlays/dev, kustomize-ը կստեղծի զարգացման տարբերակը: Եթե ​​դուք վազում եք kustomize build . կատալոգում overlays/prod - Դուք ստանում եք արտադրության տարբերակը: Եվ այս ամենը` առանց բնօրինակի մեջ որևէ փոփոխություն կատարելու (հիմք) ֆայլեր՝ բոլորը դեկլարատիվ և դետերմինիստական ​​ձևով։ Դուք կարող եք բազային կոնֆիգուրացիան և ծածկագրման դիրեկտորիաները ուղղակիորեն փոխանցել տարբերակի վերահսկմանը, իմանալով, որ այս ֆայլերի հիման վրա ցանկացած պահի կարող եք վերարտադրել ցանկալի կազմաձևերը:

Նշում. թարգմ.Նկարազարդում նախագծային փաստաթղթերից kustomize-ում ծածկույթների օգտագործման վերաբերյալ

Անհատականացնել կարող է շատ ավելին, քան այն, ինչ ներկայացված է այս հոդվածում: Այնուամենայնիվ, հուսով եմ, որ դա լավ ներածություն է:

Լրացուցիչ ռեսուրսներ

Շատ լավ հոդվածներ և հրապարակումներ կան kustomize-ի մասին: Ահա մի քանիսը, որոնք ես հատկապես օգտակար գտա.

• Փոխեք YAML-ի բազային կազմաձևը տարբեր միջավայրերի համար, արդյունահանեք/փորձարկեք՝ օգտագործելով Kustomize;
• Kustomize — Kubernetes-ում ձևանմուշներ անելու ճիշտ ձևը;
• Kubernetes-ի օբյեկտների դեկլարատիվ կառավարում` օգտագործելով Customize;
• Անհատականացնելով վերին սաղավարտի գծապատկերները Customize-ով.

Նշում. թարգմ.Դուք կարող եք նաև առաջարկել հղումների բլոկ, որը հրապարակված է որպես ռեսուրսներ կոմունալ ծառայության կայքում, որին հաջորդում է «kustomize»-ի մասին վերջին զեկույցներով տեսանյութերի հավաքածու:

Եթե ​​ունեք հարցեր կամ առաջարկներ այս նյութը բարելավելու համար, ես միշտ բաց եմ արձագանքների համար: Դուք կարող եք կապվել ինձ հետ Twitter կամ Kubernetes Slack ալիք. Զվարճացեք՝ փոփոխելով ձեր մանիֆեստները kustomize-ով:

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

• «Գործիքներ Kubernetes-ում աշխատող հավելվածների մշակողների համար";
• «Kubernetes 1.14. հիմնական նորամուծությունների ակնարկ";
• «Ամստերդամում 2019 թվականի Helm Summit-ի հինգ հիմնական արդյունքները";
• «Գործնական ծանոթություն Kubernetes - Helm-ի փաթեթի կառավարիչին.

Source: www.habr.com