🥇 Introducción a Helm 3

Nota de traducción.: 16 de mayo de este año — un hito significativo en la evolución del gestor de paquetes para Kubernetes — Helm. En este día se presentó la primera versión alfa de la futura gran versión del proyecto — 3.0. Su lanzamiento traerá a Helm cambios importantes y muy esperados, en los que muchos en la comunidad de Kubernetes tienen grandes esperanzas. También nos incluimos, ya que utilizamos Helm de manera activa para el despliegue de aplicaciones: lo hemos integrado en nuestra herramienta para implementar CI/CD. werf y de vez en cuando contribuimos en lo que podemos al desarrollo del upstream. Esta traducción reúne 7 notas del blog oficial de Helm, que están relacionadas con el primer lanzamiento alfa de Helm 3 y que hablan sobre la historia del proyecto y las principales características de Helm 3. Su autor es Matt «bacongobbler» Fisher, empleado de Microsoft y uno de los principales mantenedores de Helm.

El 15 de octubre de 2015 nació el proyecto que hoy se conoce como Helm. Apenas un año después de su fundación, la comunidad de Helm se unió a Kubernetes, mientras trabajaba activamente en Helm 2. En junio de 2018, Helm se integró en la CNCF como un proyecto en incubación. Volvamos al presente: ya está próximo el primer lanzamiento alfa del nuevo Helm 3 (este lanzamiento ya se llevó a cabo a mediados de mayo — nota del traductor.).

En este material, hablaré sobre cómo comenzó todo, cómo llegamos a esta etapa actual, presentaré algunas características únicas disponibles en el primer lanzamiento alfa de Helm 3, y explicaré cómo planeamos desarrollarnos en el futuro.

Resumen:

historia de la creación de Helm;
una dulce despedida a Tiller;
repositorios de charts;
gestión de lanzamientos;
cambios en las dependencias de charts;
library charts;
¿y ahora qué?

Historia de la creación de Helm

Nacimiento

Helm 1 comenzó como un proyecto de código abierto, creado por la empresa Deis. Éramos una pequeña startup, absorbida por Microsoft en primavera de 2017. Nuestro otro proyecto de código abierto, también llamado Deis, tenía una herramienta deisctl, que se usaba (entre otras cosas) para instalar y operar la plataforma Deis en un clúster Fleet. En ese momento, Fleet era una de las primeras plataformas para la orquestación de contenedores.

A mediados de 2015 decidimos cambiar de rumbo y trasladamos Deis (en ese momento renombrado a Deis Workflow) de Fleet a Kubernetes. Uno de los primeros fue rehacer la herramienta de instalación deisctl. La utilizamos para instalar y gestionar Deis Workflow en un clúster Fleet.

Helm 1 se creó a imagen y semejanza de conocidos gestores de paquetes, como Homebrew, apt y yum. Su principal objetivo era simplificar tareas como el empaquetado e instalación de aplicaciones en Kubernetes. Helm fue presentado oficialmente en 2015 durante la conferencia KubeCon en San Francisco.

Nuestro primer intento con Helm funcionó, pero no estuvo exento de graves limitaciones. Tomaba un conjunto de manifiestos de Kubernetes, aderezados con generadores como bloques YAML de entrada. (front-matter)*, y cargaba los resultados en Kubernetes.

* Nota de traducción.: Desde la primera versión de Helm, se eligió la sintaxis YAML para describir los recursos de Kubernetes, y al redactar configuraciones se soportaban plantillas Jinja y scripts de Python. Hablamos más sobre esto y sobre la estructura de la primera versión de Helm en el capítulo «Breve Historia de Helm» de este material..

Por ejemplo, para reemplazar un campo en un archivo YAML, había que añadir la siguiente construcción al manifiesto:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Es genial que hoy en día existan generadores de plantillas, ¿verdad?

Por muchas razones, este primer instalador de Kubernetes requería una lista de archivos de manifiesto estrictamente definida y solo ejecutaba una pequeña secuencia fija de eventos. Era tan difícil de usar que al equipo de I+D de Deis Workflow le resultó complicado cuando intentaron migrar su producto a esta plataforma; sin embargo, las semillas de la idea ya se habían sembrado. Nuestro primer intento fue una excelente oportunidad de aprendizaje: nos dimos cuenta de que estábamos realmente apasionados por crear herramientas pragmáticas que resolvieran problemas cotidianos para nuestros usuarios.

Basándonos en las lecciones de errores pasados, comenzamos a desarrollar Helm 2.

Creación de Helm 2

A finales de 2015, el equipo de Google se puso en contacto con nosotros. Estaban trabajando en una herramienta similar para Kubernetes. Deployment Manager para Kubernetes era un puerto de una herramienta existente que se utilizaba para Google Cloud Platform. «¿No querríamos», preguntaron, «pasar unos días discutiendo similitudes y diferencias?»

En enero de 2016, los equipos de Helm y Deployment Manager se encontraron en Seattle para intercambiar ideas. Las negociaciones culminaron en un ambicioso plan: combinar ambos proyectos para crear Helm 2. Junto con Deis y Google, se unieron al equipo de desarrolladores chicos de SkippBox (ahora parte de Bitnami — nota de traducción), y comenzamos a trabajar en Helm 2.

Queríamos mantener la simplicidad del uso de Helm, pero añadir lo siguiente:

plantillas de charts para personalización;
gestión interna del clúster para equipos;
un repositorio de charts de primera clase;
un formato de paquetes estable con la posibilidad de firma;
un fuerte compromiso con el versionado semántico y el mantenimiento de la compatibilidad hacia atrás entre versiones.

Para lograr estos objetivos, se agregó un segundo componente a la ecosistema de Helm. Este componente interno del clúster se llamó Tiller y se encargaba de la instalación y gestión de los charts de Helm.

Desde el lanzamiento de Helm 2 en 2016, Kubernetes ha introducido varias innovaciones importantes. Se implementó el control de acceso basado en roles (RBAC), que eventualmente reemplazó el control de acceso basado en atributos (ABAC). Se presentaron nuevos tipos de recursos (Deployments que todavía estaban en beta en ese momento). Se inventaron las Definiciones de Recursos Personalizados (originalmente llamadas Recursos de Terceros o TPRs). Y, lo más importante, surgió un conjunto de mejores prácticas.

En medio de todos estos cambios, Helm continuó sirviendo fielmente a los usuarios de Kubernetes. Después de tres años y muchas nuevas adiciones, quedó claro que era el momento de realizar cambios significativos en la base de código para que Helm pudiera seguir satisfaciendo las crecientes necesidades de la ecosistema en desarrollo.

Una suave despedida a Tiller

Durante el desarrollo de Helm 2, presentamos Tiller como parte de nuestra integración con el Deployment Manager de Google. Tiller desempeñó un papel importante para los equipos que trabajaban dentro de un clúster compartido: permitía a diferentes especialistas que administraban la infraestructura interactuar con el mismo conjunto de lanzamientos.

Dado que el control de acceso basado en roles (RBAC) se habilitó por defecto en Kubernetes 1.6, trabajar con Tiller en producción se volvió más complicado. Debido a la gran cantidad de posibles políticas de seguridad, nuestra posición era ofrecer una configuración permisiva por defecto. Esto permitía a los principiantes experimentar con Helm y Kubernetes sin necesidad de sumergirse primero en la configuración de seguridad. Desafortunadamente, esta configuración permisiva podría otorgar al usuario un rango de permisos demasiado amplio que no necesitaba. Los ingenieros de DevOps y SRE tenían que estudiar pasos operativos adicionales al instalar Tiller en un clúster multiusuario.

Al entender cómo los representantes de la comunidad utilizan Helm en situaciones específicas, nos dimos cuenta de que el sistema de gestión de lanzamientos de Tiller no necesitaba depender de un componente dentro del clúster para mantener estados o funcionar como un centro central de información sobre el lanzamiento. En su lugar, podríamos simplemente recibir información del servidor API de Kubernetes, generar el chart del lado del cliente y guardar un registro de la instalación en Kubernetes.

La funcionalidad principal de Tiller podría realizarse sin Tiller, así que una de nuestras primeras decisiones respecto a Helm 3 fue eliminar totalmente Tiller.

Con la salida de Tiller, el modelo de seguridad de Helm se simplificó drásticamente. Helm 3 ahora admite todos los métodos modernos de seguridad, identificación y autorización de Kubernetes. Los permisos de Helm se definen mediante el archivo kubeconfig. Los administradores del clúster pueden restringir los derechos de los usuarios con cualquier nivel de detalle. Los lanzamientos aún se mantienen dentro del clúster, y el resto de la funcionalidad de Helm se conserva.

Los repositorios de charts

A un alto nivel, un repositorio de charts es un lugar donde se pueden almacenar y compartir charts. El cliente de Helm empaqueta y envía charts al repositorio. En términos simples, un repositorio de charts es un servidor HTTP primitivo con un archivo index.yaml y algunos charts empaquetados.

Aunque hay algunas ventajas en que la API del repositorio de charts cumpla con los requisitos básicos de almacenamiento, también tiene algunas desventajas:

Los repositorios de charts son poco compatibles con la mayoría de las implementaciones de seguridad necesarias en un entorno de producción. La existencia de una API estándar para la autenticación y autorización es crucial en escenarios de producción.
Las herramientas de Helm para rastrear el origen del chart, utilizadas para la firma, verificación de integridad y origen del chart, son una parte opcional del proceso de publicación del chart.
En escenarios multiusuario, el mismo chart puede ser cargado por otro usuario, duplicando el espacio necesario para almacenar el mismo contenido. Para abordar este problema, se han desarrollado repositorios más inteligentes, aunque no forman parte de la especificación formal.
El uso de un único archivo índice para buscar, almacenar metadatos y obtener charts ha dificultado el desarrollo de implementaciones multiusuario seguras.

Proyecto Docker Distribution (también conocido como Docker Registry v2) es el sucesor de Docker Registry y de hecho actúa como un conjunto de herramientas para empaquetar, enviar, almacenar y entregar imágenes de Docker. Muchos grandes servicios en la nube ofrecen productos basados en Distribution. Debido a esta atención aumentada, el proyecto Distribution se benefició de mejoras a lo largo de los años, mejores prácticas en seguridad y pruebas en condiciones de 'producción', convirtiéndose en uno de los héroes no cantados más exitosos del mundo del Open Source.

Pero, ¿sabías que el proyecto Distribution fue desarrollado para distribuir cualquier forma de contenido, no solo imágenes de contenedores?

Gracias a los esfuerzos de Open Container Initiative (o OCI), los charts de Helm pueden ser alojados en cualquier instancia de Distribution. Hasta ahora, este proceso es experimental. El trabajo en el soporte para inicios de sesión y otras funciones necesarias para un Helm 3 a pleno rendimiento aún no ha finalizado, pero estamos muy emocionados por la oportunidad de aprender de los descubrimientos realizados por los equipos de OCI y Distribution a lo largo de los años. Gracias a su mentoría y orientación, estamos aprendiendo lo que significa operar un servicio de alta disponibilidad a gran escala.

Una descripción más detallada de algunos de los próximos cambios en los repositorios de charts de Helm está disponible. en el enlace.

Gestión de lanzamientos

En Helm 3, el estado de la aplicación se rastrea dentro del clúster mediante un par de objetos:

el objeto de lanzamiento — representa una instancia de la aplicación;
el secreto de la versión de lanzamiento — representa el estado deseado de la aplicación en un momento específico (por ejemplo, el lanzamiento de una nueva versión).

mountsnoop.py helm install crea el objeto de lanzamiento y el secreto de la versión de lanzamiento. Invocación helm upgrade requiere un objeto de lanzamiento (que puede cambiar) y crea un nuevo secreto de versión de lanzamiento que contiene nuevos valores y un manifiesto preparado.

El objeto de lanzamiento contiene información sobre el lanzamiento, donde el lanzamiento es una instalación específica de un gráfico y valores nombrados. Este objeto describe metadatos de nivel superior sobre el lanzamiento. El objeto de lanzamiento se conserva durante todo el ciclo de vida de la aplicación y es el propietario de todos los secretos de versión de lanzamiento, así como de todos los objetos que son creados directamente por el gráfico de Helm.

El secreto de la versión de lanzamiento vincula el lanzamiento con una serie de revisiones (instalación, actualizaciones, retrocesos, eliminación).

En Helm 2, las revisiones eran exclusivamente secuenciales. La invocación helm install creaba v1, la siguiente actualización (upgrade) — v2, y así sucesivamente. El lanzamiento y el secreto de la versión de lanzamiento se fusionaron en un solo objeto conocido como revisión. Las revisiones se almacenaban en el mismo espacio de nombres que Tiller, lo que significaba que cada lanzamiento era 'global' en términos de espacio de nombres; como resultado, solo se podía usar una instancia del nombre.

En Helm 3, cada lanzamiento está vinculado a uno o más secretos de versión de lanzamiento. El objeto de lanzamiento siempre describe el lanzamiento actual desplegado en Kubernetes. Cada secreto de versión de lanzamiento describe solo una versión de este lanzamiento. La actualización (upgrade), por ejemplo, creará un nuevo secreto de versión de lanzamiento y luego modificará el objeto de lanzamiento para que apunte a esta nueva versión. En caso de un retroceso (rollback), se pueden usar los secretos de versión de lanzamiento anteriores para revertir el lanzamiento a su estado previo.

Después de abandonar Tiller, Helm 3 almacena los datos del lanzamiento en el mismo espacio de nombres que el lanzamiento. Este cambio permite instalar un gráfico con el mismo nombre de lanzamiento en otro espacio de nombres, y los datos se mantienen entre actualizaciones/reinicios del clúster en etcd. Por ejemplo, se puede instalar WordPress en el espacio de nombres 'foo', y luego en el espacio de nombres 'bar', y ambos lanzamientos pueden llamarse 'wordpress'.

Cambios en las dependencias de gráficos

Gráficos empaquetados (usando helm package) para usar con Helm 2, se puede instalar con Helm 3, sin embargo, el flujo de trabajo para desarrollar gráficos ha sido completamente revisado, por lo que se deben hacer algunos cambios para continuar desarrollando gráficos con Helm 3. En particular, ha cambiado el sistema de gestión de dependencias de los gráficos.

El sistema de gestión de dependencias del gráfico ha pasado de requirements.yaml y requirements.lock en Chart.yaml y Chart.lock. Esto significa que los gráficos que usaron el comando helm dependency, requieren cierta configuración para funcionar en Helm 3.

Veamos un ejemplo. Agreguemos una dependencia al gráfico en Helm 2 y veamos qué cambiará al pasar a Helm 3.

En Helm 2 requirements.yaml se veía de la siguiente manera:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

En Helm 3, la misma dependencia se reflejará en su Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Los gráficos aún se descargan y se colocan en el directorio charts/, por lo que los subgráficos (subcharts), que se encuentran en el directorio charts/, seguirán funcionando sin cambios.

Presentamos Library Charts

Helm 3 admite una clase de gráficos llamada gráficos de biblioteca (library chart). Este gráfico es utilizado por otros gráficos, pero no produce ningún artefacto de lanzamiento por sí mismo. Las plantillas de los gráficos de biblioteca pueden declarar solo elementos define. Otro contenido simplemente se ignora. Esto permite a los usuarios reutilizar y compartir fragmentos de código que pueden ser utilizados en muchos gráficos, evitando así la duplicación y adhiriéndose al principio de DRY.

Los gráficos de biblioteca se declaran en la sección dependencies en el archivo Chart.yaml. La instalación y gestión de estos no difiere de otros gráficos.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Esperamos con entusiasmo las posibles aplicaciones que este componente abrirá para los desarrolladores de gráficos, así como las mejores prácticas que pueden surgir debido a los gráficos de biblioteca.

¿Qué sigue?

Helm 3.0.0-alpha.1 es la base sobre la cual comenzamos a construir una nueva versión de Helm. En este artículo, describí algunas características interesantes de Helm 3. Muchas de ellas aún se encuentran en las primeras etapas de desarrollo y eso es normal; la esencia de la versión alfa es probar la idea, recopilar comentarios de los primeros usuarios y validar nuestras suposiciones.

Una vez que se publique la versión alfa (recordemos que esto ya ha ocurrido — nota del traductor), comenzaremos a aceptar parches para Helm 3 de la comunidad. Es necesario crear una base sólida que permita desarrollar y aceptar nuevas funcionalidades, y los usuarios podrán sentirse involucrados en el proceso, abriendo tickets y haciendo correcciones.

En este artículo, he intentado resaltar algunas mejoras importantes que llegarán con Helm 3, sin embargo, esta lista no se puede considerar exhaustiva. El plan completo para Helm 3 incluye innovaciones como estrategias de actualización mejoradas, una integración más profunda con los registros OCI y el uso de esquemas JSON para la validación de valores de charts. También planeamos limpiar la base de código y actualizar aquellas partes que han estado descuidadas durante los últimos tres años.

Si sientes que hemos pasado algo por alto, ¡nos encantaría escuchar tus comentarios!

Únete a la discusión en nuestros canales de Slack:

#helm-users para preguntas y comunicación informal con la comunidad;
#helm-dev para discutir pull requests, código y errores.

También puedes participar en nuestras llamadas semanales de desarrolladores públicos los jueves a las 19:30 MSK. Las reuniones se dedican a discutir las tareas en las que trabajan los desarrolladores clave y la comunidad, así como los temas de discusión de la semana. Cualquiera puede unirse y participar en la reunión. El enlace está disponible en el canal de Slack #helm-dev.

P.D. del traductor

También puedes leer en nuestro blog:

Fuente: habr.com