Una breve introducción a Kustomize

Nota. traducir: El artículo fue escrito por Scott Lowe, un ingeniero con amplia experiencia en TI, autor/coautor de siete libros impresos (principalmente sobre VMware vSphere). Ahora trabaja para su filial VMware, Heptio (adquirida en 2016), especializándose en computación en la nube y Kubernetes. El texto en sí sirve como una introducción concisa y fácil de entender a la gestión de la configuración de Kubernetes mediante el uso de tecnología. personalizar, que recientemente pasó a formar parte de K8s.

Kustomize es una herramienta que permite a los usuarios "personalizar archivos YAML simples y sin plantillas para diferentes propósitos, dejando el YAML original intacto y utilizable" (descripción tomada directamente de personalizar el repositorio en GitHub). Kustomize se puede ejecutar directamente o, a partir de Kubernetes 1.14, usarse kubectl -k para acceder a su funcionalidad (aunque a partir de Kubernetes 1.15, el binario separado es más nuevo que las capacidades integradas en kubectl). (Nota. traducir: Y con el reciente lanzamiento Kubernetes 1.16 personalizar Apoyado por también en la utilidad kubeadm). En esta publicación, quiero presentarles a los lectores los conceptos básicos de kustomize.

En su forma/aplicación más simple, kustomize es simplemente una colección de recursos (archivos YAML que definen objetos de Kubernetes: implementaciones, servicios, etc.) más una lista de instrucciones para los cambios que deben realizarse en esos recursos. Así como make utiliza el conjunto de instrucciones contenidas en Makefile, y Docker construye el contenedor según las instrucciones de Dockerfile,personalizar usos kustomization.yaml para almacenar instrucciones sobre los cambios que el usuario desea realizar en un conjunto de recursos.

Aquí hay un archivo de ejemplo. kustomization.yaml:

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

No intentaré hablar de todos los campos posibles en el archivo. kustomization.yaml (esto está bien escrito sobre aquí), pero daré una breve explicación de un ejemplo específico:

• Campo resources indica qué (qué recursos) kustomize cambiará. En este caso, buscará recursos en archivos. deployment.yaml и service.yaml en su directorio (puede especificar rutas completas o relativas si es necesario).
• Campo namePrefix le indica a kustomize que agregue un determinado prefijo (en este caso, dev-) atribuir name todos los recursos definidos en el campo resources. Por lo tanto, si el despliegue tiene name con valor nginx-deployment, personalizarlo lo hará dev-nginx-deployment.
• Campo namespace Le indica a kustomize que agregue el espacio de nombres dado a todos los recursos. En este caso, la implementación y el servicio caerán en el espacio de nombres. development.
• Finalmente, el campo commonLabels contiene un conjunto de etiquetas que se agregarán a todos los recursos. En nuestro ejemplo, kustomize asignará una etiqueta a los recursos con el nombre environment y significado development.

Si el usuario lo hace kustomize build . en el directorio con el archivo kustomization.yaml y los recursos necesarios (es decir, archivos deployment.yaml и service.yaml), luego en la salida recibirá un texto con los cambios especificados en kustomization.yaml.

Nota. traducir: Ilustración de la documentación del proyecto sobre el uso “simple” de kustomize

La salida se puede redirigir si es necesario confirmar cambios:

kustomize build . > custom-config.yaml

Los datos de salida son deterministas (los mismos datos de entrada producirán los mismos resultados de salida), por lo que no es necesario guardar el resultado en un archivo. En cambio, se puede pasar directamente a otro comando:

kustomize build . | kubectl apply -f -

También se puede acceder a las funciones de personalización a través de kubectl -k (desde la versión 1.14 de Kubernetes). Sin embargo, tenga en cuenta que el paquete kustomize independiente se actualiza más rápido que el paquete kubectl integrado (al menos este es el caso con la versión Kubernetes 1.15).

Los lectores pueden preguntarse: "¿Por qué toda esta complejidad si puedes editar los archivos directamente?" Gran pregunta. En nuestro ejemplo, de hecho uno puede modificar archivos deployment.yaml и service.yaml directamente, pero ¿y si son una bifurcación del proyecto de otra persona? Cambiar archivos directamente hace que sea difícil (si no imposible) cambiar la base de una bifurcación cuando se realizan cambios en el origen/fuente. Usar kustomize le permite centralizar estos cambios en un archivo kustomization.yaml, dejando los archivos originales intactos y facilitando así el cambio de base de los archivos originales si es necesario.

Los beneficios de kustomize se vuelven evidentes en casos de uso más complejos. En el ejemplo anterior kustomization.yaml y los recursos están en el mismo directorio. Sin embargo, kustomize admite casos de uso en los que existe una configuración base y muchas variantes de la misma, también conocida como superposiciones. Por ejemplo, un usuario quería tomar Implementación y Servicio para nginx, que usé como ejemplo, y crear versiones (o variantes) de desarrollo, preparación y producción de esos archivos. Para hacer esto, necesitará las superposiciones mencionadas anteriormente y, de hecho, los propios recursos básicos.

Para ilustrar la idea de superposiciones y recursos subyacentes. (recursos básicos), supongamos que los directorios tienen la siguiente estructura:

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

En archivo base/kustomization.yaml usuarios usando el campo resources simplemente declare los recursos que debe incluir kustomize.

En cada uno de los archivos overlays/{dev,staging,prod}/kustomization.yaml Los usuarios consultan la configuración base en el campo. resourcesy luego indicar cambios específicos para entorno dado. Por ejemplo, archivo overlays/dev/kustomization.yaml podría parecerse al ejemplo dado anteriormente:

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

En este caso el archivo overlays/prod/kustomization.yaml podría ser completamente diferente:

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

Cuando el usuario ejecuta kustomize build . en el catalogo overlays/dev, kustomize generará la opción de desarrollo. Si tu corres kustomize build . en el catalogo overlays/prod - obtienes la opción de producción. Y todo esto, sin realizar ningún cambio en el original. (básico) archivos, todo de forma declarativa y determinista. Puede enviar la configuración base y los directorios de superposición directamente al control de versiones, sabiendo que, basándose en estos archivos, puede reproducir la configuración deseada en cualquier momento.

Nota. traducir: Ilustración de la documentación del proyecto sobre el uso de superposiciones en kustomize

Personalizar lata mucho más de lo que se cubre en este artículo. Sin embargo, espero que sirva como una buena introducción.

Recursos adicionales

Hay muchos buenos artículos y publicaciones sobre kustomize. Aquí hay algunos que encontré particularmente útiles:

• Cambie la configuración base de YAML para diferentes entornos de producción/prueba usando Kustomize;
• Kustomize: la forma correcta de crear plantillas en Kubernetes;
• Gestión declarativa de objetos de Kubernetes mediante Personalizar;
• Personalización de gráficos de timón ascendentes con Personalizar.

Nota. traducir: También puedes recomendar un bloque de enlaces publicados como Recursos en el sitio web de la utilidad, seguido de una colección de videos con los últimos informes sobre kustomize.

Si tiene preguntas o sugerencias para mejorar este material, siempre estoy abierto a recibir comentarios. Puedes contactar conmigo en Twitter o Canal de holgura de Kubernetes. ¡Diviértete modificando tus manifiestos con kustomize!

PD del traductor

Lea también en nuestro blog:

• «Herramientas para desarrolladores de aplicaciones que se ejecutan en Kubernetes";
• «Kubernetes 1.14: Aspectos destacados de las novedades";
• «Cinco resultados principales de Helm Summit 2019 en Amsterdam";
• «Introducción práctica al administrador de paquetes para Kubernetes - Helm".

Fuente: habr.com