Una breu introducció a Customize

Nota. transl.: L'article va ser escrit per Scott Lowe, un enginyer amb àmplia experiència en TI, que és l'autor/coautor de set llibres impresos (principalment sobre VMware vSphere). Ara treballa per a la seva filial de VMware Heptio (adquirida el 2016), especialitzada en cloud computing i Kubernetes. El text en si serveix com una introducció concisa i fàcil d'entendre a la gestió de la configuració per a Kubernetes mitjançant la tecnologia Personalitza, que recentment va passar a formar part de K8s.

Kustomize és una eina que permet als usuaris "personalitzar fitxers YAML senzills i sense plantilles per a diferents propòsits, deixant el YAML original intacte i utilitzable" (descripció agafada directament de Kustomize el repositori a GitHub). Kustomize es pot executar directament o, a partir de Kubernetes 1.14, s'utilitza kubectl -k per accedir a la seva funcionalitat (tot i que a partir de Kubernetes 1.15, el binari separat és més nou que les capacitats integrades a kubectl). (Nota. transl.: I amb el recent llançament Kubernetes 1.16 personalitzar recolzat per també a la utilitat kubeadm.) En aquesta publicació, vull presentar als lectors els conceptes bàsics de kustomize.

En la seva forma/aplicació més senzilla, kustomize és simplement una col·lecció de recursos (fitxers YAML que defineixen objectes de Kubernetes: desplegaments, serveis, etc.) a més d'una llista d'instruccions per als canvis que cal fer en aquests recursos. De la mateixa manera que make utilitza el conjunt d'instruccions contingut a Makefile, i Docker construeix el contenidor a partir de les instruccions de Dockerfile, personalitzar els usos kustomization.yaml per emmagatzemar instruccions sobre quins canvis vol fer l'usuari a un conjunt de recursos.

Aquí teniu un fitxer d'exemple kustomization.yaml:

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

No intentaré parlar de tots els camps possibles del fitxer. kustomization.yaml (això està ben escrit aquí), però donaré una breu explicació d'un exemple concret:

• Camp resources indica què canviarà (quins recursos) kustomize. En aquest cas, buscarà recursos als fitxers deployment.yaml и service.yaml al vostre directori (podeu especificar camins complets o relatius si cal).
• Camp namePrefix indica a kustomize que afegeixi un prefix determinat (en aquest cas - dev-) atribuir name tots els recursos definits en el camp resources. Així, si el desplegament té name amb significat nginx-deployment, personalitzar ho farà dev-nginx-deployment.
• Camp namespace indica a kustomize que afegeixi l'espai de noms donat a tots els recursos. En aquest cas, el desplegament i el servei cauran a l'espai de noms development.
• Finalment, el camp commonLabels conté un conjunt d'etiquetes que s'afegiran a tots els recursos. En el nostre exemple, kustomize assignarà una etiqueta als recursos amb el nom environment i significat development.

Si l'usuari ho fa kustomize build . al directori amb el fitxer kustomization.yaml i els recursos necessaris (és a dir, fitxers deployment.yaml и service.yaml), llavors a la sortida rebrà un text amb els canvis especificats a kustomization.yaml.

Nota. transl.: Il·lustració de la documentació del projecte sobre l'ús “simple” de kustomize

La sortida es pot redirigir si cal fer canvis:

kustomize build . > custom-config.yaml

Les dades de sortida són deterministes (les mateixes dades d'entrada produiran els mateixos resultats de sortida), de manera que no cal que deseu el resultat en un fitxer. En canvi, es pot passar directament a una altra ordre:

kustomize build . | kubectl apply -f -

També es pot accedir a les funcions de kustomize mitjançant kubectl -k (des de la versió 1.14 de Kubernetes). Tanmateix, tingueu en compte que el paquet kustomize autònom s'actualitza més ràpidament que el paquet kubectl integrat (almenys aquest és el cas de la versió 1.15 de Kubernetes).

Els lectors poden preguntar: "Per què tota aquesta complexitat si podeu editar els fitxers directament?" Gran pregunta. En el nostre exemple, de fet un pot modificar fitxers deployment.yaml и service.yaml directament, però i si són una bifurcació del projecte d'una altra persona? Canviar els fitxers directament fa que sigui difícil (si no impossible) canviar la base d'una bifurcació quan es fan canvis a l'origen/origen. L'ús de kustomize us permet centralitzar aquests canvis en un fitxer kustomization.yaml, deixant els fitxers originals intactes i, per tant, facilita la rebase dels fitxers originals si cal.

Els avantatges de kustomize es fan evidents en casos d'ús més complexos. En l'exemple anterior kustomization.yaml i els recursos es troben al mateix directori. Tanmateix, kustomize admet casos d'ús en què hi ha una configuració base i moltes variants, també conegudes com a superposicions. Per exemple, un usuari volia prendre Deployment and Service per a nginx, que vaig utilitzar com a exemple, i crear versions de desenvolupament, posada en escena i producció (o variants) d'aquests fitxers. Per fer-ho necessitarà les superposicions esmentades i, de fet, els mateixos recursos bàsics.

Per il·lustrar la idea de superposicions i recursos subjacents (recursos bàsics), suposem que els directoris tenen l'estructura següent:

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

A l'arxiu base/kustomization.yaml usuaris que utilitzen el camp resources simplement declareu els recursos que hauria d'incloure kustomize.

En cadascun dels fitxers overlays/{dev,staging,prod}/kustomization.yaml els usuaris fan referència a la configuració base al camp resourcesi, a continuació, indiqueu els canvis específics per a entorn donat. Per exemple, fitxer overlays/dev/kustomization.yaml podria semblar a l'exemple donat anteriorment:

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

En aquest cas el fitxer overlays/prod/kustomization.yaml podria ser completament diferent:

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

Quan l'usuari corre kustomize build . al catàleg overlays/dev, kustomize generarà l'opció de desenvolupament. Si corres kustomize build . al catàleg overlays/prod - Tens l'opció de producció. I tot això, sense fer cap canvi a l'original (base) fitxers, tot de manera declarativa i determinista. Podeu comprometre la configuració base i els directoris de superposició directament al control de versions, sabent que a partir d'aquests fitxers podeu reproduir la configuració desitjada en qualsevol moment.

Nota. transl.: Il·lustració de la documentació del projecte sobre l'ús de superposicions a kustomize

Personalitza la llauna molt més del que es tracta en aquest article. Tanmateix, espero que serveixi com a bona introducció.

Recursos addicionals

Hi ha molts bons articles i publicacions sobre kustomize. Aquí hi ha alguns que em van semblar especialment útils:

• Canvieu la configuració base de YAML per a diferents entorns de producció/prova mitjançant Kustomize;
• Kustomize: la manera correcta de fer plantilles a Kubernetes;
• Gestió declarativa d'objectes de Kubernetes mitjançant Customize;
• Personalització dels gràfics de Helm aigües amunt amb Customize.

Nota. transl.: També podeu recomanar un bloc d'enllaços publicats com a Recursos al lloc web de la utilitat, seguit d'una col·lecció de vídeos amb els últims informes sobre kustomize.

Si teniu preguntes o suggeriments per millorar aquest material, estic sempre obert a rebre comentaris. Pots contactar amb mi a Twitter o Canal Kubernetes Slack. Diverteix-te modificant els teus manifests amb kustomize!

PS del traductor

Llegeix també al nostre blog:

• «Eines per a desenvolupadors d'aplicacions que s'executen a Kubernetes»;
• «Kubernetes 1.14: aspectes destacats de les novetats»;
• «Cinc resultats principals de Helm Summit 2019 a Amsterdam»;
• «Introducció pràctica al gestor de paquets per a Kubernetes - Helm».

Font: www.habr.com