Helm Charts en Kubernetes 2026: Empaquetado, Despliegue y Preguntas de Entrevista

Los Helm Charts de Kubernetes simplifican el despliegue de aplicaciones al empaquetar todos los recursos de Kubernetes en un unico artefacto versionado. Helm 3, la version estable actual, elimina la necesidad de Tiller e introduce soporte para registros OCI, haciendo la distribucion de charts mas segura y estandarizada. Este tutorial cubre la creacion de charts, templating, estrategias de despliegue y las preguntas de entrevista mas comunes realizadas por equipos de contratacion.

Comprender la Estructura y Componentes de un Helm Chart

Un Helm chart es un directorio con una estructura predefinida. El nombre del chart se convierte en el nombre del directorio, y cada archivo cumple un proposito especifico en el proceso de empaquetado y despliegue.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

El campo apiVersion: v2 indica compatibilidad con Helm 3. El campo version rastrea los cambios del chart, mientras que appVersion refleja la version de la aplicacion desplegada. Las dependencias declaran otros charts que este chart requiere, con condiciones opcionales para habilitarlas o deshabilitarlas.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Los values definen configuraciones por defecto que los usuarios pueden sobrescribir durante la instalacion. Anidar valores bajo claves significativas mantiene las configuraciones organizadas y autodocumentadas.

Creacion de Deployments de Kubernetes con Templates de Helm

Los templates de Helm utilizan templating de Go con funciones Sprig para generar manifiestos de Kubernetes dinamicamente. El objeto {{ .Values }} proporciona acceso al contenido de values.yaml, mientras que {{ .Release }} contiene metadatos del despliegue.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

La funcion nindent agrega nueva linea e indentacion, elemento critico para la generacion de YAML. El uso de include con templates nombrados (definidos en _helpers.tpl) mantiene los templates DRY y mantenibles.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Los templates helper estandarizan las convenciones de nomenclatura y labels en todos los recursos, asegurando el cumplimiento con los labels recomendados por Kubernetes.

Dependencias y Subcharts de Helm

Las aplicaciones complejas frecuentemente dependen de bases de datos, caches o colas de mensajes. Las dependencias de Helm permiten incrustar estos como subcharts, gestionados automaticamente durante la instalacion.

# Actualizar dependencias antes del empaquetado
helm dependency update ./my-application

# Construir dependencias (crea el directorio charts/)
helm dependency build ./my-application

El comando helm dependency update descarga las dependencias en el directorio charts/. Las dependencias condicionales usan values para alternar su inclusion:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Este patron permite configuraciones especificas por ambiente donde produccion usa servicios gestionados mientras desarrollo usa bases de datos dentro del cluster.

Despliegue de Helm Charts con Gestion de Releases

Helm rastrea los despliegues como releases, habilitando rollbacks y actualizaciones versionadas. Cada release mantiene historial para auditoria y recuperacion.

# Instalar un chart con valores personalizados
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Actualizar una release existente
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

El flag --atomic asegura que las actualizaciones fallidas se reviertan automaticamente. El flag --timeout establece cuanto tiempo espera Helm hasta que los recursos esten listos antes de declarar fallo.

# Ver historial de releases
helm history my-release -n production

# Rollback a revision anterior
helm rollback my-release 2 -n production

# Desinstalar una release
helm uninstall my-release -n production --keep-history

El flag --keep-history preserva los registros de release incluso despues de la desinstalacion, util para cumplimiento y depuracion.

Estrategias de Prueba y Validacion de Helm Charts

Probar los Helm charts antes del despliegue detecta errores de templates y problemas de configuracion tempranamente. Helm proporciona herramientas integradas para linting y pruebas dry-run.

# Verificar chart por errores y mejores practicas
helm lint ./my-application

# Renderizar templates localmente sin desplegar
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run contra la API del cluster
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

El comando helm template renderiza manifiestos localmente, util para pipelines CI que validan el YAML generado. El flag --dry-run envia manifiestos al servidor API de Kubernetes para validacion sin crear recursos.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Los hooks de Helm con helm.sh/hook: test se ejecutan despues de helm test my-release, validando que los despliegues funcionan correctamente post-instalacion.

Tecnicas Avanzadas de Templating en Helm

Los charts de produccion requieren logica condicional, bucles y transformacion de datos. Las funciones Sprig extienden los templates de Go con utilidades para manipulacion de strings, codificacion y control de flujo.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

La funcion range itera sobre maps y listas. La funcion b64enc codifica valores en base64 para secrets de Kubernetes. Los operadores pipe encadenan funciones para transformacion de datos.

Preguntas y Respuestas de Entrevista sobre Helm Charts

Las entrevistas tecnicas frecuentemente evaluan conocimientos de Helm a traves de preguntas conceptuales y practicas. La siguiente seccion cubre los temas mas frecuentemente abordados.

Cual es la diferencia entre helm install y helm upgrade --install?

helm install crea una nueva release y falla si la release ya existe. helm upgrade --install (con el flag --install) crea una nueva release si no existe, o la actualiza si existe. Los pipelines CI/CD tipicamente usan helm upgrade --install para despliegues idempotentes.

Como se pasan datos sensibles a los Helm charts?

Existen tres enfoques: gestores de secrets externos (Vault, AWS Secrets Manager), archivos values cifrados (SOPS, sealed-secrets), o secrets de Kubernetes creados fuera de Helm y referenciados en templates. Se debe evitar almacenar secrets en archivos values.yaml en texto plano commitidos en control de versiones.

Que son los hooks de Helm y cuando se deben usar?

Los hooks se ejecutan en puntos especificos del ciclo de vida de una release: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback, y test. Usos comunes incluyen migraciones de base de datos antes de actualizaciones, envio de notificaciones despues de despliegues, o ejecucion de tests de integracion.

Como se gestiona el versionado de charts?

El campo version en Chart.yaml rastrea cambios del chart usando versionado semantico. El campo appVersion rastrea la version de la aplicacion desplegada. El campo version debe incrementarse para cualquier modificacion del chart, incluso si la version de la aplicacion permanece igual.

Cual es el proposito de .helmignore?

Similar a .gitignore, .helmignore excluye archivos del empaquetado del chart. Entradas tipicas incluyen *.tgz (evitar empaquetar builds anteriores), .git/, documentacion *.md no necesaria en runtime, y archivos de configuracion CI.

Para profundizar en la preparacion de entrevistas de Kubernetes, es posible explorar los modulos de preguntas Kubernetes Basics y Kubernetes Advanced en SharpSkill.

Conclusion

Puntos clave para trabajar con Helm charts:

• Estructurar charts con separacion clara entre metadatos Chart.yaml, valores por defecto values.yaml y directorio templates conteniendo manifiestos Kubernetes
• Usar templates helper en _helpers.tpl para estandarizar nomenclatura y labels en todos los recursos
• Gestionar dependencias via Chart.yaml con habilitacion condicional para configuraciones especificas por ambiente
• Probar charts con helm lint, helm template y helm install --dry-run antes de desplegar en produccion
• Rastrear releases con nombres significativos y usar el flag --atomic para rollback automatico en fallos
• Almacenar secrets en gestores externos en lugar de archivos values en texto plano