Arquitectura de Helm
Este documento describe la arquitectura de Helm a alto nivel.
El propósito de Helm
Helm es una herramienta para gestionar paquetes Kubernetes llamados charts. Helm puede hacer lo siguiente:
- Crear nuevos charts desde cero
- Empaquetar charts en archivos de charts (tgz)
- Interactuar con repositorios de charts donde se almacenan charts
- Instalar y desinstalar charts en un clúster Kubernetes existente
- Gestionar el ciclo de lanzamiento de los charts instalados con Helm
Para Helm, hay tres conceptos importantes:
- El chart es un conjunto de información necesaria para crear una instancia de una aplicación de Kubernetes.
- El config contiene información de configuración que puede fusionarse en un chart empaquetado para crear un objeto desplegable.
- Un release es una instancia en ejecución de un chart, combinado con un config específico.
Componentes
Helm es un ejecutable que se implementa en dos partes distintas:
El cliente Helm es un cliente de línea de comandos para usuarios finales. El cliente es responsable de lo siguiente:
- Desarrollo de charts locales
- Gestión de repositorios
- Gestión de releases
- Interfaz con la biblioteca Helm
- Envío de charts para su instalación
- Solicitud de actualización o desinstalación de releases existentes
La biblioteca Helm proporciona la lógica para ejecutar todas las operaciones de Helm. Interactúa con el servidor API de Kubernetes y proporciona la siguiente capacidad:
- Combinar un chart y una configuración para construir un release
- Instalar charts en Kubernetes y proporcionar el objeto release subsiguiente
- Actualizar y desinstalar charts interactuando con Kubernetes
La biblioteca standalone de Helm encapsula la lógica de Helm para que pueda ser aprovechada por diferentes clientes.
Implementación
El cliente y la biblioteca Helm están escritos en el lenguaje de programación Go.
La biblioteca utiliza la biblioteca cliente de Kubernetes para comunicarse con Kubernetes. Actualmente, esa biblioteca utiliza REST+JSON. Almacena información en Secrets ubicados dentro de Kubernetes. No necesita su propia base de datos.
Los archivos de configuración se escriben, cuando es posible, en YAML.