Nota perev. : El artículo fue escrito por Scott Lowe, un ingeniero de TI senior que fue autor / coautor de siete libros impresos (principalmente para VMware vSphere). Actualmente trabaja en 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 amplia y fácil de entender a la gestión de la configuración para Kubernetes utilizando la tecnología Kustomize , incluida recientemente con K8.
Kustomize es una herramienta que permite a los usuarios "personalizar archivos YAML simples y sin plantillas para diversos fines, dejando el YAML original intacto y utilizable" (la descripción se toma prestada directamente del
repositorio de kustomize en GitHub ). Kustomize se puede ejecutar directamente o, comenzando con Kubernetes 1.14, use
kubectl -k para acceder a sus funciones (aunque a partir de Kubernetes 1.15, un binario separado es más nuevo que las características integradas en kubectl).
( Nota : con la versión reciente de Kubernetes 1.16 , kustomize también es compatible con la utilidad kubeadm). En esta publicación, quiero presentar 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 sobre los cambios que deben hacerse a estos recursos. Del mismo modo que make usa el conjunto de instrucciones contenido en el
Makefile y Docker
Dockerfile contenedor basado en las instrucciones del
Dockerfile , kustomize usa
kustomization.yaml para almacenar instrucciones sobre los cambios que el usuario desea hacer 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 sobre todos los campos posibles en el archivo
kustomization.yaml (esto está bien escrito
aquí ), pero daré una breve explicación de un ejemplo específico:
- El campo de
resources indica qué (qué recursos) kustomize cambiará. En este caso, buscará recursos en los archivos deployment.yaml y service.yaml en su directorio (si es necesario, puede especificar rutas completas o relativas). - El 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 de resources . Por lo tanto, si hay un name en Deployment con el valor nginx-deployment , kustomize lo convertirá en dev-nginx-deployment - El campo de
namespace indica a kustomize que agregue el espacio de nombres especificado a todos los recursos. En este caso, Deployment and Service caerá en el espacio de nombres de 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 del environment y el development valor.
Si el usuario ejecuta
kustomize build . en el directorio con el archivo
kustomization.yaml y los recursos necesarios (es decir, archivos
deployment.yaml y
service.yaml ), luego, en la salida, recibirá el texto con los cambios registrados en
kustomization.yaml .
Nota perev. : Ilustración de la documentación del proyecto para el uso "simple" de kustomizeLa salida se puede redirigir si necesita confirmar los cambios:
kustomize build . > custom-config.yaml
La salida es determinista (con la misma entrada, se obtendrá la misma salida), por lo que no puede guardar el resultado en un archivo. En cambio, puede pasarlo inmediatamente a otro comando:
kustomize build . | kubectl apply -f -
También se puede acceder a las
kubectl -k través de
kubectl -k (desde la versión 1.14 de Kubernetes). Sin embargo, tenga en cuenta que un paquete de kustomize separado se actualiza más rápido que uno integrado en kubectl (al menos este es el caso con el lanzamiento de Kubernetes 1.15).
Los lectores pueden preguntar: "¿Por qué todas estas dificultades, si puede editar archivos directamente?". Gran pregunta En nuestro ejemplo, es realmente
posible modificar los archivos
deployment.yaml y
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) volver a crear la bifurcación cuando se realizan cambios en la fuente / fuente. El uso de kustomize le permite centralizar estos cambios en el archivo
kustomization.yaml , dejando intactos los archivos originales y facilitando así el replanteamiento de los archivos fuente si es necesario.
Los beneficios 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 de uso cuando hay una configuración básica y muchas de sus variantes, también conocidas como
superposiciones . Por ejemplo, un usuario quería tomar Deployment and Service para nginx, que usé como ejemplo, y crear versiones (o variantes) de desarrollo, almacenamiento provisional y producción de esos archivos. Para hacer esto, necesitará las superposiciones mencionadas anteriormente y, de hecho, los recursos básicos en sí mismos.
Para ilustrar la idea de superposiciones y
recursos base , suponga 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
base/kustomization.yaml usuarios simplemente usan el campo de
resources para declarar los recursos que kustomize debería habilitar.
En cada uno de los
overlays/{dev,staging,prod}/kustomization.yaml usuarios se refieren a la configuración básica en el campo de
resources y luego indican los cambios específicos para
este entorno . Por ejemplo, el
overlays/dev/kustomization.yaml podría parecerse al ejemplo dado anteriormente:
resources: - ../../base namePrefix: dev- namespace: development commonLabels: environment: development
Al mismo tiempo, el
overlays/prod/kustomization.yaml puede ser completamente diferente:
resources: - ../../base namePrefix: prod- namespace: production commonLabels: environment: production sre-team: blue
Cuando el usuario comienza a personalizar la
kustomize build . en el
overlays/dev , kustomize generará una opción de desarrollo. Si ejecuta
kustomize build . en el directorio
overlays/prod : obtienes la opción de producción. Y todo esto, sin hacer ningún cambio en los archivos originales
(base) , y todo esto, de una manera declarativa y determinista. Puede confirmar la configuración básica y los directorios de superposición directamente en el sistema de control de versiones, sabiendo que en función de estos archivos puede reproducir la configuración deseada en cualquier momento.
Nota perev. : Ilustración de la documentación del proyecto para usar superposiciones en kustomizeKustomize puede hacer
mucho más de lo que se describe 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:
Nota perev. : También puede aconsejar el bloque de enlaces publicado como Recursos en el sitio web de la utilidad y la posterior recopilació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 contactarme en
Twitter o en
el canal Kubernetes Slack . ¡Diviértete modificando tus manifiestos con kustomize!
PD del traductor
Lea también en nuestro blog: