Cyflwyniad Byr i Kustomize

Nodyn. traws.: Ysgrifennwyd yr erthygl gan Scott Lowe, peiriannydd gyda phrofiad helaeth mewn TG, sy’n awdur/cyd-awdur saith llyfr printiedig (ar VMware vSphere yn bennaf). Mae bellach yn gweithio i'w is-gwmni VMware Heptio (a gaffaelwyd yn 2016), gan arbenigo mewn cyfrifiadura cwmwl a Kubernetes. Mae'r testun ei hun yn gyflwyniad cryno a hawdd ei ddeall i reoli cyfluniad ar gyfer Kubernetes gan ddefnyddio technoleg Addasu, a ddaeth yn rhan o K8s yn ddiweddar.

Cyflwyniad Byr i Kustomize

Offeryn yw Kustomize sy'n caniatáu i ddefnyddwyr “addasu ffeiliau YAML syml, heb dempledi at wahanol ddibenion, gan adael yr YAML gwreiddiol yn gyfan ac yn ddefnyddiadwy” (disgrifiad wedi'i fenthyg yn uniongyrchol o ystorfa kustomize ar GitHub). Gellir rhedeg Kustomize yn uniongyrchol neu, fel Kubernetes 1.14, ei ddefnyddio kubectl -k i gael mynediad at ei ymarferoldeb (er o Kubernetes 1.15, mae'r deuaidd ar wahân yn fwy newydd na'r galluoedd sydd wedi'u hymgorffori yn kubectl). (Nodyn. traws.: A chyda'r datganiad diweddar Ciwbernetau 1.16 addasu gyda chefnogaeth hefyd yn y cyfleustodau kubeadm.) Yn y swydd hon, rwyf am gyflwyno darllenwyr i hanfodion kustomize.

Yn ei ffurf/cymhwysiad symlaf, casgliad o adnoddau yn unig yw kustomize (ffeiliau YAML sy'n diffinio gwrthrychau Kubernetes: Defnydd, Gwasanaethau, ac ati) ynghyd â rhestr o gyfarwyddiadau ar gyfer newidiadau y mae angen eu gwneud i'r adnoddau hynny. Yn union fel mae make yn defnyddio'r set gyfarwyddiadau a gynhwysir yn Makefile, ac mae Docker yn adeiladu'r cynhwysydd yn seiliedig ar gyfarwyddiadau gan Dockerfile, addasu defnyddiau kustomization.yaml i storio cyfarwyddiadau ynghylch pa newidiadau y mae'r defnyddiwr am eu gwneud i set o adnoddau.

Dyma ffeil enghraifft kustomization.yaml:

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

Ni fyddaf yn ceisio siarad am yr holl feysydd posibl yn y ffeil. kustomization.yaml (mae hyn wedi'i ysgrifennu'n dda amdano yma), ond rhoddaf esboniad byr o enghraifft benodol:

  • Maes resources yn nodi beth (pa adnoddau) fydd yn newid. Yn yr achos hwn, bydd yn chwilio am adnoddau mewn ffeiliau deployment.yaml и service.yaml yn eich cyfeiriadur (gallwch nodi llwybrau llawn neu berthnasol os oes angen).
  • Maes namePrefix yn cyfarwyddo kustomize i ychwanegu rhagddodiad penodol (yn yr achos hwn - dev-) i briodoli name yr holl adnoddau a ddiffinnir yn y maes resources. Felly, os oes gan Deploy name gydag ystyr nginx-deployment, bydd addasu yn ei gwneud yn dev-nginx-deployment.
  • Maes namespace yn cyfarwyddo kustomize i ychwanegu'r gofod enw a roddir i'r holl adnoddau. Yn yr achos hwn, bydd Defnyddio a Gwasanaeth yn disgyn i'r gofod enwau development.
  • Yn olaf, y cae commonLabels yn cynnwys set o labeli a fydd yn cael eu hychwanegu at yr holl adnoddau. Yn ein hesiampl, bydd kustomize yn aseinio label i'r adnoddau gyda'r enw environment ac ystyr development.

Os yw'r defnyddiwr yn gwneud hynny kustomize build . yn y cyfeiriadur gyda'r ffeil kustomization.yaml a’r adnoddau angenrheidiol (h.y. ffeiliau deployment.yaml и service.yaml), yna yn yr allbwn bydd yn derbyn testun gyda'r newidiadau a nodir ynddo kustomization.yaml.

Cyflwyniad Byr i Kustomize
Nodyn. traws.: Darlun o ddogfennaeth y prosiect ar y defnydd “syml” o kustomize

Gellir ailgyfeirio'r allbwn os oes angen gwneud newidiadau:

kustomize build . > custom-config.yaml

Mae'r data allbwn yn benderfynol (bydd yr un data mewnbwn yn cynhyrchu'r un canlyniadau allbwn), felly nid oes rhaid i chi gadw'r canlyniad i ffeil. Yn lle hynny, gellir ei drosglwyddo'n uniongyrchol i orchymyn arall:

kustomize build . | kubectl apply -f -

Gall y nodweddion kustomize hefyd ar gael drwy kubectl -k (ers fersiwn Kubernetes 1.14). Fodd bynnag, cofiwch fod y pecyn kustomize annibynnol yn cael ei ddiweddaru'n gyflymach na'r pecyn kubectl integredig (o leiaf mae hyn yn wir gyda datganiad Kubernetes 1.15).

Gall darllenwyr ofyn: “Pam yr holl gymhlethdod hwn os gallwch chi olygu'r ffeiliau'n uniongyrchol?” Cwestiwn gwych. Yn ein hesiampl ni, yn wir all neb addasu ffeiliau deployment.yaml и service.yaml yn uniongyrchol, ond beth os ydynt yn fforch o brosiect rhywun arall? Mae newid ffeiliau'n uniongyrchol yn ei gwneud hi'n anodd (os nad yn amhosibl) ail-osod fforc pan wneir newidiadau i'r tarddiad/ffynhonnell. Mae defnyddio kustomize yn caniatáu ichi ganoli'r newidiadau hyn mewn ffeil kustomization.yaml, gan adael y ffeiliau gwreiddiol yn gyfan a thrwy hynny ei gwneud hi'n haws ail-osod y ffeiliau gwreiddiol os oes angen.

Daw manteision kustomize i'r amlwg mewn achosion defnydd mwy cymhleth. Yn yr enghraifft uchod kustomization.yaml ac mae'r adnoddau yn yr un cyfeiriadur. Fodd bynnag, mae kustomize yn cefnogi achosion defnydd lle mae cyfluniad sylfaen a llawer o amrywiadau ohono, a elwir hefyd yn troshaenau. Er enghraifft, roedd defnyddiwr eisiau cymryd Defnydd a Gwasanaeth ar gyfer nginx, a ddefnyddiais fel enghraifft, a chreu fersiynau datblygu, llwyfannu a chynhyrchu (neu amrywiadau) o'r ffeiliau hynny. I wneud hyn, bydd angen y troshaenau uchod arno ac, mewn gwirionedd, yr adnoddau sylfaenol eu hunain.

I ddarlunio'r syniad o droshaenau ac adnoddau gwaelodol (adnoddau sylfaenol), gadewch i ni dybio bod gan y cyfeiriaduron y strwythur canlynol:

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

Mewn ffeil base/kustomization.yaml defnyddwyr sy'n defnyddio'r maes resources dim ond datgan yr adnoddau y dylai kustomize eu cynnwys.

Ym mhob un o'r ffeiliau overlays/{dev,staging,prod}/kustomization.yaml mae defnyddwyr yn cyfeirio at y ffurfweddiad sylfaen yn y maes resources, ac yna nodi newidiadau penodol ar gyfer amgylchedd a roddir. Er enghraifft, ffeil overlays/dev/kustomization.yaml efallai y bydd yn edrych fel yr enghraifft a roddwyd yn gynharach:

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

Yn yr achos hwn y ffeil overlays/prod/kustomization.yaml gallai fod yn hollol wahanol:

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

Pan fydd y defnyddiwr yn rhedeg kustomize build . yn y catalog overlays/dev, Bydd kustomize yn cynhyrchu'r opsiwn datblygu. Os ydych yn rhedeg kustomize build . yn y catalog overlays/prod - rydych chi'n cael yr opsiwn cynhyrchu. A hyn i gyd - heb wneud unrhyw newidiadau i'r gwreiddiol (sylfaen) ffeiliau, i gyd mewn ffordd ddatganiadol a phenderfynol. Gallwch chi ymrwymo'r cyfluniad sylfaenol a'r cyfeirlyfrau troshaenu'n uniongyrchol i reoli fersiwn, gan wybod y gallwch chi, yn seiliedig ar y ffeiliau hyn, atgynhyrchu'r ffurfweddiad dymunol ar unrhyw adeg.

Cyflwyniad Byr i Kustomize
Nodyn. traws.: Darlun o ddogfennaeth y prosiect ar ddefnyddio troshaenau yn kustomize

Addasu can llawer mwy na'r hyn a drafodir yn yr erthygl hon. Fodd bynnag, gobeithio ei fod yn gyflwyniad da.

Adnoddau Ychwanegol

Mae yna lawer o erthyglau a chyhoeddiadau da am kustomize. Dyma rai a oedd yn arbennig o ddefnyddiol i mi:

Nodyn. traws.: Gallwch hefyd argymell bloc o ddolenni a gyhoeddwyd fel Adnoddau ar wefan y cyfleustodau, ac yna casgliad o fideos gyda'r adroddiadau diweddaraf am kustomize.

Os oes gennych gwestiynau neu awgrymiadau ar gyfer gwella'r deunydd hwn, rwyf bob amser yn agored i adborth. Gallwch gysylltu â mi yn Twitter neu Sianel Kubernetes Slack. Cael hwyl yn addasu eich maniffestau gyda kustomize!

PS gan y cyfieithydd

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Prynu gwesteio dibynadwy ar gyfer gwefannau sydd â diogelwch DDoS, gweinyddwyr VPS VDS 🔥 Prynu cynnal gwefannau dibynadwy gyda diogelwch DDoS, gweinyddion VPS VDS | ProHoster