Nota perev. : El 16 de mayo de este año es un hito importante en el desarrollo del administrador de paquetes para Kubernetes - Helm. En este día, se presentó la primera versión alfa de la futura versión principal del proyecto: 3.0. Su liberación traerá cambios significativos y muy esperados a Helm, que muchos en la comunidad de Kubernetes tienen grandes esperanzas. Nosotros mismos los tratamos, ya que utilizamos activamente Helm para implementar aplicaciones: lo integramos en nuestra herramienta para implementar CI / CD werf y de vez en cuando hacemos una contribución factible al desarrollo ascendente. Esta traducción reúne 7 notas del blog oficial de Helm, que están programadas para el primer lanzamiento de Helm 3 alpha y cuentan sobre la historia del proyecto y las características principales de Helm 3. Su autor es Matt "bacongobbler" Fisher, un empleado de Microsoft y uno de los principales mantenedores de Helm. El 15 de octubre de 2015, nació el proyecto, ahora conocido como Helm. Solo 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
unió a CNCF como un proyecto de incubación. Avance rápido hasta el presente, y ahora está en camino el primer lanzamiento alfa del nuevo Helm 3
(este lanzamiento ya tuvo lugar a mediados de mayo, aprox. Transl.) .
En este artículo, hablaré sobre cómo comenzó todo, cómo llegamos a la etapa actual, presentaré algunas características únicas disponibles en la primera versión de Helm 3 alpha y explicaré cómo planeamos desarrollarnos más.
Resumen:
- historia de la creación de Helm;
- gentil despedida de Tiller;
- repositorios de cartas;
- gestión de lanzamientos;
- cambios en las dependencias de la carta;
- cartas de la biblioteca;
- que sigue
Historia del timón
Nacimiento
Helm 1 comenzó como un proyecto de código abierto creado por Deis. Fuimos una pequeña startup
absorbida por Microsoft en la primavera de 2017. Nuestro otro proyecto de código abierto, también llamado Deis, tenía una herramienta
deisctl que se utilizó (entre otras cosas) para instalar y operar la plataforma Deis en
el clúster de la flota . Fleet fue una de las primeras plataformas para la orquestación de contenedores en ese momento.
A mediados de 2015, decidimos cambiar de rumbo y transferimos Deis (en ese momento renombrado a Deis Workflow) de Fleet a Kubernetes. Uno de los primeros en rediseñar la
deisctl instalación
deisctl . Lo usamos para instalar y administrar Deis Workflow en un clúster de flota.
Helm 1 se creó a imagen de gestores de paquetes conocidos como Homebrew, apt y yum. Su tarea principal era simplificar tareas como empaquetar e instalar aplicaciones en Kubernetes. Helm se presentó oficialmente en 2015 en la conferencia KubeCon en San Francisco.
Nuestro primer intento con Helm funcionó, pero hubo serias restricciones. Tomó un conjunto de manifiestos de Kubernetes, aromatizado con generadores, como bloques YAML de
primera línea *, y subió los resultados a Kubernetes.
* Nota perev. : Desde la primera versión de Helm, se eligió la sintaxis YAML para describir los recursos de Kubernetes, y las plantillas Jinja y los scripts de Python fueron compatibles al escribir configuraciones. Escribimos más sobre esto y el dispositivo de la primera versión de Helm en el capítulo "Una breve historia de Helm" de este material .Por ejemplo, para reemplazar un campo en un archivo YAML, tenía que agregar la siguiente construcción al manifiesto:
#helm:generate sed -i -es|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml
Es genial que haya motores de plantillas hoy, ¿no?
Por muchas razones, este instalador inicial de Kubernetes requirió una lista codificada de archivos de manifiesto y realizó solo una pequeña secuencia fija de eventos. Fue tan difícil de usar que el equipo de I + D de Deis Workflow tuvo dificultades cuando intentaron transferir su producto a esta plataforma; sin embargo, las semillas de la idea ya estaban sembradas. Nuestro primer intento fue una gran oportunidad de aprendizaje: nos dimos cuenta de que realmente nos apasionaba crear herramientas pragmáticas que resuelvan problemas cotidianos para nuestros usuarios.
Basado en la experiencia de errores pasados, comenzamos a desarrollar Helm 2.
Yelmo de creación 2
A finales de 2015, el equipo de Google nos contactó. Trabajaron en una herramienta similar para Kubernetes. Deployment Manager para Kubernetes fue el puerto de la herramienta existente que se utilizó para Google Cloud Platform. "¿Nos gustaría", preguntaron, "pasar unos días discutiendo las similitudes y diferencias?"
En enero de 2016, los equipos de Helm and Deployment Manager se reunieron en Seattle para intercambiar ideas. Las negociaciones terminaron con un ambicioso plan: combinar ambos proyectos para crear Helm 2. Junto con Deis y Google, los muchachos de
SkippBox (ahora parte de Bitnami - aprox. Transl.) Se unieron al equipo de desarrollo y comenzamos a trabajar en Helm 2.
Queríamos mantener la facilidad de uso de Helm, pero agreguemos lo siguiente:
- plantillas de gráficos para personalización;
- gestión intracluster para equipos;
- Repositorio de gráficos de primera clase
- formato de paquete estable con la capacidad de firmar;
- Fuerte compromiso con las versiones semánticas y el mantenimiento de la compatibilidad con versiones anteriores.
Para lograr estos objetivos, se ha agregado un segundo elemento al ecosistema Helm. Este componente intracluster se llamaba Tiller y estaba involucrado en la instalación de cartas Helm y su gestión.
Desde el lanzamiento de Helm 2 en 2016, Kubernetes ha obtenido varias innovaciones importantes. Se
introdujo el control de acceso basado en
roles (
RBAC ), que finalmente reemplazó al control de acceso basado en atributos (ABAC). Se introdujeron nuevos tipos de recursos (las implementaciones en ese momento aún permanecían en estado beta). Se inventaron definiciones de recursos personalizados (originalmente llamados recursos de terceros o TPR). Y lo más importante, ha aparecido 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 incorporaciones, quedó claro que era hora de realizar cambios significativos en la base del código para que Helm pudiera continuar satisfaciendo las crecientes necesidades de un ecosistema en desarrollo.
Suave despedida de Tiller
Durante el desarrollo de Helm 2, presentamos Tiller como parte de nuestra integración con el Administrador de implementación de Google. Tiller desempeñó un papel importante para los equipos que trabajan dentro de un clúster común: permitió que varios especialistas que operaban la infraestructura interactuaran con el mismo conjunto de lanzamientos.
Dado que el control de acceso basado en roles (RBAC) estaba habilitado por defecto en Kubernetes 1.6, trabajar con Tiller en la producción se volvió más difícil. Debido a la gran cantidad de posibles políticas de seguridad, nuestra posición ha sido proponer permisos por defecto. Esto permitió a los principiantes experimentar con Helm y Kubernetes sin tener que sumergirse primero en la configuración de seguridad. Desafortunadamente, esta configuración permisiva podría dotar al usuario de una amplia gama de permisos que no necesitaba. Los ingenieros de DevOps y SRE tuvieron que aprender pasos operativos adicionales instalando Tiller en un clúster de múltiples inquilinos.
Después de aprender cómo los miembros de la comunidad usan Helm en situaciones específicas, nos dimos cuenta de que el sistema de administración de versiones de Tiller no necesitaba depender de un componente dentro del clúster para mantener el estado o funcionar como un centro central con información de versión. En cambio, podríamos obtener información del servidor API de Kubernetes, generar un gráfico del lado del cliente y guardar el registro de instalación en Kubernetes.
La tarea principal de Tiller podría llevarse a cabo sin Tiller, por lo que una de nuestras primeras decisiones con respecto a Helm 3 fue un rechazo total de Tiller.
Con la partida de Tiller, el modelo de seguridad de Helm se ha simplificado radicalmente. Helm 3 ahora admite todos los métodos modernos de seguridad, identificación y autorización de los Kubernetes de hoy. Los permisos de timón se determinan utilizando
el archivo kubeconfig . Los administradores de clústeres pueden restringir los derechos de los usuarios con cualquier nivel de granularidad. Las versiones todavía se almacenan dentro del clúster, el resto de la funcionalidad de Helm se conserva.
Repositorios de cartas
En un nivel alto, el repositorio de gráficos es un lugar donde puede almacenar y compartir gráficos. El cliente Helm empaqueta y envía los gráficos al repositorio. En pocas palabras, el repositorio de gráficos es un servidor HTTP primitivo con un archivo index.yaml y algunos gráficos empaquetados.
Aunque hay algunas ventajas en que la API del repositorio de gráficos cumple con los requisitos más básicos para el repositorio, también tiene varias desventajas:
- Los repositorios de gráficos son poco compatibles con la mayoría de las implementaciones de seguridad requeridas en un entorno de producción. Tener una API estándar para autenticación y autorización es crucial en los escenarios de producción.
- Las herramientas de Helm para rastrear el origen del gráfico, utilizadas para firmar, verificar la integridad y el origen del gráfico, son una parte opcional del proceso de publicación del Gráfico.
- En escenarios de múltiples usuarios, el mismo gráfico puede ser cargado por otro usuario, duplicando la cantidad de espacio requerido para almacenar el mismo contenido. Se han desarrollado repositorios más inteligentes para resolver este problema, pero no forman parte de la especificación formal.
- El uso de un único archivo de índice para buscar, almacenar metadatos y obtener gráficos complica el desarrollo de implementaciones seguras para múltiples usuarios.
El proyecto
Docker Distribution (también conocido como Docker Registry v2) es el sucesor del Docker Registry y en realidad 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 la distribución. Gracias a esa mayor atención, el proyecto de Distribución se ha beneficiado de muchos años de mejoras, mejores prácticas en el campo de la seguridad y pruebas en condiciones de "combate", que lo han convertido en uno de los héroes anónimos más exitosos del mundo de Código Abierto.
¿Pero sabías que el proyecto de Distribución fue diseñado para distribuir cualquier forma de contenido, no solo imágenes de contenedores?
Gracias a los esfuerzos de la
Open Container Initiative (u OCI), los gráficos Helm se pueden colocar en cualquier instancia de Distribución. Hasta ahora, este proceso es experimental. El trabajo de soporte para inicios de sesión y otras funciones necesarias para un Helm 3 completo aún no ha terminado, pero estamos muy contentos de aprender de los descubrimientos realizados por los equipos de OCI y Distribución a lo largo de los años. Y gracias a su mentoría y liderazgo, aprendemos cuál es la operación de un servicio altamente accesible a gran escala.
Una descripción más detallada de algunos de los próximos cambios en los repositorios de Helm-chart está disponible
aquí .
Gestión de lanzamientos
En Helm 3, el estado de una aplicación se supervisa dentro de un clúster mediante un par de objetos:
- liberar objeto: representa una instancia de la aplicación;
- versión secreta de lanzamiento: representa el estado deseado de la aplicación en un momento determinado (por ejemplo, el lanzamiento de una nueva versión).
Llamar a
helm install crea un objeto de lanzamiento y un secreto de versión de lanzamiento. Llamar a
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 publicación contiene información de publicación, donde la publicación es una instalación específica de un gráfico y valores con nombre. Este objeto describe los 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 la versión de lanzamiento, así como de todos los objetos que se crean directamente en el gráfico Helm.
La versión secreta de la versión asocia una versión con una serie de revisiones (instalación, actualizaciones, reversiones, desinstalación).
En Helm 2, las revisiones fueron extremadamente consistentes. La llamada de
helm install creó v1, la actualización de actualización posterior v2, y así sucesivamente. El lanzamiento y el lanzamiento de la versión secreta se colapsaron en un solo objeto, conocido como revisión. Las revisiones se almacenaron en el mismo espacio de nombres que Tiller, lo que significaba que cada versión era "global" en términos de espacio de nombres; Como resultado, solo se puede usar una instancia del nombre.
En Helm 3, cada versión está asociada con uno o más secretos de versión de versión. El objeto de lanzamiento siempre describe el lanzamiento actual implementado en Kubernetes. Cada versión secreta de la versión describe solo una versión de esta versión. Una actualización, por ejemplo, creará una nueva versión secreta de la versión y luego modificará el objeto de la versión para que apunte a esta nueva versión. En el caso de la reversión, puede usar los secretos de la versión de lanzamiento anterior para revertir el lanzamiento a su estado anterior.
Después de abandonar Tiller, Helm 3 almacena los datos de lanzamiento en un solo espacio de nombres con el lanzamiento. Tal cambio le permite instalar un gráfico con el mismo nombre de versión en un espacio de nombres diferente, y los datos se guardan entre las actualizaciones / reinicios del clúster en etcd. Por ejemplo, puede instalar Wordpress en el espacio de nombres "foo" y luego en el espacio de nombres "barra", y ambas versiones pueden llamarse "wordpress".
Cambios de dependencia de gráficos
Los gráficos empaquetados (usando el
helm package Helm) para usar con Helm 2 se pueden instalar con Helm 3, pero el flujo de trabajo de desarrollo de gráficos se ha revisado por completo, por lo que es necesario realizar algunos cambios para continuar desarrollando gráficos con Helm 3. En particular, el sistema de administración ha cambiado Gráfico de dependencias.
El sistema de gestión de dependencia de gráficos se ha movido de
Chart.yaml y
Chart.lock a
Chart.yaml y
Chart.lock . Esto significa que los gráficos que usan el
helm dependency requieren alguna configuración para funcionar en Helm 3.
Veamos un ejemplo. Agregue una dependencia al gráfico en Helm 2 y vea qué cambios cuando cambia a Helm 3.
En Helm 2
requirements.yaml veía así:
dependencies: - name: mariadb version: 5.xx 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.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
Los
charts/ todavía se cargan y se colocan en el directorio de
charts/ , por lo que los subcartagramas en el directorio de
charts/ continuarán funcionando sin cambios.
Presentación de gráficos de biblioteca
Helm 3 admite una clase de gráfico llamada
gráfico de biblioteca . Este gráfico es utilizado por otros gráficos, pero no crea ningún artefacto de lanzamiento por sí solo. Las plantillas de gráfico de biblioteca solo pueden declarar elementos
define . Otro contenido simplemente se ignora. Esto permite a los usuarios reutilizar y compartir fragmentos de código que se pueden usar en muchos gráficos, evitando así la duplicación y el
cumplimiento del principio
DRY .
Los gráficos de la biblioteca se declaran en la sección de
dependencies del archivo
Chart.yaml . La instalación y administración de ellos no son diferentes de otras tablas.
dependencies: - name: mylib version: 1.xx repository: quay.io
Esperamos con interés los casos de uso que este componente abrirá para los desarrolladores de gráficos, así como las mejores prácticas que puedan surgir de los gráficos de la biblioteca.
Que sigue
Helm 3.0.0-alpha.1: la base sobre la cual comenzamos a crear una nueva versión de Helm. En el artículo describí algunas características interesantes de Helm 3. Muchos de ellos todavía están en las primeras etapas de desarrollo y esto es normal; La esencia de la versión alfa es probar la idea, recopilar comentarios de los primeros usuarios y confirmar nuestras suposiciones.
Tan pronto como se lance la versión alfa
(recuerde que esto ya sucedió , aprox. Transl.) , Comenzaremos a recibir parches para Helm 3 de la comunidad. Es necesario crear una base sólida que le permita desarrollar y adoptar nuevas funcionalidades, y los usuarios podrán sentirse involucrados en el proceso, abriendo tickets y haciendo correcciones.
En el artículo intenté resaltar algunas mejoras serias que aparecerán en Helm 3, pero esta lista no es exhaustiva. El plan a gran escala 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 verificar los valores de los gráficos. También planeamos borrar la base del código y actualizar las partes que se han descuidado durante los últimos tres años.
Si siente que nos hemos perdido algo, ¡nos complacerá escuchar sus pensamientos!
Únase a la discusión en nuestros
canales de Slack :
#helm-users para preguntas y comunicación fácil con la comunidad;#helm-dev para discutir solicitudes de extracción, código y errores.
También puede chatear en nuestras llamadas semanales para desarrolladores públicos los jueves a las 19:30 MSK. Las reuniones están dedicadas a discutir las tareas en las que los desarrolladores clave y la comunidad están trabajando, así como los temas de discusión para la semana. Cualquiera puede unirse y participar en la reunión. El enlace está disponible en el canal
#helm-dev Slack.
PD del traductor
Lea también en nuestro blog: