Notu. transl.: La artikolo estis skribita de Scott Lowe, inĝeniero kun vasta sperto en IT, kiu estas la aŭtoro/kunaŭtoro de sep presitaj libroj (ĉefe pri VMware vSphere). Li nun laboras por ĝia VMware-filio Heptio (akirita en 2016), specialiĝanta pri nuba komputado kaj Kubernetes. La teksto mem funkcias kiel konciza kaj facile komprenebla enkonduko al agorda administrado por Kubernetes uzante teknologion. , kiu lastatempe iĝis parto de K8s.
Kustomize estas ilo kiu permesas al uzantoj "agordi simplajn, ŝablon-liberajn YAML-dosierojn por malsamaj celoj, lasante la originan YAML sendifekta kaj uzebla" (priskribo pruntita rekte de ). Kustomize povas esti rulita rekte aŭ, ekde Kubernetes 1.14, uzata kubectl -k por aliri ĝian funkciecon (kvankam ekde Kubernetes 1.15, la aparta duumaro estas pli nova ol la kapabloj konstruitaj en kubectl). (Notu. transl.: Kaj kun la lastatempa eldono personecigi ankaŭ en la ilo kubeadm.) En ĉi tiu afiŝo, mi volas prezenti legantojn al la bazaĵoj de kustomize.
En ĝia plej simpla formo/aplikaĵo, kustomize estas simple kolekto de rimedoj (YAML-dosieroj, kiuj difinas Kubernetes-objektojn: Deplojoj, Servoj, ktp.) plus listo de instrukcioj por ŝanĝoj, kiuj devas esti faritaj al tiuj rimedoj. Same kiel make uzas la instrukcion enhavitan en Makefile, kaj Docker konstruas la ujon surbaze de instrukcioj de Dockerfile, personecigi uzojn kustomization.yaml por konservi instrukciojn pri kiaj ŝanĝoj la uzanto volas fari al aro da rimedoj.
Jen ekzemplo dosiero kustomization.yaml:
resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
environment: development
Mi ne provos paroli pri ĉiuj eblaj kampoj en la dosiero. kustomization.yaml (pri tio estas bone skribita ), sed mi donos mallongan klarigon pri specifa ekzemplo:
- kampo
resourcesindikas kio (kiu rimedoj) kustomize ŝanĝos. En ĉi tiu kazo, ĝi serĉos rimedojn en dosierojdeployment.yamlиservice.yamlen via dosierujo (vi povas specifi plenajn aŭ relativajn vojojn se necese). - kampo
namePrefixinstrukcias kustomize aldoni certan prefikson (en ĉi tiu kazo -dev-) atribuinameĉiuj rimedoj difinitaj en la kamporesources. Tiel, se Deployment havasnamekun signifonginx-deployment, personecigi faros ĝindev-nginx-deployment. - kampo
namespaceinstrukcias kustomize aldoni la donitan nomspacon al ĉiuj rimedoj. En ĉi tiu kazo, Deplojo kaj Servo falos en la nomspacondevelopment. - Fine, la kampo
commonLabelsenhavas aron da etikedoj kiuj estos aldonitaj al ĉiuj rimedoj. En nia ekzemplo, kustomize asignos etikedon al la rimedoj kun la nomoenvironmentkaj signifodevelopment.
Se la uzanto faras kustomize build . en la dosierujo kun la dosiero kustomization.yaml kaj la necesaj rimedoj (t.e. dosieroj deployment.yaml и service.yaml), tiam ĉe la eligo ĝi ricevos tekston kun la ŝanĝoj specifitaj en kustomization.yaml.
Notu. transl.: Ilustraĵo el la projektdokumentado pri la "simpla" uzo de kustomize
La eligo povas esti redirektita se ŝanĝoj devas esti faritaj:
kustomize build . > custom-config.yamlLa eligo-datumoj estas determinismaj (la samaj enigo-datumoj produktos la samajn eligrezultojn), do vi ne devas konservi la rezulton al dosiero. Anstataŭe, ĝi povas esti transdonita rekte al alia komando:
kustomize build . | kubectl apply -f -
La kustomize-funkcioj ankaŭ estas alireblaj per kubectl -k (ekde Kubernetes versio 1.14). Tamen memoru, ke la memstara kustomize-pakaĵo estas ĝisdatigita pli rapide ol la integra kubectl-pakaĵo (almenaŭ tio estas la kazo kun la eldono de Kubernetes 1.15).
Legantoj povas demandi: "Kial ĉi tiu komplekseco se vi povas redakti la dosierojn rekte?" Bonega demando. En nia ekzemplo, ja povas modifi dosierojn deployment.yaml и service.yaml rekte, sed kio se ili estas forko de alies projekto? Ŝanĝi dosierojn rekte malfaciligas (se ne maleblas) rebazi forkon kiam ŝanĝoj estas faritaj al la origino/fonto. Uzado de kustomize permesas vin alcentrigi ĉi tiujn ŝanĝojn en dosiero kustomization.yaml, lasante la originalajn dosierojn nerompitaj kaj tiel faciligante rebazi la originalajn dosierojn se necese.
La avantaĝoj de kustomize evidentiĝas en pli kompleksaj uzkazoj. En la supra ekzemplo kustomization.yaml kaj la rimedoj estas en la sama dosierujo. Tamen, kustomize subtenas uzkazojn kie ekzistas baza agordo kaj multaj variantoj de ĝi, ankaŭ konataj kiel surbaze. Ekzemple, uzanto volis preni Deplojon kaj Servon por nginx, kiun mi uzis kiel ekzemplon, kaj krei evoluajn, enscenigantajn kaj produktadajn versiojn (aŭ variantojn) de tiuj dosieroj. Por fari tion, li bezonos la supre menciitajn kovraĵojn kaj, fakte, la bazajn rimedojn mem.
Por ilustri la ideon de supermetaĵoj kaj subestaj rimedoj (bazaj rimedoj), ni supozu, ke la dosierujoj havas la jenan strukturon:
- base
- deployment.yaml
- service.yaml
- kustomization.yaml
- overlays
- dev
- kustomization.yaml
- staging
- kustomization.yaml
- prod
- kustomization.yaml
En dosiero base/kustomization.yaml uzantoj uzante la kampon resources simple deklari la rimedojn, kiujn kustomize devus inkluzivi.
En ĉiu el la dosieroj overlays/{dev,staging,prod}/kustomization.yaml uzantoj rilatas al la baza agordo en la kampo resources, kaj poste indiku specifajn ŝanĝojn por donita medio. Ekzemple, dosiero overlays/dev/kustomization.yaml povus aspekti kiel la ekzemplo donita pli frue:
resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
environment: development
En ĉi tiu kazo la dosiero overlays/prod/kustomization.yaml povus esti tute malsama:
resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
environment: production
sre-team: blue
Kiam la uzanto kuras kustomize build . en la katalogo overlays/dev, kustomize generos la evoluopcion. Se vi kuras kustomize build . en la katalogo overlays/prod - vi ricevas la opcion de produktado. Kaj ĉio ĉi - sen fari ajnajn ŝanĝojn al la originalo (bazo) dosieroj, ĉio en deklara kaj determinisma maniero. Vi povas transigi la bazan agordon kaj supermeti dosierujojn rekte al versio-kontrolo, sciante, ke surbaze de ĉi tiuj dosieroj vi povas reprodukti la deziratan agordon en ajna momento.
Notu. transl.: Ilustraĵo el la projektdokumentaro pri uzado de supermetaĵoj en kustomize
Agordu povas multe pli ol tio, kio estas kovrita en ĉi tiu artikolo. Tamen mi esperas, ke ĝi servos kiel bona enkonduko.
Pliaj Rimedoj
Estas multaj bonaj artikoloj kaj publikaĵoj pri kustomize. Jen kelkaj, kiujn mi trovis precipe utilaj:
- ;
- ;
- ;
- .
Notu. transl.: Vi ankaŭ povas rekomendi blokon de ligiloj publikigitaj kiel en la retejo de la utileco, sekvita de kolekto de videoj kun la plej novaj raportoj pri kustomize.
Se vi havas demandojn aŭ sugestojn por plibonigi ĉi tiun materialon, mi ĉiam estas malfermita al sugestoj. Vi povas kontakti min ĉe aŭ . Amuziĝu modifi viajn manifestojn per kustomize!
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com