🥇Presentamos Helm 3

Nota. traducir: El 16 de mayo de este año marca un hito importante en el desarrollo del administrador de paquetes para Kubernetes: Helm. Ese día se presentó la primera versión alfa de la futura versión principal del proyecto, la 3.0. Su lanzamiento traerá cambios significativos y largamente esperados a Helm, en los que muchos miembros de la comunidad de Kubernetes tienen grandes esperanzas. Nosotros mismos somos uno de ellos, ya que utilizamos activamente Helm para la implementación de aplicaciones: lo hemos integrado en nuestra herramienta para implementar CI/CD. patio y de caso en caso contribuimos de manera factible al desarrollo del upstream. Esta traducción combina 7 notas del blog oficial de Helm que están dedicadas a la primera versión alfa de Helm 3 y cuentan 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 mantenedores clave 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 Helm se unió a Kubernetes mientras trabajaba activamente en Helm 2. En junio de 2018, Helm se unió a la CNCF como un proyecto en desarrollo (incubación). Un avance rápido hasta el presente, y la primera versión alfa del nuevo Helm 3 está en camino. (este lanzamiento ya ha tenido lugar a mediados de mayo - aprox. trad.).

En este artículo, hablaré sobre dónde comenzó todo, cómo llegamos a donde estamos hoy, presentaré algunas de las características únicas disponibles en la primera versión alfa de Helm 3 y explicaré cómo planeamos seguir desarrollándonos.

Resumen:

la historia de la creación de Helm;
una tierna despedida a Tiller;
repositorios de gráficos;
gestión de la liberación;
cambios en las dependencias de los gráficos;
gráficos de biblioteca;
que siguiente

La historia de Yelmo

Nacimiento

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

A mediados de 2015, decidimos cambiar de rumbo y migramos Deis (luego rebautizado como Deis Workflow) de Fleet a Kubernetes. Uno de los primeros fue la herramienta de instalación rediseñada. deisctl. Lo usamos para instalar y administrar Deis Workflow en el clúster Fleet.

Helm 1 fue creado a imagen de administradores de paquetes famosos como Homebrew, apt y yum. Su principal objetivo 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 no estuvo exento de serias limitaciones. Tomó un conjunto de manifiestos de Kubernetes con generadores como bloques YAML introductorios. (frontera)* y cargó los resultados en Kubernetes.

* Nota. traducir: Desde la primera versión de Helm, se eligió la sintaxis YAML para describir los recursos de Kubernetes, y se admitieron plantillas Jinja y scripts de Python al escribir configuraciones. Escribimos más sobre esto y el dispositivo de la primera versión de Helm en general en el capítulo "Una breve historia de Helm". este material.

Por ejemplo, para reemplazar un campo en un archivo YAML, agregaría la siguiente construcción a su manifiesto:

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

Es genial que existan motores de plantillas hoy en día, ¿no?

Por muchas razones, este primer instalador de Kubernetes requería una lista codificada de archivos de manifiesto y solo ejecutaba una pequeña secuencia fija de eventos. Era 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 se habían sembrado. Nuestro primer intento fue una gran oportunidad de aprendizaje, ya que nos dimos cuenta de que realmente nos apasionaba crear herramientas pragmáticas que resolvieran los problemas cotidianos de nuestros usuarios.

Basándonos en la experiencia de errores pasados, comenzamos a desarrollar Helm 2.

Haciendo el timón 2

A finales de 2015, el equipo de Google se puso en contacto con nosotros. Estaban trabajando en una herramienta similar para Kubernetes. El Administrador de implementación para Kubernetes era una adaptación de una herramienta existente utilizada para Google Cloud Platform. “¿Estamos dispuestos”, preguntaron, “a pasar unos días discutiendo similitudes y diferencias?”

En enero de 2016, los equipos de Helm y Deployment Manager se reunieron en Seattle para intercambiar ideas. Las conversaciones culminaron en un ambicioso plan para fusionar ambos proyectos para crear Helm 2. Junto con Deis y Google, los chicos de Saltar caja (ahora parte de Bitnami - traducción aproximada), y comenzamos a trabajar en Helm 2.

Queríamos mantener la facilidad de uso de Helm, pero agregar lo siguiente:

plantillas de gráficos para personalización;
gestión intracluster para equipos;
repositorio de gráficos de primer nivel;
formato de paquete estable con opción de firma;
un fuerte compromiso con el control de versiones semántico y el mantenimiento de la compatibilidad con versiones anteriores.

Para lograr estos objetivos, se ha agregado un segundo elemento al ecosistema de Helm. Este componente dentro del clúster se llamó Tiller y era responsable de instalar y administrar los gráficos de Helm.

Desde el lanzamiento de Helm 2 en 2016, Kubernetes ha agregado varias innovaciones importantes. Se agregó control de acceso basado en roles (RBAC), que finalmente reemplazó el control de acceso basado en atributos (ABAC). Se introdujeron nuevos tipos de recursos (las implementaciones todavía estaban en versión beta en ese momento). Se inventaron las definiciones de recursos personalizadas (originalmente llamadas 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 ha seguido sirviendo fielmente a los usuarios de Kubernetes. Después de tres años y muchas incorporaciones nuevas, estaba claro que era hora de realizar cambios significativos en el código base para que Helm pudiera continuar satisfaciendo las crecientes necesidades de un ecosistema en evolución.

Un tierno adiós a Tiller

Durante el desarrollo de Helm 2, presentamos Tiller como parte de nuestra integración con el Administrador de implementación de Google. Tiller jugó un papel importante para los equipos que trabajaban dentro de un clúster común: permitió que diferentes especialistas que operaban la infraestructura interactuaran con el mismo conjunto de versiones.

Dado que el control de acceso basado en roles (RBAC) estaba habilitado de forma predeterminada en Kubernetes 1.6, trabajar con Tiller en producción se volvió más difícil. Debido a la gran cantidad de políticas de seguridad posibles, nuestra posición era ofrecer una configuración permisiva 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 otorgar al usuario una gama demasiado amplia de permisos que no necesitaba. Los ingenieros de DevOps y SRE tuvieron que aprender pasos operativos adicionales al instalar Tiller en un clúster multiinquilino.

Al aprender cómo la comunidad usa Helm en situaciones específicas, nos dimos cuenta de que el sistema de gestión de lanzamientos de Tiller no necesita depender de un componente dentro del clúster para mantener los estados o actuar como un centro central para la información de lanzamientos. En cambio, podríamos simplemente obtener información del servidor API de Kubernetes, generar un gráfico en el lado del cliente y guardar un registro de instalación de Kubernetes.

El objetivo principal de Tiller se podía lograr sin Tiller, por lo que una de nuestras primeras decisiones con respecto a Helm 3 fue abandonar por completo a Tiller.

Sin Tiller, el modelo de seguridad de Helm se ha simplificado radicalmente. Helm 3 ahora admite todos los métodos modernos de seguridad, identidad y autorización de los Kubernetes actuales. Los permisos de Helm se determinan usando archivo kubeconfig. Los administradores de clústeres pueden restringir los derechos de los usuarios a cualquier granularidad. Las versiones todavía se almacenan dentro del clúster, el resto de la funcionalidad de Helm se conserva.

Repositorios de gráficos

En un nivel alto, un repositorio de gráficos es un lugar donde se pueden almacenar y compartir gráficos. El cliente Helm empaqueta y envía los gráficos al repositorio. En pocas palabras, un repositorio de gráficos es un servidor HTTP primitivo con un archivo index.yaml y algunos gráficos empaquetados.

Si bien existen algunas ventajas en que la API del repositorio de gráficos cumpla con los requisitos de almacenamiento más básicos, también existen algunas desventajas:

Los repositorios de gráficos no son compatibles con la mayoría de las implementaciones de seguridad necesarias en un entorno de producción. Tener una API estándar para autenticación y autorización es esencial en escenarios de producción.
Las herramientas de procedencia de cartas de Helm, utilizadas para firmar, verificar la integridad y la procedencia de una carta, son una parte opcional del proceso de publicación de cartas.
En escenarios multiusuario, otro usuario puede cargar el mismo gráfico, duplicando la cantidad de espacio necesario para almacenar el mismo contenido. Se han desarrollado repositorios más inteligentes para abordar este problema, sin embargo, no forman parte de la especificación formal.
El uso de un único archivo de índice para buscar, almacenar metadatos y recuperar gráficos ha dificultado el desarrollo de implementaciones multiusuario seguras.

proyecto Distribución de Docker (también conocido como Docker Registry v2) es el sucesor de Docker Registry y en realidad es un conjunto de herramientas para empaquetar, enviar, almacenar y distribuir imágenes de Docker. Muchos grandes servicios en la nube ofrecen productos basados en Distribución. Con esta mayor atención, el proyecto de Distribución se ha beneficiado de años de mejoras, mejores prácticas de seguridad y pruebas de campo que lo han convertido en uno de los héroes anónimos más exitosos del mundo del Código Abierto.

¿Pero sabías que el proyecto Distribution fue diseñado para distribuir cualquier tipo de contenido, no solo imágenes contenedoras?

Gracias a los esfuerzos Iniciativa de contenedor abierto (u OCI), los gráficos de Helm se pueden colocar en cualquier instancia de Distribución. Hasta ahora, este proceso es experimental. El trabajo en soporte de inicio de sesión y otras funciones necesarias para un Helm 3 completo aún está en curso, pero estamos entusiasmados de aprender de los descubrimientos realizados por los equipos de OCI y Distribución a lo largo de los años. Y a través de su tutoría y orientación, estamos aprendiendo cómo es operar un servicio de alta disponibilidad a escala.

Está disponible una descripción más detallada de algunos de los próximos cambios en los repositorios de Helm Chart. enlace.

Gestión de la liberación

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

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

Llamar helm install crea un objeto de lanzamiento y un secreto de versión de lanzamiento. Llamar helm upgrade requiere un objeto de lanzamiento (que puede modificar) y crea un nuevo secreto de versión de lanzamiento que contiene los 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 del gráfico y los valores nombrados. Este objeto describe metadatos de nivel superior sobre la versión. El objeto de lanzamiento persiste 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 creados directamente por el gráfico de Helm.

El secreto de la versión de lanzamiento asocia un lanzamiento con una serie de revisiones (instalación, actualizaciones, reversiones, eliminaciones).

En Helm 2, las revisiones fueron extremadamente consistentes. Llamar helm install creado v1, la actualización posterior (upgrade) - v2, y así sucesivamente. La versión de lanzamiento y el secreto de la versión de lanzamiento se han colapsado 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 versión era "global" en términos de espacio de nombres; como resultado, sólo se podía utilizar 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 versión siempre describe la versión actual implementada en Kubernetes. Cada secreto de versión de lanzamiento describe solo una versión de ese lanzamiento. Una actualización, por ejemplo, creará un secreto de nueva versión de lanzamiento y luego cambiará el objeto de lanzamiento para que apunte a esa nueva versión. En el caso de una reversión, puede utilizar los secretos de la versión anterior para revertir la versión a un estado anterior.

Después de dejar de usar Tiller, Helm 3 almacena los datos de la versión en el mismo espacio de nombres que la versión. Este 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 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 "bar", y ambas versiones pueden denominarse "wordpress".

Cambios en la dependencia del gráfico

Gráficos empaquetados (usando helm package) para usar con Helm 2 se puede instalar con Helm 3; sin embargo, 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 gestión de dependencia de gráficos ha cambiado.

El sistema de gestión de dependencias de Chart pasó de requirements.yaml и requirements.lock en Chart.yaml и Chart.lock. Esto significa que los gráficos que utilizaron el comando helm dependency, requieren alguna configuración para funcionar en Helm 3.

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

En el timón 2 requirements.yaml se veía así:

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 todavía se descargan y se colocan en el directorio. charts/, entonces subgráficos (subgráficos), ubicado en el directorio charts/, seguirá funcionando sin cambios.

Presentación de gráficos de biblioteca

Helm 3 admite una clase de gráficos llamados gráficos de biblioteca (gráfico de la biblioteca). Este gráfico lo utilizan otros gráficos, pero no genera ningún artefacto de publicación por sí solo. Las plantillas de gráficos de biblioteca solo pueden declarar elementos define. El resto del 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 respetando el principio. SECO.

Los gráficos de la biblioteca se declaran en la sección. dependencies en archivo Chart.yaml. Instalarlos y administrarlos no es diferente de otros gráficos.

dependencies:
  - name: mylib
    version: 1.x.x
    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 pueden surgir de los gráficos de la biblioteca.

¿Qué será lo próximo?

Helm 3.0.0-alpha.1 es 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. Muchas de ellas aún se encuentran en las primeras etapas de desarrollo, y esto es normal; El objetivo de una versión alfa es probar la idea, recopilar comentarios de los primeros usuarios y validar nuestras suposiciones.

Tan pronto como se lance la versión alfa (recuerda que esto ya sucedió - aprox. trad.), comenzaremos a aceptar parches para Helm 3 de la comunidad. Es necesario construir una base sólida para permitir que se desarrollen y adopten nuevas funciones, y que los usuarios se sientan involucrados en el proceso abriendo tickets y haciendo correcciones.

Intenté resaltar algunas de las principales mejoras que llegarán a Helm 3, pero esta lista no es exhaustiva. La hoja de ruta completa para Helm 3 incluye características como estrategias de actualización mejoradas, una integración más profunda con los registros OCI y el uso de esquemas JSON para validar los valores del gráfico. También planeamos limpiar el código base y actualizar partes del mismo que se han descuidado durante los últimos tres años.

Si cree que nos hemos perdido algo, ¡nos encantaría escuchar su opinión!

Únase a la discusión en nuestro canales flojos:

#helm-users para consultas y comunicación sencilla con la comunidad;
#helm-dev para discutir solicitudes de extracción, código y errores.

También puede chatear en nuestras llamadas públicas semanales para desarrolladores los jueves a las 19:30 MSK. Las reuniones están dedicadas a discutir las tareas en las que están trabajando 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. Enlace disponible en el canal Slack #helm-dev.

PD del traductor

Lea también en nuestro blog:

Fuente: habr.com

Presentamos el timón 3