🥇 Breve introducción a Kustomize

Nota de traducción.: 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). Actualmente trabaja en su filial de VMware, Heptio (absorbida en 2016), especializándose en computación en la nube y Kubernetes. El texto sirve como una introducción concisa y fácil de entender sobre la gestión de configuraciones para Kubernetes mediante la tecnología Kustomize, que recientemente se incorporó a K8s.

Kustomize es una herramienta que permite a los usuarios "personalizar archivos YAML simples y libres de plantillas para diferentes propósitos, dejando el YAML original intacto y utilizable" (esta descripción se toma directamente del repositorio kustomize en GitHub). Kustomize se puede ejecutar directamente o, a partir de Kubernetes 1.14, utilizar kubectl -k para acceder a sus funciones (aunque, a partir de Kubernetes 1.15, el binario separado es más reciente que las capacidades integradas en kubectl). (Nota de traducción.: Con el reciente lanzamiento de Kubernetes 1.16 kustomize es compatible , también en la herramienta kubeadm.) En esta publicación, quiero familiarizar a los lectores con los conceptos básicos de kustomize.

En su forma más sencilla o aplicación, kustomize es simplemente un conjunto de recursos (archivos YAML que definen objetos de Kubernetes: Deployments, Services, etc.) más una lista de instrucciones sobre los cambios que se deben realizar en estos recursos. Al igual que make utiliza un conjunto de instrucciones que se encuentran en el Makefile, y Docker construye un contenedor basado en las instrucciones de Dockerfile, kustomize utiliza kustomization.yaml para almacenar los mandatos sobre qué cambios desea hacer el usuario en el conjunto de recursos.

Aquí hay un ejemplo de archivo kustomization.yaml:

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

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

Campo resources indica qué (qué recursos) cambiará kustomize. En este caso, estará buscando recursos en los archivos deployment.yaml y service.yaml en su directorio (si es necesario, se pueden especificar rutas completas o relativas).
Campo namePrefix indica a kustomize que agregue un prefijo específico (en este caso, dev-) al atributo name de todos los recursos definidos en el campo resources. Así, si en el Deployment hay name con el valor nginx-deployment, kustomize lo convertirá en dev-nginx-deployment.
Campo namespace indica a kustomize que agregue el espacio de nombres especificado a todos los recursos. En este caso, Deployment y Service estarán en el espacio de nombres desarrollo.
Finalmente, el campo commonLabels contiene un conjunto de etiquetas que se añadirán a todos los recursos. En nuestro ejemplo, kustomize asignará a los recursos una etiqueta con el nombre entorno y el valor desarrollo.

Si el usuario ejecuta kustomize build . en el directorio con el archivo kustomization.yaml y los recursos necesarios (es decir, los archivos deployment.yaml y service.yaml), recibirá como salida el texto con las modificaciones especificadas en kustomization.yaml.

Nota de traducción.: Ilustración de la documentación del proyecto sobre el uso "sencillo" de kustomize

La salida se puede redirigir si es necesario para registrar los cambios:

kustomize build . > custom-config.yaml

La salida es determinista (con los mismos datos de entrada se obtienen los mismos resultados de salida), por lo que no es necesario guardar el resultado en un archivo. En su lugar, se puede pasar directamente a otro comando:

kustomize build . | kubectl apply -f -

El acceso a las funciones de kustomize también se puede obtener a través de kubectl -k (a partir de la versión 1.14 de Kubernetes). Sin embargo, tenga en cuenta que el paquete separado de kustomize se actualiza más rápido que el integrado en kubectl (al menos, esa es la situación con la versión 1.15 de Kubernetes).

Los lectores pueden preguntar: "¿Por qué complicarse tanto si se pueden editar los archivos directamente?". Excelente pregunta. En nuestro ejemplo, de hecho en es posible modificar los archivos deployment.yaml y service.yaml directamente, pero ¿qué pasa si son un fork de algún proyecto? Cambiar los archivos directamente dificulta (si es que no hace imposible) el rebase del fork cuando se realizan cambios en el origen. Usar kustomize permite centralizar estos cambios en un archivo kustomization.yaml, dejando los archivos originales intactos y así facilitando, si es necesario, el rebase de los archivos de origen.

Las ventajas de kustomize se hacen 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 escenarios en los que hay una configuración base y múltiples variantes de esta, también conocidas como Además:. Por ejemplo, el usuario podría querer tomar el Deployment y Service para nginx que utilicé como ejemplo y crear versiones (o variantes) de desarrollo, staging y producción de esos archivos. Para ello, necesitará las superposiciones mencionadas anteriormente y, por supuesto, los propios recursos base.

Para ilustrar la idea de overlays y recursos base (recursos base), 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 el archivo base/kustomization.yaml los usuarios utilizan el campo resources simplemente declaran los recursos que debe incluir kustomize.

En cada uno de los archivos overlays/{dev,staging,prod}/kustomization.yaml los usuarios hacen referencia a la configuración base en el campo resources, y luego especifican los cambios concretos para ese entorno. Por ejemplo, el archivo overlays/dev/kustomization.yaml puede lucir como el ejemplo proporcionado anteriormente:

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

Mientras que el archivo overlays/prod/kustomization.yaml puede ser completamente diferente:

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

Cuando el usuario ejecute kustomize build . en el directorio overlays/dev, kustomize generará una versión de desarrollo. Si se ejecuta kustomize build . en el directorio overlays/prod , obtendremos una versión de producción. Y todo esto, sin realizar cambios en los archivos originales (base) , y todo esto — de manera declarativa y determinista. Se puede hacer commit de la configuración base y de los directorios de overlays directamente en el sistema de control de versiones, sabiendo que con estos archivos se puede reproducir la configuración deseada en cualquier momento.

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

Kustomize puede mucho hacer más de lo que se ha mencionado 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 consideré especialmente útiles:

Nota de traducción.: También se puede recomendar un bloque de enlaces, publicado como Recursos en el sitio de la herramienta, seguido de una colección de videos con las últimas presentaciones sobre kustomize.

Si tienes preguntas o sugerencias para mejorar este material, siempre estoy abierto a comentarios. Puedes contactarme a través de Twitter o en el canal de Slack de Kubernetes. ¡Disfruta modificando tus manifiestos con kustomize!

P.D. del traductor

También puedes leer en nuestro blog:

Fuente: habr.com

Introducción breve a Kustomize

Recursos adicionales

P.D. del traductor