Los «Helm umbrella charts» describen y encapsulan una colección desplegable de componentes Kubernetes débilmente acoplados como un «Helm chart» de orden superior. En otras palabras, una colección de elementos de software que tienen cada uno sus propios charts individuales pero que, por la razón que sea (por ejemplo, opciones de diseño, facilidad de despliegue, complejidades de versionado), deben instalarse o actualizarse como una unidad atómica.
Si queréis empezar con Helm lo mejor es que le echéis un vistazo a esta pequeña guía en gitea o a los apuntes que hice en un curso de Apasoft Training. Para que os hagáis una idea, en el siguiente gráfico podéis ver un sencillo esquema de la arquitectura de Helm.
Índice
¿Qué es Helm?
Helm te ayuda a administrar las aplicaciones de Kubernetes. Podrás definir, instalar y actualizar incluso la aplicación de Kubernetes más compleja. Las Charts son fáciles de crear, versionar, compartir y publicar. Le llaman el gestor de paquetes de kubernetes.
En la versión 2 se utilizaba un servidor llamado «Tiller» y el problema que tenía es que había que
configurar la seguridad para conectarse con Kubernetes. Ahora RBAC está integrado con
Kubernetes, con lo cuál evitamos todas la configuración.
Helm Umbrella Charts
Un caso de uso simple para un gráfico Umbrella podría ser el de una aplicación web con un componente web-scraper separado que extrae información para una base de datos. En este ejemplo trivial, la aplicación web y el scraper se describirían cada uno en sus propios Charts que pueden desplegarse individualmente. Para los propósitos del ejemplo, asumamos que una aplicación no arrancaría sin la otra, y debido a alguna razón heredada, las dos no pueden ser desplegadas por separado. Este es un buen caso de uso para un Umbrella Chart, ya que encapsularía ambas aplicaciones en una única unidad desplegable. Helm se asegurará de que el fallo de instalación o actualización de uno de los componentes devuelva a ambos a su estado anterior.
Separación de funciones
En el ejemplo anterior, tanto la aplicación web como la aplicación scraper que la acompaña se describen en sus propios Charts. Por supuesto, el Umbrella Chart de orden superior que engloba estos dos simplemente incluiría las versiones correctas de estos gráficos en la sección de dependencias del archivo Charts.yaml de la siguiente manera:
dependencies:
-name: web-application
version: 4.3.8
-name: web-scraper
version: 2.2.9
Los archivos values.yaml de las aplicaciones individuales contendrán normalmente las versiones de las imágenes y las etiquetas de los artefactos de ambas aplicaciones generados en el momento de la compilación.
images:
name: web-application
tag: 7.6.1.327 ----------------------------images:
name: web-scraper
tag: 9.2.7.426
Un Umbrella Chart hace referencia a la versión del propio Chart y no a la versión subyacente de la imagen contenedora. Esto significa que cualquier cambio en la versión de la imagen resultará en modificaciones en los Charts de los componentes individuales.
Aunque esto funcionará, en la práctica no es particularmente eficiente y no suele ser una buena práctica cuando se hace un uso exclusivo de los Umbrella Charts para desplegar aplicaciones subyacentes. En primer lugar, las pilas de aplicaciones que necesitan hacer uso de los gráficos paraguas suelen tener más de dos dependencias. El efecto neto de esto es que para cada versión de un componente de software, el número de versión de la etiqueta en los gráficos Helm individuales tendrá que ser incrementado. Si está haciendo uso de un museo de cartas, esto significa actualizar las versiones de las etiquetas de imagen en cada carta que haya sido construida y enviar nuevas versiones de estas cartas a un Chart Museum (Servidor de repositorios de Chart de Helm), normalmente con un nuevo número de versión de tag. Los nuevos números de versión de los subcharts deberán actualizarse también en el Chart general. Por supuesto, se podría argumentar que las herramientas de CI pueden hacer esto fácilmente – y pueden (cualquier cosa se puede programar), pero ¿deberían?
¿qué ha cambiado desde la perspectiva de Kubernetes? Pues muy poco. Sí, la versión del software ha cambiado, pero en la mayoría de los casos, una actualización de la versión del software no tiene ningún impacto en la forma en que la aplicación se despliega en un entorno Kubernetes. Dado que Helm describe la forma en que las aplicaciones se instalan en un entorno junto con otras variables de entorno, la versión del software no es un elemento estructural que requiera la actualización de una versión del gráfico Helm, ni necesariamente subirla a Chart Museum.
Dicho esto, todavía hay que conseguir que la nueva versión del software se refleje en el Helm Umbrella Charts para poder desplegarlo, así que ¿cómo lo conseguimos? Para hacer que esto funcione, una vez más usamos la sección global del fichero values.yaml. Esta sección es exclusiva de los Umbrella Charts y permite que los subcharts hagan referencia a variables de los Umbrella Charts.
global:
image:
tags:
web-application: 7.6.1.327
web-scraper: 9.2.7.426
Al permitir que los subcharts hereden las tags de las versiones del Umbrella Chart, como en el ejemplo anterior, se mitiga la sobrecarga de tener que mantener las versiones de los Charts hijos y cada subchart individual no tiene que mutar cada vez que se realiza una publicación. Por lo tanto, el Umbrella Chart sirve como lugar central para describir una Release multiaplicación.
Aunque este enfoque puede desviarse de la intención de versionado de los Charts Helm, hace que trabajar con Umbrella Charts sea mucho más fácil. Normalmente, la versión de un subchart difiere de la versión del software subyacente que describe el Chart. Por lo tanto, cuando se hace referencia a un subchart en un Umbrella Chart, la versión de la aplicación no es obvia. Para evitarlo, se puede cambiar la versión del subchart para que coincida con la versión de la imagen, pero así se pierde la lógica de versionar el Chart sólo cuando se realizan cambios significativos.
¿En qué casos no es aplicable?
En proyectos en los que sólo se despliegan Charts independientes / subcharts individualmente, normalmente las versiones de las tags de imagen de los charts de Helm se actualizan directamente en cada chart. Por supuesto, esto debería seguir siendo así ya que no hay ningún chart de orden superior desplegando el sub-chart.
Incluso cuando se utilizan Umbrella Charts, uno puede querer controlar la versión de la imagen en el sub-chart, sobre todo si partes de un proyecto que están haciendo uso de sub-chart como un chart independiente.
Conclusión
Cuando se utilizan Umbrella Charts para desplegar un stack multicomponente, especialmente cuando los subcomponentes del stack rara vez, o nunca, se desplegarán de forma independiente, tiene sentido migrar las versiones de imagen al Umbrella Chart y mantenerlas allí. Ejemplos de este tipo de proyectos son aquellos en los que existe una estricta gobernanza de versiones y un gestor de versiones empaqueta un conjunto de Charts para lanzarlos a un entorno de producción. Este es el caso de grandes empresas y del sector público, pero, por supuesto, no siempre.
Al tratar los subcharts como recetas solo para el despliegue, el versionado y la liberación de Charts individuales se mantienen al mínimo y solo son necesarios cuando es necesario desarrollar en un subchart individual, es decir, cambiar la forma en que se despliega en un entorno Kubernetes y no cada vez que cambia una versión de la aplicación.
