Unha breve introdución a Kustomize

Nota. transl.: O artigo foi escrito por Scott Lowe, un enxeñeiro con ampla experiencia en TI, que é o autor/coautor de sete libros impresos (principalmente sobre VMware vSphere). Agora traballa para a súa filial de VMware Heptio (adquirida en 2016), especializada en cloud computing e Kubernetes. O texto en si serve como unha introdución concisa e fácil de entender á xestión da configuración para Kubernetes mediante a tecnoloxía Personalizar, que recentemente pasou a formar parte de K8s.

Kustomize é unha ferramenta que permite aos usuarios "personalizar ficheiros YAML sinxelos e sen modelo para diferentes fins, deixando o YAML orixinal intacto e utilizable" (descrición tomada directamente de Kustomize repositorio en GitHub). Kustomize pódese executar directamente ou, a partir de Kubernetes 1.14, utilizarse kubectl -k para acceder á súa funcionalidade (aínda que a partir de Kubernetes 1.15, o binario separado é máis novo que as capacidades integradas en kubectl). (Nota. transl.: E co lanzamento recente Kubernetes 1.16 personalizar apoiado por tamén na utilidade kubeadm.) Nesta publicación, quero presentar aos lectores os conceptos básicos de kustomize.

Na súa forma/aplicación máis sinxela, kustomize é simplemente unha colección de recursos (ficheiros YAML que definen obxectos de Kubernetes: implementacións, servizos, etc.) ademais dunha lista de instrucións para os cambios que se deben facer neses recursos. Do mesmo xeito que make usa o conxunto de instrucións contido en Makefile, e Docker constrúe o contedor baseándose nas instrucións de Dockerfile, personalizar usos kustomization.yaml para almacenar instrucións sobre os cambios que quere facer o usuario nun conxunto de recursos.

Aquí tes un ficheiro de exemplo kustomization.yaml:

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

Non intentarei falar de todos os campos posibles do ficheiro. kustomization.yaml (Isto está ben escrito aquí), pero vou dar unha breve explicación dun exemplo específico:

• Campo resources indica que (que recursos) cambiará kustomize. Neste caso, buscará recursos en ficheiros deployment.yaml и service.yaml no seu directorio (pode especificar camiños completos ou relativos se é necesario).
• Campo namePrefix indica a kustomize que engada un determinado prefixo (neste caso - dev-) atribuír name todos os recursos definidos no campo resources. Así, se o Despliegue ten name con valor nginx-deployment, Personalizar farano dev-nginx-deployment.
• Campo namespace instrúe a kustomize para engadir o espazo de nomes dado a todos os recursos. Neste caso, Implementación e Servizo caerán no espazo de nomes development.
• Finalmente, o campo commonLabels contén un conxunto de etiquetas que se engadirán a todos os recursos. No noso exemplo, kustomize asignará unha etiqueta aos recursos co nome environment e significado development.

Se o usuario o fai kustomize build . no directorio co ficheiro kustomization.yaml e os recursos necesarios (é dicir, ficheiros deployment.yaml и service.yaml), entón na saída recibirá un texto cos cambios especificados en kustomization.yaml.

Nota. transl.: Ilustración da documentación do proxecto sobre o uso “simple” de kustomize

A saída pódese redirixir se hai que realizar cambios:

kustomize build . > custom-config.yaml

Os datos de saída son deterministas (os mesmos datos de entrada producirán os mesmos resultados de saída), polo que non tes que gardar o resultado nun ficheiro. Pola contra, pódese pasar directamente a outro comando:

kustomize build . | kubectl apply -f -

Tamén se pode acceder ás funcións de kustomize mediante kubectl -k (desde a versión 1.14 de Kubernetes). Non obstante, teña en conta que o paquete kustomize autónomo actualízase máis rápido que o paquete kubectl integrado (polo menos este é o caso da versión 1.15 de Kubernetes).

Os lectores poden preguntar: "Por que tanta complexidade se pode editar os ficheiros directamente?" Gran pregunta. No noso exemplo, de feito unha lata modificar ficheiros deployment.yaml и service.yaml directamente, pero e se son un garfo do proxecto alleo? Cambiar directamente os ficheiros dificulta (se non imposible) cambiar a base dunha bifurcación cando se fan cambios na orixe/fonte. Usar kustomize permíteche centralizar estes cambios nun ficheiro kustomization.yaml, deixando intactos os ficheiros orixinais e facilitando así a rebase dos ficheiros orixinais se é necesario.

Os beneficios de kustomize fanse evidentes en casos de uso máis complexos. No exemplo anterior kustomization.yaml e os recursos están no mesmo directorio. Non obstante, kustomize admite casos de uso nos que hai unha configuración base e moitas variantes desta, tamén coñecidas como superposicións. Por exemplo, un usuario quería tomar Deployment and Service para nginx, que usei como exemplo, e crear versións (ou variantes) de desenvolvemento, posta en escena e produción deses ficheiros. Para iso, precisará das superposicións mencionadas e, de feito, dos propios recursos básicos.

Para ilustrar a idea de superposicións e recursos subxacentes (recursos básicos), supoñamos que os directorios teñen a seguinte estrutura:

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

En arquivo base/kustomization.yaml usuarios que usan o campo resources simplemente declare os recursos que debe incluír kustomize.

En cada un dos ficheiros overlays/{dev,staging,prod}/kustomization.yaml os usuarios fan referencia á configuración base no campo resources, e despois indicar cambios específicos para ambiente dado. Por exemplo, arquivo overlays/dev/kustomization.yaml pode parecerse ao exemplo dado anteriormente:

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

Neste caso o arquivo overlays/prod/kustomization.yaml pode ser completamente diferente:

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

Cando o usuario corre kustomize build . no catálogo overlays/dev, kustomize xerará a opción de desenvolvemento. Se corres kustomize build . no catálogo overlays/prod - obtén a opción de produción. E todo isto - sen facer ningún cambio no orixinal (base) arquivos, todo de xeito declarativo e determinista. Podes comprometer a configuración base e os directorios de superposición directamente ao control de versións, sabendo que en base a estes ficheiros podes reproducir a configuración desexada en calquera momento.

Nota. transl.: Ilustración da documentación do proxecto sobre o uso de superposicións en kustomize

Personaliza a lata moito máis do que se trata neste artigo. Non obstante, espero que sirva de boa presentación.

Recursos adicionais

Hai moitos bos artigos e publicacións sobre kustomize. Aquí tes algúns que me pareceron especialmente útiles:

• Cambia a configuración base de YAML para diferentes ambientes de produción/proba usando Kustomize;
• Kustomize: a forma correcta de crear modelos en Kubernetes;
• Xestión declarativa de obxectos de Kubernetes mediante Customize;
• Personalización de gráficos de dirección ascendente con Customize.

Nota. transl.: Tamén pode recomendar un bloque de ligazóns publicadas como recursos no sitio web da utilidade, seguido dunha colección de vídeos cos últimos informes sobre kustomize.

Se tes preguntas ou suxestións para mellorar este material, sempre estou aberto a comentarios. Podes contactar comigo en chilro ou Canle Slack de Kubernetes. Divírtete modificando os teus manifestos con kustomize!

PS do tradutor

Lea tamén no noso blog:

• «Ferramentas para desenvolvedores de aplicacións que se executan en Kubernetes»;
• «Kubernetes 1.14: visión xeral das principais novidades»;
• «Cinco resultados principais do Helm Summit 2019 en Amsterdam»;
• «Introdución práctica ao xestor de paquetes para Kubernetes - Helm».

Fonte: www.habr.com