Eliminación Definitiva del Componente Tiller

Helm 3 ha eliminado por completo el componente servidor Tiller, transformando la herramienta en un cliente puro. Este cambio resuelve problemas críticos de seguridad y operatividad presentes en versiones anteriores. Anteriormente, Tiller requería permisos de ClusterRole que generaban conflictos con los contextos de kubectl, provocando situaciones donde un usuario podía desplegar recursos mediante Helm pero no mediante kubectl.

La arquitectura actual ofrece tres mejoras fundamentaels:

• Herencia directa de permisos desde el contexto de kubectl
• Supresión del comando helm init
• Ámbito de nombres para los nombres de releases

Este enfoque refuerza el principio fundamental: cualquier operación ejecutable con kubectl debe ser posible mediante Helm.

Modelo de Repositorios Distribuidos y Helm Hub

El sistema centralizado de repositorios ha sido reemplazado por una red distribuida. El repositorio stable predeterminado ya no existe, y Helm Hub actúa como índice unificado para descubrir charts. Para instalar una aplicación como PostgreSQL:

helm repo add acme-charts https://charts.acme.com/repository
helm repo update
helm install despliegue-prueba acme-charts/postgresql --set service.port=5432

La búsqueda se realiza directamente en Helm Hub:

helm search hub postgresql --list-repos

Esta arquitectura beneficia a mantenedores al eliminar cuellos de botella en publicación de charts, y a usuarios al garantizar acceso a versiones actualizadas sin retrasos.

Validación Estricta con Esquemas JSON

Los charts pueden definir esquemas JSON para validar valores de entrada. Este mecanismo previene errores comunes como tipos de datos incorrectos. Por ejemplo, al especificar un puerto como cadena:

helm install app-test --set service.port="cinco"

Helm 3 genera un error explícito:

VALORES INVALIDOS:
service.port debe ser un entero (recibido: "cinco")
Esquema requerido: {"type":"integer","minimum":1,"maximum":65535}

Adicionalmente, se implementa validación OpenAPI contra la API de Kubernetes, bloqueando solicitudes con estructuras incorrectas antes de llegar al clúster.

Pruebas Integrdaas con Jobs de Kubernetes

El sistema de pruebas ahora utiliza Jobs en lugar de Pods persistentes. Los recursos de prueba se gestionan automáticamente mediante el ciclo de vida del release:

apiVersion: batch/v1
kind: Job
metadata:
  name: prueba-integracion
  annotations:
    "helm.sh/hook": test-success
spec:
  template:
    spec:
      containers:
        - name: tester
          image: curlimages/curl
          command: ["curl", "-sS", "http://servicio:8080/health"]

Al ejecutar helm test app-test, los Jobs se crean, ejecutan y eliminan automáticamente sin requerir banderas adicionales, facilitando ejecuciones repetidas durante el despliegue.

Sintaxis de Línea de Comandos Revisada

Los comandos han sido rediseñados para mayor coherencia. El nombre del release ahora es obligatorio, pero se puede generar automáticamente:

helm install --generate-name acme-charts/nginx

La eliminación de recursos se simplifica con:

helm uninstall despliegue-prueba

Que elimina automáticamente todos los recursos asociados sin necesidad de --purge. Algunos comandos heredados funcionan como alias, pero se recomienda adoptar la nueva nomenclatura para evitar conflictos en scripts automatizados.