Cómo instalar aplicaciones en Kubernetes utilizando Helm

Helm es una herramienta que se conoce como el gestor de paquetes de Kubernetes porque cumple, en el ámbito de un clúster de Kubernetes, un papel muy parecido al que cumplen los gestores de paquetes de un sistema operativo respecto al software instalado en una máquina. Así como en un sistema un gestor de paquetes permite instalar, actualizar y desinstalar programas junto con sus dependencias mediante comandos sencillos, Helm permite instalar, actualizar y desinstalar aplicaciones completas en Kubernetes de forma igual de cómoda. La razón por la que esta herramienta resulta tan valiosa es que desplegar una aplicación en Kubernetes de manera manual suele requerir escribir y aplicar numerosos manifiestos en formato YAML, que describen los distintos objetos que la aplicación necesita, como el objeto que gestiona las réplicas de los contenedores, el que la expone dentro del clúster, el que gestiona el acceso desde el exterior o los que guardan la configuración y las credenciales. Manejar todos esos manifiestos a mano es tedioso y propenso a errores, y se complica aún más cuando la misma aplicación debe desplegarse en varios entornos, como desarrollo y producción, con pequeñas variaciones, lo que lleva a duplicar y editar archivos. Helm resuelve esto empaquetando todos esos manifiestos en una unidad reutilizable llamada chart, en la que los valores concretos están parametrizados en lugar de fijos, de modo que un mismo chart sirve para múltiples entornos simplemente cambiando los valores que se le proporcionan. De este modo, instalar una aplicación se reduce a un comando, personalizarla consiste en aportar un conjunto de valores propios, y actualizarla o revertirla a una versión anterior se convierte también en operaciones de un solo comando gracias a que Helm lleva un historial de versiones de cada instalación. En definitiva, Helm se llama el gestor de paquetes de Kubernetes porque convierte el despliegue de aplicaciones complejas, que de otro modo implicaría gestionar montañas de YAML, en algo repetible, parametrizable, versionado y reversible, del mismo modo que un gestor de paquetes simplifica la instalación de software.

Un chart es la unidad de empaquetado de Helm, es decir, el paquete que contiene todo lo necesario para desplegar una aplicación en Kubernetes, y equivale conceptualmente a lo que sería un paquete instalable en un gestor de paquetes tradicional. Un chart consiste principalmente en un conjunto de plantillas de los manifiestos de Kubernetes que la aplicación requiere, acompañadas de metadatos que describen el chart, como su nombre y su versión, y de un archivo de valores por defecto. La característica esencial que hace potente a un chart es que sus manifiestos no contienen valores fijos, sino parámetros o marcadores que se rellenan en el momento de la instalación con los valores que se le proporcionen. Esto significa que un mismo chart puede producir configuraciones distintas de la aplicación según los valores que reciba, sin necesidad de modificar sus plantillas. Por ejemplo, el número de réplicas, la versión de la imagen del contenedor, el dominio de acceso o la cantidad de recursos asignados pueden ser parámetros que se ajustan al instalar, de manera que el mismo chart sirva para un entorno de desarrollo modesto y para un entorno de producción robusto simplemente cambiando esos valores. Los charts pueden obtenerse de repositorios públicos, donde existen multitud de aplicaciones comunes ya empaquetadas y listas para instalar, como bases de datos, servidores web, controladores de acceso o herramientas de monitorización, y también pueden crearse charts propios para las aplicaciones internas de una organización, de modo que su despliegue quede estandarizado y reutilizable. Cuando se instala un chart en un clúster, se genera lo que se llama un release, que es una instancia concreta y con nombre de esa instalación, y Helm guarda el historial de sus versiones. Gracias a los charts, en lugar de mantener y editar manualmente montones de manifiestos duplicados para cada aplicación y cada entorno, se dispone de una plantilla única y parametrizable que centraliza y simplifica todo el despliegue, aportando orden, reutilización y coherencia.

La personalización de una aplicación instalada con Helm se realiza mediante los valores, que son los datos concretos que se proporcionan a un chart para rellenar los parámetros de sus plantillas y así adaptar el despliegue a las necesidades particulares, sin tener que modificar las plantillas del propio chart. Todo chart incluye un archivo de valores por defecto que define los ajustes que se aplicarán si no se indica lo contrario, y esos valores por defecto pueden sobrescribirse de dos maneras principales. La forma recomendada y más ordenada es crear un archivo de valores propio, en el que se especifican únicamente aquellos ajustes que se desean cambiar respecto a los valores por defecto, como por ejemplo el número de réplicas, la versión de la imagen, el dominio, las opciones de almacenamiento o los límites de recursos, y proporcionar ese archivo al instalar o actualizar mediante la opción correspondiente; este enfoque tiene la ventaja de que el archivo de valores puede versionarse junto con el resto de la configuración, quedando documentado y reproducible. La segunda forma es indicar valores puntuales directamente en la línea de comandos mediante la opción que permite establecer un valor concreto, lo cual resulta cómodo para cambios rápidos o pruebas, aunque es menos adecuado para configuraciones estables porque no queda registrado en un archivo. Un aspecto muy útil de este modelo es que se pueden mantener distintos archivos de valores para distintos entornos, por ejemplo uno para desarrollo y otro para producción, de manera que el mismo chart genere despliegues adaptados a cada caso simplemente seleccionando el archivo de valores adecuado al instalar. Todo aquello que no se especifica en los valores propios conserva el valor por defecto definido en el chart. Antes de aplicar una personalización en un entorno real, es muy recomendable comprobar qué manifiestos generará Helm con esos valores, usando las opciones que permiten renderizar las plantillas o simular la instalación sin aplicarla, lo que ayuda a detectar valores mal puestos antes de que afecten al clúster. Este sistema de valores es lo que hace que un único chart sea tan flexible y reutilizable.

Una de las grandes ventajas de Helm frente a aplicar manifiestos manualmente es la forma sencilla en que gestiona el ciclo de vida de un despliegue, permitiendo actualizarlo y revertirlo con comandos únicos gracias a que mantiene un historial de versiones de cada release. Cuando se quiere modificar una aplicación ya instalada, ya sea porque ha salido una versión nueva del chart o porque se desean cambiar sus valores de configuración, se utiliza la operación de actualización, que aplica los cambios al release existente y crea una nueva revisión, conservando el registro de las anteriores. Esto es importante porque significa que Helm no se limita a aplicar el estado actual, sino que recuerda por qué versiones ha pasado el despliegue. Si tras una actualización se detecta que algo ha ido mal, por ejemplo porque la nueva versión introduce un fallo o una configuración incorrecta, Helm permite revertir el despliegue a una revisión anterior mediante la operación de reversión, que devuelve la aplicación al estado en que se encontraba en esa revisión previa, todo ello con un único comando y sin tener que reconstruir manualmente la configuración antigua. Para saber a qué revisión volver, se puede consultar el historial del release, que lista las distintas revisiones por las que ha pasado. Este mecanismo de actualización y reversión aporta una enorme tranquilidad operativa, porque convierte los despliegues en operaciones seguras y reversibles, reduciendo el riesgo de que un cambio problemático deje la aplicación en un estado difícil de recuperar. Conviene distinguir la actualización de una reinstalación desde cero: la actualización respeta el release y su historial, mientras que desinstalar e instalar de nuevo pierde ese historial y el estado asociado. También es recomendable, antes de actualizar en un entorno crítico, simular la operación o revisar los manifiestos que se generarán, para anticipar el efecto del cambio. En conjunto, la gestión de releases con historial, actualización y reversión es una de las razones por las que Helm resulta tan valioso para operar aplicaciones en Kubernetes de forma controlada.

Sí, es muy recomendable conocer los fundamentos de Kubernetes antes de usar Helm, porque Helm no es una alternativa que sustituya la necesidad de entender Kubernetes, sino una herramienta que se apoya en él y que simplifica su uso, pero que en última instancia genera y gestiona objetos de Kubernetes por debajo. Un chart de Helm, cuando se instala, produce los mismos manifiestos que se escribirían a mano, como los objetos que gestionan las réplicas de contenedores, los que exponen la aplicación, los que gestionan el acceso externo o los que guardan configuración y credenciales, solo que de forma empaquetada y parametrizada. Esto tiene una consecuencia práctica importante: si algo falla en el despliegue, por ejemplo si los contenedores no arrancan, si la aplicación no es accesible o si aparece un comportamiento inesperado, diagnosticar y resolver el problema requiere entender esos objetos de Kubernetes subyacentes y saber inspeccionarlos con las herramientas propias del clúster. Quien intenta usar Helm sin una base de Kubernetes tiende a tratarlo como una caja negra, capaz de instalar aplicaciones cuando todo va bien, pero incapaz de comprender o solucionar los problemas cuando surgen, lo que limita mucho su utilidad y puede llevar a situaciones bloqueadas. Por ello, lo aconsejable es adquirir primero una comprensión sólida de los conceptos esenciales de Kubernetes, como los pods que ejecutan los contenedores, los objetos que gestionan su despliegue y escalado, los que exponen los servicios dentro y fuera del clúster, y las nociones de configuración, almacenamiento y espacios de nombres, y a partir de ahí incorporar Helm como una capa que hace más cómodo y reutilizable el despliegue de aplicaciones. De hecho, entender Kubernetes hace que Helm resulte mucho más comprensible, porque se ve con claridad qué está generando cada chart y por qué. En resumen, Helm y Kubernetes no compiten, sino que se complementan: Kubernetes es la base imprescindible y Helm es la herramienta que facilita trabajar con ella, de modo que conviene dominar lo primero para aprovechar de verdad lo segundo.

Los charts de Helm se obtienen principalmente de repositorios, que son colecciones de charts publicados y accesibles, y existen tanto repositorios públicos con multitud de aplicaciones comunes ya empaquetadas como repositorios privados o propios de una organización para sus aplicaciones internas. En el ámbito público existen catálogos donde se pueden buscar y descubrir charts para software muy habitual, como bases de datos, servidores web, sistemas de mensajería, controladores de acceso o herramientas de monitorización, mantenidos por sus proyectos o por la comunidad, lo que permite desplegar aplicaciones conocidas de forma rápida sin tener que empaquetarlas uno mismo. Para usarlos, se añade el repositorio correspondiente a la configuración local de Helm y se actualiza su índice, tras lo cual se puede instalar cualquier chart de ese repositorio indicando su nombre. En cuanto a la seguridad, es un aspecto que hay que tomarse en serio, porque instalar un chart implica desplegar en el clúster los objetos y las imágenes de contenedor que ese chart define, de modo que un chart de origen dudoso podría introducir software no deseado, configuraciones inseguras o incluso componentes maliciosos. Por ello, la recomendación es instalar charts únicamente desde fuentes de confianza, como los repositorios oficiales de los proyectos, los mantenidos por organizaciones reputadas o los propios internos, y desconfiar de charts de procedencia desconocida. Además, conviene revisar qué va a desplegar un chart antes de instalarlo, algo que se puede hacer renderizando sus plantillas con los valores previstos para ver los manifiestos resultantes, así como fijar la versión concreta del chart que se instala para garantizar que futuras instalaciones sean reproducibles y no traigan cambios inesperados. También es importante no incluir secretos ni credenciales en texto plano en los archivos de valores que se versionan, gestionándolos en su lugar mediante mecanismos seguros. Con estas precauciones, es decir, usar fuentes fiables, revisar lo que se despliega, fijar versiones y manejar bien los secretos, la instalación de charts con Helm es segura y muy conveniente, permitiendo aprovechar el enorme ecosistema de aplicaciones empaquetadas disponible.