Helm

Helm 4.0 explicado: novedades clave, cambios importantes y cómo prepararte para la migración

por
Helm 4.0 explicado: novedades clave, cambios importantes y cómo prepararte para la migración

Helm es uno de las principales utilidades dentro del ecosistema de Kubernetes y por tanto la release de una nueva version major, como es Helm 4.0 es algo a tener en consideración porqué sin dudas es algo que se va a tener que analizar, valorar y gestionar en los próximos meses.

Debido a eso, veremos muchos comentarios y artículos alrededor de este tema, por lo que vamos a intentar mostrar algo de luz.

Principales novedades de Helm 4.0

Según el propio proyecto en su anuncio, Helm 4 introduce tres grandes bloques de cambios: nuevo sistema de plugins, mejor integración con Kubernetes ** y modernización interna de SDK y rendimiento**.

Nuevo sistema de plugins (incluye WebAssembly)

Se ha rediseñado por completo del sistema de plugins, haciendo un enfoque especial en la seguridad mediante la introducción de un nuevo runtime WebAssembly que si bien es opcional, es recomendado dado que se ejecutan en un modo «sandbox» que ofrece limites y garantías desde el punto de vista de la seguridad

De todos modos, no hay que preocuparse en exceso, ya que los plugins “clásicos” siguen funcionando, pero el mensaje es claro: para seguridad y extensibilidad, la dirección es Wasm.

Server-Side Apply y mejor integración con otros controladores

Desde esta versión Helm 4 a través del flag --server-side se soporta Server-Side Apply (SSA) que ya se ha convertido en estable desde la versión v1.22 de Kubernetes y permite llevar al lado del servidor las actualizaciones sobre los objetos para evitar conflictos entre diferentes controladores que gestionan los mismos recursos.

También incorporar integración con kstatus para asegurar el estado de un componente de na una manera más fiable que lo que ocurre actualmente con el uso del parámetro --wait

Otras Mejoras Adicionales

Adicionalmente hay otro listado de mejores que siendo de menor calado son saltos cualitativos de importancia como puede ser los siguiente:

  • Instalación por digest en registries OCI: (helm install myapp oci://...@sha256:<digest>)
  • Valores multi-document: puedes pasar varios YAML de values en un único fichero multi-doc, facilitando entornos / overlays complejos.
  • Nuevo argumento --set-json que permite de una manera sencilla pasar estructuras complejas comparado con la solución actual mediante uso del parámetro --set

¿Por qué una major (v4) y no otra minor de la 3.x?

Tal y como explican en la entrada oficial de lanzamiento había features que el equipo no podía introducir en v3 sin romper APIs públicas del SDK y arquitectura interna:

  • Cambio fuerte en el sistema de plugins (WebAssembly, nuevos tipos, integración profunda con el core).
  • Reestructuración de paquetes Go y establecimiento de un SDK estable en helm.sh/helm/v4, incompatible a nivel de código con v3.
  • Introducción y futura evolución de Charts v3, que requieren que el SDK soporte múltiples versiones de API de charts.

Con todo esto, seguir en la rama 3.x habría violado SemVer: el cambio de número mayor está básicamente “pagando” la deuda técnica acumulada para poder avanzar.

Adicionalmente se espera en el futuro una nueva evolución de las charts, pasando de una v2 a una futura v3 que aun no esta completamente definida y actualmente las charts v2 se ejecutan correctamente en esta nueva versión.

¿Tengo que migrar a esta nueva versión?

La respuesta corta es: si. Y posiblemente la respuesta larga sea: sí, y rápido. En el anuncio oficial de Helm 4 especifican el calendario de soporte de Helm 3:

  • Bugfixes de Helm 3 hasta el 8 de julio de 2026.
  • Security fixes de Helm 3 hasta el 11 de noviembre de 2026.
  • No se backportearán nuevas features a Helm 3 durante ese periodo; únicamente se actualizarán librerías de cliente de Kubernetes para soportar nuevas versiones de K8s.

Traducción práctica:

  • Tienes ~1 año para planificar migración tranquila a Helm 4 con soporte de bugs.
  • Después de noviembre de 2026, seguir usando Helm 3 será cada vez más arriesgado desde el punto de vista de seguridad y compatibilidad.

Buenas prácticas para migración

Para realizar la migración hay que recordar que es perfectamente posible y factible tener instaladas ambas versiones en un misma máquina o agente, por lo que se puede hacer una migración «paulatina» para asegurar que se llega al final del soporte de la versión v3 con todo migrado correctamente, y para eso se recomiendan lo siguientes pasos:

  • Realizar un análisis de todos los comandos y uso de Helm tanto desde el punto de vista de pipelines de integración, scripts de upgrade o incluso la importación de librerías cliente de helm en desarrollos basados en Helm.
  • Especialmente revisar con cautela todos los usos de --post-renderer, helm registry login, --atomic, --force.
  • Posteriormente al análisis empezar a probar Helm 4 primero en entornos no productivos, reutilizando los mismos charts y values, revirtiendo a Helm 3 en caso de que se detecte un problema hasta que este sea sub
  • Si tienes plugins críticos, probarlos explícitamente con Helm 4 antes de hacer el cambio global.

Helm v3.17 y el flag –take-ownership: qué problema resuelve y cuándo deberías usarlo

por
Helm v3.17 y el flag --take-ownership: qué problema resuelve y cuándo deberías usarlo

Helm ha sido durante mucho tiempo el estándar para gestionar aplicaciones de Kubernetes utilizando gráficos empaquetados, aportando un nivel de reproducibilidad y automatización al proceso de implementación. Sin embargo, algunas tareas operativas, como renombrar una versión o migrar objetos entre gráficos, tradicionalmente han requerido soluciones complicadas. Con la introducción del flag --take-ownership en Helm v3.17 (lanzado en enero de 2025), finalmente se aborda un punto de dolor de larga data, al menos parcialmente.

En esta publicación, exploraremos:

  • Qué hace el flag --take-ownership
  • Por qué era necesario
  • Las advertencias y limitaciones
  • Casos de uso del mundo real donde ayuda
  • Cuándo no usarlo

Entendiendo la Propiedad de Objetos en Helm

Cuando Helm instala o actualiza un gráfico, inyecta metadatos—etiquetas y anotaciones—en cada objeto de Kubernetes gestionado. Estos incluyen:

app.kubernetes.io/managed-by: Helm
meta.helm.sh/release-name: my-release
meta.helm.sh/release-namespace: default

Estos metadatos cumplen un papel importante: Helm los utiliza para rastrear y gestionar recursos asociados con cada versión. Como medida de seguridad, Helm no permite que otra versión modifique objetos que no posee y cuando intentas hacerlo verás mensajes como el siguiente:

Error: Unable to continue with install: Service "provisioner-agent" in namespace "test-my-ns" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "dp-core-infrastructure11": current value is "dp-core-infrastructure"

Si bien esto protege a los usuarios de sobrescrituras accidentales, crea limitaciones para casos de uso avanzados.

Por Qué Se Necesitaba --take-ownership

Supongamos que quieres:

  • Renombrar una versión existente de Helm de api-v1 a api.
  • Mover un ConfigMap o Service de un gráfico a otro.
  • Reconstruir el estado durante la reconciliación de GitOps cuando los metadatos anteriores de Helm se han desviado.

Anteriormente, tu única opción era:

  1. Desinstalar la versión existente.
  2. Reinstalar con el nuevo nombre.

Este enfoque introduce tiempo de inactividad, y en sistemas de producción, eso a menudo no es aceptable.

Qué Hace el Flag

helm upgrade my-release ./my-chart --take-ownership

Cuando se pasa este flag, Helm:

  • Omitirá la validación de propiedad para objetos existentes.
  • Sobrescribirá las etiquetas y anotaciones para asociar el objeto con la versión actual.

En la práctica, esto te permite reclamar la propiedad de recursos que anteriormente pertenecían a otra versión, permitiendo transferencias sin problemas.

⚠️ Lo Que No Hace

Este flag no:

  • Limpia referencias de la versión anterior.
  • Te protege de futuras desinstalaciones de la versión original (que aún podrían eliminar recursos compartidos).
  • Te permite adoptar recursos de Kubernetes completamente no gestionados (aquellos no creados inicialmente por Helm).

En resumen, es un mecanismo para eludir las verificaciones de propiedad de Helm, no un gestor de ciclo de vida completo.

Casos de Uso del Mundo Real

Veamos escenarios comunes donde esta característica es útil.

✅ 1. Renombrar una Versión Sin Tiempo de Inactividad

Antes:

helm uninstall old-name
helm install new-name ./chart

Ahora:

helm upgrade new-name ./chart --take-ownership

✅ 2. Migrar Objetos Entre Gráficos

Estás refactorizando un gráfico grande en otros más pequeños y modulares y necesitas reasignar ciertos objetos Service o Secret.

Este flag permite que la nueva versión tome control del objeto sin eliminarlo o recrearlo.

✅ 3. Reconciliación de Desviaciones en GitOps

Si los objetos fueron desplegados fuera de banda o sus metadatos cambiaron sin intención, las herramientas de GitOps que usan Helm pueden recuperarse sin intervención manual usando --take-ownership.

Mejores Prácticas y Recomendaciones

  • Usa este flag intencionalmente, y documenta dónde se aplica.
  • Si es posible, elimina la versión anterior después de la migración para evitar confusiones.
  • Monitorea de cerca el comportamiento de Helm al gestionar objetos compartidos.
  • Para recursos no gestionados por Helm, continúa usando kubectl annotate o kubectl label para alinear manualmente los metadatos.

Conclusión

El flag --take-ownership es una adición bienvenida al arsenal de la CLI de Helm. Aunque no es una solución universal, suaviza muchas de las asperezas que enfrentan los desarrolladores y SREs durante la evolución de versiones y la adopción de GitOps.

Aporta una mejora sutil pero poderosa, especialmente en entornos complejos donde la propiedad de los recursos no es estática.

Mantente actualizado con las versiones de Helm, y considera este flag como tu nuevo aliado en la ingeniería avanzada de versiones.

Consejos y trucos avanzados de Helm: Comandos y banderas poco comunes para una mejor gestión de Kubernetes

por
Consejos y trucos avanzados de Helm: Comandos y banderas poco comunes para una mejor gestión de Kubernetes

Gestionar los recursos de Kubernetes de manera efectiva puede a veces parecer abrumador, pero Helm, el gestor de paquetes de Kubernetes, ofrece varios comandos y banderas que hacen el proceso más fluido e intuitivo. En este artículo, profundizaremos en algunos comandos y banderas menos conocidos de Helm, explicando sus usos, beneficios y ejemplos prácticos.

1. helm get values: Recuperando Valores del Chart Desplegado

El comando helm get values es esencial cuando necesitas ver los valores de configuración de un chart de Helm desplegado. Esto es particularmente útil cuando tienes un chart desplegado pero no tienes acceso a su archivo de configuración original. Con este comando, puedes lograr un enfoque de «Infraestructura como Código» capturando el estado actual de tu despliegue.

Uso:

helm get values <release-name> [flags]
  • <release-name>: El nombre de tu release de Helm.

Ejemplo:

Para obtener los valores de un chart desplegado llamado my-release:

helm get values my-release --namespace my-namespace

Este comando muestra los valores actuales utilizados para el despliegue, lo cual es valioso para la documentación, replicar el entorno o modificar despliegues.

2. Entendiendo las Banderas de helm upgrade: --reset-values, --reuse-values, y --reset-then-reuse

El comando helm upgrade se utiliza típicamente para actualizar o modificar un release de Helm existente. Sin embargo, el comportamiento de este comando puede ajustarse finamente usando varias banderas: --reset-values, --reuse-values, y --reset-then-reuse.

  • --reset-values: Ignora los valores previos y utiliza solo los valores proporcionados en el comando actual. Usa esta bandera cuando quieras sobrescribir completamente la configuración existente.

Escenario de Ejemplo: Estás desplegando una nueva versión de tu aplicación y quieres asegurarte de que no se retengan valores antiguos.

  helm upgrade my-release my-chart --reset-values --set newKey=newValue
  • --reuse-values: Reutiliza los valores del release anterior y los fusiona con cualquier nuevo valor proporcionado. Esta bandera es útil cuando quieres mantener la mayor parte de la configuración antigua pero aplicar algunos ajustes.

Escenario de Ejemplo: Necesitas agregar una nueva variable de entorno a un despliegue existente sin afectar las otras configuraciones.

  helm upgrade my-release my-chart --reuse-values --set newEnv=production
  • --reset-then-reuse: Una combinación de los dos. Se restablece a los valores originales y luego se fusionan los valores antiguos, permitiéndote comenzar con una hoja limpia mientras retienes configuraciones específicas.

Escenario de Ejemplo: Útil en entornos complejos donde quieres asegurarte de que el chart esté usando la configuración predeterminada original pero retener algunos valores personalizados.

  helm upgrade my-release my-chart --reset-then-reuse --set version=2.0

3. helm lint: Asegurando la Calidad del Chart en Pipelines CI/CD

El comando helm lint verifica los charts de Helm en busca de errores de sintaxis, mejores prácticas y otros problemas potenciales. Esto es especialmente útil al integrar Helm en un pipeline CI/CD, ya que asegura que tus charts sean confiables y se adhieran a las mejores prácticas antes del despliegue.

Uso:

helm lint <chart-path> [flags]
  • <chart-path>: Ruta al chart de Helm que deseas validar.

Ejemplo:

helm lint ./my-chart/

Este comando escanea el directorio my-chart en busca de problemas como campos faltantes, estructura YAML incorrecta o uso obsoleto. Si estás automatizando despliegues, integrar helm lint en tu pipeline ayuda a detectar problemas temprano.

Integrando helm lint en un Pipeline CI/CD:

En un pipeline de Jenkins, por ejemplo, podrías agregar la siguiente etapa:

pipeline {
  agent any
  stages {
stage('Lint Helm Chart') {
  steps {
    script {
      sh 'helm lint ./my-chart/'
    }
  }
}
// Otras etapas como build, test, deploy
  }
}

Al agregar esta etapa, aseguras que cualquier problema de sintaxis o estructura se detecte antes de proceder a las etapas de construcción o despliegue.

4. helm rollback: Revertir a un Release Anterior

El comando helm rollback te permite revertir un release a una versión anterior. Esto puede ser increíblemente útil en caso de una actualización o despliegue fallido, ya que proporciona una forma de restaurar rápidamente un estado conocido como bueno.

Uso:

helm rollback <release-name> [revision] [flags]
  • <release-name>: El nombre de tu release de Helm.
  • [revision]: El número de revisión al que deseas revertir. Si se omite, Helm revertirá al release anterior por defecto.

Ejemplo:

Para revertir un release llamado my-release a su versión anterior:

helm rollback my-release

Para revertir a una revisión específica, digamos la revisión 3:

helm rollback my-release 3

Este comando puede ser un salvavidas cuando un cambio reciente rompe tu aplicación, permitiéndote restaurar rápidamente la continuidad del servicio mientras investigas el problema.

5. helm verify: Validando un Chart Antes de Usarlo

El comando helm verify verifica la integridad y validez de un chart antes de que sea desplegado. Este comando asegura que el archivo del paquete del chart no haya sido manipulado o corrompido. Es particularmente útil cuando estás obteniendo charts de repositorios externos o usando charts compartidos entre varios equipos.

Uso:

helm verify <chart-path>
  • <chart-path>: Ruta al archivo del chart de Helm (.tgz file).

Ejemplo:

Para verificar un chart descargado llamado my-chart:

helm verify ./my-chart.tgz

Si el chart pasa la verificación, Helm mostrará un mensaje de éxito. Si falla, verás detalles de los problemas, que podrían ir desde archivos faltantes hasta discrepancias en el checksum.

Conclusión

Aprovechar estos comandos y banderas avanzados de Helm puede mejorar significativamente tus capacidades de gestión de Kubernetes. Ya sea que estés recuperando configuraciones de despliegue existentes, ajustando tus actualizaciones de Helm o asegurando la calidad de tus charts en un pipeline CI/CD, estos trucos te ayudan a mantener un entorno de Kubernetes robusto y eficiente.

Desbloqueando la Flexibilidad y Reutilización: Aprovechando el Poder de los Subgráficos de Múltiples Instancias de Helm

por
Desbloqueando la Flexibilidad y Reutilización: Aprovechando el Poder de los Subgráficos de Múltiples Instancias de Helm

El uso de subgráficos de múltiples instancias de Helm como parte de tu gráfico principal podría ser algo que, desde el principio, puede sonar extraño. Ya comentamos sobre los subgráficos y dependencias de los gráficos de helm en el blog porque el caso de uso habitual es así:

Tengo un gráfico que necesita otro componente, y lo «importo» como un subgráfico, lo que me da la posibilidad de desplegar el mismo componente y personalizar sus valores sin necesidad de crear otra copia del gráfico y, como puedes imaginar, simplificando mucho la gestión de los gráficos, un ejemplo puede ser así:

Descubre cómo múltiples subgráficos pueden revolucionar tus despliegues de Helm. Aprende a aprovechar el poder de la reutilización y personalización, permitiéndote desplegar componentes idénticos con configuraciones únicas. Mejora la flexibilidad y simplifica la gestión con esta avanzada característica de Helm. Desbloquea todo el potencial de tu arquitectura de microservicios y toma el control de despliegues de aplicaciones complejas. Sumérgete en el mundo de múltiples subgráficos y eleva tus gráficos de Helm al siguiente nivel.

Entonces, creo que eso está totalmente claro, pero ¿de qué estamos hablando ahora? El caso de uso es tener el mismo subgráfico definido dos veces. Así que, imagina este escenario, estamos hablando de eso en lugar de esto:

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Estamos teniendo algo como esto

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached-copy1
  version: "3.2.1"
  repository: "https://another.example.com/charts"
- name: memcached-copy2
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Así que tenemos la opción de definir más de una «instancia» del mismo subgráfico. Y supongo que, en este momento, puedes empezar a preguntarte: «¿Cuáles son los casos de uso donde podría necesitar esto?»

Porque eso es bastante comprensible, a menos que lo necesites nunca te darás cuenta de eso. Es lo mismo que me pasa a mí. Así que hablemos un poco sobre posibles casos de uso para esto.

 Casos de Uso para Dependencia de Múltiples Instancias de Helm

Imagina que estás desplegando un gráfico de helm para un conjunto de microservicios que pertenecen al ámbito de la misma aplicación y cada uno de los microservicios tiene la misma base tecnológica, que puede ser TIBCO BusinessWorks Container Edition o pueden ser microservicios Golang. Así que todos ellos tienen la misma base por lo que pueden usar el mismo gráfico «bwce-microservice» o «golang-microservices» pero cada uno de ellos tiene su propia configuración, por ejemplo:

  • Cada uno de ellos tendrá su propio nombre de imagen que diferirá de uno a otro.
  • Cada uno de ellos tendrá su propia configuración que diferirá de uno a otro.
  • Cada uno de ellos tendrá sus propios puntos de conexión que diferirán y probablemente incluso se conectarán a diferentes fuentes como bases de datos o sistemas externos.

Así que, este enfoque nos ayudaría a reutilizar el mismo gráfico de helm tecnológico, «bwce» e instanciarlo varias veces, para que podamos tener cada uno de ellos con su propia configuración sin la necesidad de crear algo «personalizado» y manteniendo los mismos beneficios en términos de mantenibilidad que el enfoque de dependencia de helm nos proporciona.

 ¿Cómo podemos implementar esto?

Ahora que tenemos claro el caso de uso que vamos a soportar, el siguiente paso es sobre cómo podemos hacer esto una realidad. Y, para ser honesto, esto es mucho más simple de lo que puedes pensar desde el principio, comencemos con la situación normal cuando tenemos un gráfico principal, llamémoslo un «programa», que ha incluido una plantilla «bwce» como una dependencia como puedes ver aquí:

name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon: 
appVersion: 2.7.2

dependencies:
- name: bwce
  version: ~1.0.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"

Y ahora, vamos a movernos a un enfoque de múltiples instancias donde requeriremos dos microservicios diferentes, llamémoslos serviceA y serviceB, y ambos usarán el mismo gráfico de helm bwce.

Así que lo primero que modificaremos es el Chart.yaml de la siguiente manera:

name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon: 
appVersion: 2.7.2

dependencies:
- name: bwce
  alias: serviceA
  version: ~0.2.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"
- name: bwce
  alias: serviceB
  version: ~0.2.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"

La parte importante aquí es cómo declaramos la dependencia. Como puedes ver en el nombre seguimos manteniendo el mismo «nombre» pero tienen un campo adicional llamado «alias» y este alias es lo que nos ayudará a identificar más tarde las propiedades para cada una de las instancias según lo requiramos. Con eso, ya tenemos nuestra definición de instancia de serviceA y serviceB y podemos comenzar a usarlo en el values.yml de la siguiente manera:

# Este es un archivo con formato YAML.
# Declara variables para ser pasadas a tus plantillas.

serviceA:
  image: 
    imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceA:2.5.2
    pullPolicy: Always
serviceB:  
  image: 
    imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceB:2.5.2
    pullPolicy: Always

 Conclusión

El principal beneficio de esto es que mejora las opciones de usar gráficos de helm para aplicaciones «complejas» que requieren diferentes instancias del mismo tipo de componentes y al mismo tiempo.

Eso no significa que necesites un gráfico de helm enorme para tu proyecto porque esto iría en contra de todas las mejores prácticas del enfoque de contenedorización y microservicios, pero al menos te dará la opción de definir diferentes niveles de abstracción como desees, manteniendo todos los beneficios desde una perspectiva de gestión.

Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado en 10 Minutos

por
Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado en 10 Minutos

Las plantillas de Helm en archivos, como el contenido de ConfigMaps o el contenido de Secrets, son uno de los requisitos más comunes cuando estás en el proceso de crear un nuevo helm chart. Como ya sabes, el Helm Charts es cómo usamos Kubernetes para empaquetar nuestros recursos de aplicación y YAML en un solo componente que podemos gestionar de una vez para facilitar el proceso de mantenimiento y operación.

Visión General de las Plantillas de Helm

Por defecto, el proceso de plantillas funciona con archivos YAML, permitiéndonos usar algunas variables y algunas funciones lógicas para personalizar y templar nuestros recursos YAML de Kubernetes según nuestras necesidades.

Entonces, en resumen, solo podemos tener archivos yaml dentro de la carpeta de plantillas de un YAML. Pero a veces nos gustaría hacer el mismo proceso en ConfigMaps o Secrets o ser más concretos con el contenido de esos ConfigMaps, por ejemplo, archivos de propiedades y así sucesivamente.

Plantillas de Helm en Archivos: Cómo Personalizar el Contenido de ConfigMaps Simplificado
Plantillas de Helm en Archivos: Visión General de las Plantillas de Helm mostrando los Archivos fuera de las plantillas que usualmente se requieren

Como puedes ver, es bastante normal tener diferentes archivos como archivos de configuración json, archivos de propiedades, scripts de shell como parte de tu helm chart, y la mayoría de las veces te gustaría dar un enfoque dinámico a su contenido, y es por eso que usar Plantillas de Helm en Archivos es tan importante para ser el enfoque principal de este artículo

Funciones de Ayuda de Helm para Gestionar Archivos

Por defecto, Helm nos proporciona un conjunto de funciones para gestionar archivos como parte del helm chart para simplificar el proceso de incluirlos como parte del gráfico, como el contenido de ConfigMap o Secret. Algunas de estas funciones son las siguientes:

  • .Files.Glob: Esta función permite encontrar cualquier patrón de archivos internos que coincida con el patrón, como el siguiente ejemplo:
    { range $path, $ := .Files.Glob ".yaml" }
  • .Files.Get: Esta es la opción más simple para reunir el contenido de un archivo específico que conoces la ruta completa dentro de tu helm chart, como el siguiente ejemplo: {{ .Files.Get "config1.toml" | b64enc }}

Incluso puedes combinar ambas funciones para usarlas juntas como en el siguiente ejemplo:

 {{ range $path, $_ :=  .Files.Glob  "**.yaml" }}
      {{ $.Files.Get $path }}
{{ end }}

Luego puedes combinar eso una vez que tengas el archivo que deseas usar con algunas funciones de ayuda para introducir fácilmente en un ConfigMap y un Secret como se explica a continuación:

  • .AsConfig : Usa el contenido del archivo para ser introducido como ConfigMap manejando el patrón: nombre-del-archivo: contenido-del-archivo
  • .AsSecrets: Similar al anterior, pero haciendo la codificación base64 para los datos.

Aquí puedes ver un ejemplo real de usar este enfoque en una situación real de helm chart

apiVersion: v1
kind: Secret
metadata:
  name: zones-property
  namespace: {{ $.Release.Namespace }}
data: 
{{ ( $.Files.Glob "tml_zones_properties.json").AsSecrets | indent 2 }}

Puedes encontrar más información sobre eso aquí. Pero esto solo nos permite tomar el archivo tal cual e incluirlo en un ConfigMap. No nos permite hacer ninguna lógica o sustitución al contenido como parte de ese proceso. Entonces, si queremos modificar esto, este no es un ejemplo válido.

¿Cómo Usar Plantillas de Helm en Archivos como ConfigMaps o Secrets?

En caso de que podamos hacer algunas modificaciones al contenido, necesitamos usar la siguiente fórmula:

apiVersion: v1
kind: Secret
metadata:
  name: papi-property
  namespace: {{ $.Release.Namespace }}
data:
{{- range $path, $bytes := .Files.Glob "tml_papi_properties.json" }}
{{ base $path | indent 2 }}: {{ tpl ($.Files.Get $path) $ | b64enc }}
{{ end }}

Entonces, lo que estamos haciendo aquí es primero iterar por los archivos que coinciden con el patrón usando la función .Files.Glob que explicamos antes, iterando en caso de que tengamos más de uno. Luego creamos manualmente la estructura siguiendo el patrón: nombre-del-archivo: contenido-del-archivo.

Para hacer eso, usamos la función base para proporcionar solo el nombre del archivo desde una ruta completa (y agregar la indentación adecuada) y luego usamos .Files.Get para obtener el contenido del archivo y hacer la codificación base64 usando la función b64enc porque, en este caso, estamos manejando un secreto.

El truco aquí es agregar la función tpl que permite que el contenido de este archivo pase por el proceso de plantillas; así es como todas las modificaciones que necesitamos hacer y las variables referenciadas desde el objeto .Values serán reemplazadas adecuadamente, dándote todo el poder y flexibilidad del helm chart en archivos de texto como propiedades, archivos JSON y mucho más.

¡Espero que esto sea tan útil para ti como lo ha sido para mí al crear nuevos gráficos de helm! Y mira aquí para otros trucos usando bucles en helm o dependencias de helm.

Dependencia de Helm: Descubre Cómo Funciona

por
Dependencia de Helm: Descubre Cómo Funciona
Tabla de contenidos
  1. ¿Qué es una Dependencia de Helm?
  2. ¿Cómo declaramos una Dependencia de Helm?
  3. ¿Cómo declaro una Dependencia Condicional de Helm?
  4. ¿Cómo declaro una Dependencia de Helm con una versión diferente?

La Dependencia de Helm es una parte crítica para entender cómo funciona Helm, ya que es la forma de establecer relaciones entre diferentes paquetes de helm. Hemos hablado mucho aquí sobre qué es Helm, y algunos temas relacionados, e incluso proporcionamos algunos trucos si creas tus gráficos.

Entonces, como se comentó, Helm Chart no es más que un paquete que colocas alrededor de los diferentes objetos de Kubernetes que necesitan ser desplegados para que tu aplicación funcione. La comparación habitual es que es similar a un Paquete de Software. Cuando instalas una aplicación que depende de varios componentes, todos esos componentes se empaquetan juntos, y aquí es lo mismo.

¿Qué es una Dependencia de Helm?

Una Dependencia de Helm no es más que la forma en que defines que tu Chart necesita otro chart para funcionar. Por supuesto, puedes crear un Helm Chart con todo lo que necesitas para desplegar tu aplicación, pero a veces te gustaría dividir ese trabajo en varios charts simplemente porque son fáciles de mantener o el caso de uso más común porque quieres aprovechar otro Helm Chart que ya está disponible.

Un caso de uso puede ser una aplicación web que requiere una base de datos, por lo que puedes crear en tu Helm Chart todos los archivos YAML para desplegar tu aplicación web y tu base de datos en Kubernetes, o puedes tener tus archivos YAML para tu aplicación web (Deployment, Services, ConfigMaps,…) y luego decir: Y necesito una base de datos y para proporcionarla voy a usar este chart.

Esto es similar a cómo funciona con los paquetes de software en sistemas UNIX; tienes tu paquete que hace el trabajo, como, por ejemplo, A, pero para que ese trabajo se realice, requiere la biblioteca L, y para asegurar que cuando estás instalando A, la Biblioteca L ya esté allí o si no, se instalará, declaras que tu aplicación A depende de la Biblioteca L, así que aquí es lo mismo. Declaras que tu Chart depende de otro Chart para funcionar. Y eso nos lleva al siguiente punto.

¿Cómo declaramos una Dependencia de Helm?

Este es el siguiente punto; ahora que entendemos qué es una Dependencia de Helm conceptualmente y tenemos un caso de uso, ¿cómo podemos hacer eso en nuestro Helm Chart?

Todo el trabajo se realiza en el archivo Chart.yml. Si recuerdas, el archivo Chart.yml es el archivo donde declaras todos los metadatos de tu Helm Chart, como el nombre, la versión del chart, la versión de la aplicación, la URL de ubicación, el icono y mucho más. Y generalmente tiene una estructura como esta:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"

Así que aquí podemos agregar una sección dependencies y, en esa sección es donde vamos a definir los charts de los que dependemos. Como puedes ver en el fragmento a continuación:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: 1.0.0
  repository: "file:///location_of_my_chart"

Aquí estamos declarando Dependency como nuestra Dependencia de Helm. Especificamos la versión que nos gustaría usar (similar a la versión que decimos en nuestro chart), y eso nos ayudará a asegurar que proporcionaremos la misma versión que ha sido probada como parte de la resolución de la dependencia y también la ubicación usando una URL que puede ser una URL externa si esto está apuntando a un Helm Chart que está disponible en internet o fuera de tu computadora o usando una Ruta de Archivo en caso de que estés apuntando a un recurso local en tu máquina.

Eso hará el trabajo de definir la dependencia de helm, y de esta manera, cuando instales tu chart usando el comando helm install, también proporcionará la dependencia.

¿Cómo declaro una Dependencia Condicional de Helm?

Hasta ahora, hemos aprendido cómo declarar una dependencia, y cada vez que aprovisiono mi aplicación, también proporcionará la dependencia. Pero generalmente nos gustaría tener un enfoque más detallado para eso. Imagina el mismo escenario anterior: Tenemos nuestra Aplicación Web que depende de la Base de Datos, y tenemos dos opciones, podemos aprovisionar la base de datos como parte de la instalación de la aplicación web, o podemos apuntar a una base de datos externa y en ese caso, no tiene sentido aprovisionar la Dependencia de Helm. ¿Cómo podemos hacer eso?

Entonces, fácil, porque uno de los parámetros opcionales que puedes agregar a tu dependencia es condition y hacer exactamente eso, condition te permite especificar una bandera en tu values.yml que en el caso sea igual a true, proporcionará la dependencia pero en el caso sea igual a false omitirá esa parte similar al fragmento mostrado a continuación:

 apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: 1.0.0
  repository: "file:///location_of_my_chart"
  condition: database.enabled

Y con eso, estableceremos el parámetro enabled bajo database en nuestro values.yml a true si nos gustaría aprovisionarlo.

¿Cómo declaro una Dependencia de Helm con una versión diferente?

Como se muestra en los fragmentos anteriores, ofrecemos que cuando declaramos una Dependencia de Helm, especificamos la versión; esa es una forma segura de hacerlo porque asegura que cualquier cambio realizado en el chart de helm no afectará tu paquete. Sin embargo, al mismo tiempo, no puedes estar al tanto de correcciones de seguridad o parches en el chart que te gustaría aprovechar en tu implementación.

Para simplificar eso, tienes la opción de definir la versión de una manera más flexible usando el operador ~ en la definición de la versión, como puedes ver en el fragmento a continuación:

apiVersion: v2
name: MyChart
description: My Chart Description
type: application
version: 0.2.0
appVersion: "1.16.0"
dependencies:
- name: Dependency
  version: ~1.0.0
  repository: "file:///location_of_my_chart"
  condition: database.enabled

Esto significa que cualquier parche realizado en el chart será aceptado, por lo que esto es similar a que este chart usará la última versión de 1.0.X. Sin embargo, no usará la versión 1.1.0, por lo que eso permite tener más flexibilidad, pero al mismo tiempo mantener las cosas seguras y protegidas en caso de un cambio importante en el Chart del que dependes. Esta es solo una forma de definir eso, pero la flexibilidad es enorme ya que las versiones de Chart usan «Versiones Semánticas», Puedes aprender y leer más sobre eso aquí: https://github.com/Masterminds/semver.

Bucles de Helm: Truco de Helm #1

por
Bucles de Helm: Truco de Helm #1
Tabla de contenidos
  1. Introducción
  2. Introducción a los Bucles de Helm
  3. ¿Cómo crear un Bucle de Helm?
  4. ¿Cómo acceder a elementos principales dentro de un Bucle de Helm?

Introducción

Descubre cómo agregar bucles de Helm a tus helm charts para proporcionar un comportamiento más dinámico a tus Helm Charts.

Los Helm Charts se están convirtiendo en la solución predeterminada de facto cuando deseas empaquetar tu implementación de Kubernetes para poder distribuirla o instalarla rápidamente en tu sistema.

Definido varias veces como el apt para Kubernetes por su similitud con el antiguo gestor de paquetes de distribuciones GNU/Linux similares a Debian, parece seguir creciendo en popularidad cada mes en comparación con otras soluciones similares incluso más integradas en Kubernetes como Kustomize, como puedes ver en la imagen de Google Trends a continuación:

Helm Loops: Helm Charts vs Kustomize

Pero crear estos helm charts no es tan fácil como parece. Si ya has estado trabajando en ello, probablemente te hayas atascado en algún punto, o hayas pasado mucho tiempo tratando de hacer algunas cosas. Si es la primera vez que estás creando uno o intentando hacer algo avanzado, espero que todos estos trucos te ayuden en tu camino. Hoy vamos a cubrir uno de los trucos más importantes, y esos son los bucles de Helm.

Introducción a los Bucles de Helm

Si ves cualquier helm chart, seguro que tendrás muchos bloques condicionales. Prácticamente todo está cubierto bajo una estructura if/else basada en los archivos values.yml que estás creando. Pero esto se vuelve un poco complicado cuando hablamos de bucles. Pero lo bueno es que tendrás la opción de ejecutar un bucle de helm dentro de tus helm charts usando la primitiva range.

¿Cómo crear un Bucle de Helm?

El uso de la primitiva range es bastante simple, ya que solo necesitas especificar el elemento que deseas iterar, como se muestra en el fragmento a continuación:

{{- range .Values.pizzaToppings }}
- {{ . | title | quote }}
{{- end }}

Este es un ejemplo bastante simple donde el yaml iterará sobre los valores que has asignado a la estructura pizzaToppings en tu values.yml.

Hay algunos conceptos a tener en cuenta en esta situación:

  • Puedes acceder fácilmente a todo dentro de esta estructura que estás recorriendo. Entonces, si el ingrediente de la pizza tiene campos adicionales, puedes acceder a ellos con algo similar a esto:
{{- range.Values.pizzaToppings }}
- {{ .ingredient.name | title | quote }}
{{- end }}

Y esto accederá a una estructura similar a esta en tu values.yml:

 pizzaToppings:
	- ingredient:
		name: Piña
		weight: 3

Lo bueno es que puedes acceder a su atributo subyacente sin replicar toda la jerarquía principal hasta llegar a la estructura de bucle porque dentro de la sección de rango, el alcance ha cambiado. Nos referiremos a la raíz de cada elemento que estamos iterando.

¿Cómo acceder a elementos principales dentro de un Bucle de Helm?

En la sección anterior, cubrimos cómo podemos acceder fácilmente al atributo interno dentro de la estructura de bucle debido al cambio de alcance, lo que también tiene un problema. En caso de que quiera acceder a algún elemento en el padre de mi archivo values.yml o en algún lugar fuera de la estructura, ¿cómo puedo acceder a ellos?

Lo bueno es que también tenemos una gran respuesta para eso, pero puedes llegar allí. Necesitamos entender un poco sobre los alcances en Helm.

Como se comentó, . se refiere al elemento raíz en el alcance actual. Si nunca has definido una sección de rango u otra primitiva que cambie el contexto, . siempre se referirá a la raíz de tu values.yml. Es por eso que cuando ves un helm chart, ves todas las estructuras con la siguiente forma de trabajar: .Values.x.y.z, pero ya hemos visto que cuando tenemos una sección range, esto está cambiando, por lo que esta no es una buena manera.

Para resolver eso, tenemos el contexto $ que se refiere constantemente a la raíz del values.yml sin importar cuál sea el alcance actual. Así que eso significa que si tengo el siguiente values.yml:

base:
	- type: slim 
pizzaToppings:
	- ingredient:
		name: Piña
		weight: 3
	- ingredient:
		name: Manzana
		weight: 3

Y quiero referirme al tipo base dentro de la sección de rango similar a antes, puedo hacerlo usando el siguiente fragmento:

{{- range .Values.pizzaToppings }}
- {{ .ingredient.name | title | quote }} {{ $.Values.base.type }}
{{- end }}

Eso generará la siguiente salida:

 - Piña slim
 - Manzana slim

¡Así que espero que este truco de helm chart te ayude con la creación, modificación o mejora de tus helm charts mejorados en el futuro utilizando bucles de helm sin ninguna preocupación adicional!