Nota perev. : El mayor interés en el "administrador de paquetes Kubernetes" - Helm, que se ha observado recientemente, es fácil de explicar. La tan esperada actualización principal de Helm v3, sobre la que ya escribimos , se encuentra en la etapa activa, y no solo de desarrollo, sino también de lanzamientos. Su última versión beta, la tercera consecutiva , se lanzó a principios de septiembre. Y recientemente, tuvo lugar un evento bastante grande (para un proyecto de código abierto tan especializado), las impresiones de las que comparten sus visitantes de CloudARK, que ofrece iPaaS (plataforma de integración como servicio) para Kubernetes.
Foto original tomada de la cuenta de Flickr de CNCFHelm Summit se celebró en Amsterdam la semana pasada. Reunió a unos 150 entusiastas que representan a varios usuarios y proveedores de servicios en Kubernetes. Aquí hay cinco puntos clave de este evento.
1. En Helm 3.0: mejor seguridad, soporte CRD y algunos cambios que rompen el enfoque habitual
A la cumbre asistieron algunos de los miembros clave del equipo central de desarrollo de Helm. A partir de sus discursos y comunicaciones al margen, quedó claro que Helm 3.0 será un hito importante para el proyecto. Muchos de ustedes probablemente hayan escuchado que la tercera versión no tendrá Tiller, el componente del servidor Helm.
( Nota : se puede encontrar más información sobre esto en este artículo ). Habrá otras innovaciones importantes en Helm 3.0, como controles de seguridad más estrechos y un mejor soporte para las Definiciones de recursos personalizados (CRD). Aquí hay tres aspectos clave que recuerdo especialmente:
- En el área de seguridad, el conjunto de permisos preconfigurados para los usuarios de forma predeterminada será mínimo. A diferencia de Tiller, que recibió automáticamente derechos de administrador para todo el clúster, en Helm 3.0 deberá otorgar manualmente privilegios a las cuentas de usuario (Usuario) y servicio (Servicio) diseñadas para trabajar con Helm. Este cambio garantiza la toma de decisiones informadas por parte de los administradores sobre la seguridad de sus clústeres.
- El segundo cambio importante es el soporte CRD mejorado. En la versión actual de Helm, CRD se instala a través del
crd-install , definido como una anotación. Sin embargo, no todos los desarrolladores y operadores de CRD lo usan. Esto hace que los gráficos de Helm sean vulnerables a los errores de instalación, ya que la configuración correcta de los gráficos requiere que los CRD se coloquen frente a los manifiestos de recursos personalizados. Helm 3.0 llevará el soporte CRD a un nuevo nivel. El subdirectorio chrts aparecerá en el directorio de crd . Será suficiente para el usuario agregar todos los archivos CRD YAML a este directorio. Helm lo procesará antes de configurar el resto del gráfico. Este procedimiento asegurará que CRD esté instalado antes de instalar manifiestos de recursos personalizados. - Los cambios importantes afectarán el trabajo con la CLI. Por ejemplo, ahora durante la instalación del gráfico, se genera un nombre de lanzamiento aleatorio si no se especifica como parámetro de entrada. En Helm 3.0, la situación será la opuesta: un parámetro con un nombre será obligatorio. Para preservar el nombre aleatorio de las versiones, deberá especificar un indicador especial al ingresar el comando.
2. Consolidación de artefactos nativos en la nube
Varias sesiones se dedicaron a los problemas de almacenamiento de cartas Helm. Estas sesiones fueron dirigidas por
Josh Dolitsky , autor del
ChartMuseum . Presentó el problema, las soluciones existentes y habló sobre las tendencias generales en este espacio. La conclusión principal es que trabajar con varios artefactos que deben abordarse en el enfoque nativo de la nube (imágenes Docker, gráficos Helm, archivos de parche Kustomize) debe hacerse de la misma manera.
El proyecto
ORAS : se solicita el registro OCI como almacenamiento para garantizar el almacenamiento de todos estos artefactos en un único registro. Para los usuarios de Kubernetes, este es definitivamente un paso en la dirección correcta, ya que le permitirá consolidar varios artefactos en un registro, al tiempo que proporciona soporte para cosas como la partición del registro, el control de acceso, etc.
3. Timón y operadores
Varios oradores abordaron el tema de los controladores y operadores de usuarios en sus discursos.
La presentación de CloudARK se centró en las mejores prácticas para crear gráficos Helm para operadores.
El equipo de Red Hat habló sobre los operadores y el
Centro de operadores .
Representantes de
Workday ,
Weaveworks y la
Universidad de Notre Dame en sus discursos discutieron el enfoque nativo de Kubernetes para negociar continuamente las versiones basadas en Helm en un clúster utilizando un proceso llamado GitOps.
( Nota de traducción : Lea más sobre GitOps aquí .)La conclusión clave de todas estas actuaciones fue que Helm y los operadores se complementan bien. Mientras que el primero (Helm) se centra en la plantilla y la simplicidad de la administración de artefactos, los segundos (operadores) se concentran en administrar las tareas del Día 2
(es decir, en la etapa del ciclo de vida del sistema, cuando comienza a dar frutos a sus creadores - aprox. ) para software de terceros, como bases de datos relacionales / no relacionales que se ejecutan en un clúster de Kubernetes.
4. Cuestiones de gestión de cartas de timón
Cuando se trata de aplicaciones empresariales grandes, un diagrama de Helm no es suficiente. Se requieren algunos cuadros.
La presentación de GitLab fue un verdadero descubrimiento en este sentido. Tienen muchos gráficos, mientras que el tamaño promedio del gráfico también es bastante grande (varios miles de líneas). Administrar todos estos gráficos no es una tarea fácil en sí misma.
Hubo dos presentaciones interesantes sobre varios aspectos de este problema. En uno
, el equipo de IBM presentó su herramienta interna que simplifica la búsqueda de gráficos Helm por varios criterios. Se centraron en resolver el problema de los ingenieros de DevOps, que se vieron obligados a seleccionar e instalar gráficos en sus clústeres. En otro,
el equipo replicado habló sobre tratar de resolver el problema de administrar las ediciones de gráficos de Helm sin crear copias o tenedores. La esencia de su enfoque es separar el gráfico básico de Helm y crear gráficos personalizados de Helm tomando prestada la idea de kustomize de los archivos de parche. En el futuro, podemos presenciar una actividad rápida en esta dirección, ya que varios proveedores se concentran en varios aspectos de los gráficos de Helm que influyen en su gestión. Por ejemplo, nosotros en CloudARK nos
enfocamos en los gráficos Helm para operadores que reciben anotaciones especiales de
platform-as-code para que sea más fácil descubrir y hacer que los recursos personalizados sean más fáciles de usar.
5. Comunidad hospitalaria
Los desarrolladores de Helm y los miembros clave de la comunidad resultaron ser personas muy amigables. Estaban abiertos y disponibles para cualquier discusión y pregunta, como fechas de lanzamiento, pensamientos sobre Helm y kustomize, eventos conjuntos con KubeCon, etc.
También hablaron sobre el proceso de participar en el desarrollo de Helm. No parecía demasiado complicado. El proyecto Helm aún no ha adoptado el proceso KEP (Propuesta de mejora de Kubernetes). Sin embargo, esto puede cambiar después de que se complete la etapa de incubación.
CloudARK en Helm Summit
Nuestra presentación en la cumbre se dedicó a los principios y las mejores prácticas de creación de gráficos Helm para operadores. Ofrecemos iPaaS, que permite a los equipos de DevOps crear sus propias pilas de plataformas Kubernetes sin ninguna conexión con el proveedor de Kubernetes o las interfaces propietarias. Los CRD / operadores necesarios se empaquetan en forma de diagramas de Helm con especial énfasis en la compatibilidad de Recursos personalizados de varios operadores.
La presentación se basó en las lecciones aprendidas del desarrollo independiente de varios operadores y el análisis de más de cien operadores disponibles públicamente para obtener una capa de plataforma nativa Kubernetes personalizada, lista para uso corporativo.
Amsterdam
El lugar de la conferencia cuenta con vistas panorámicas de uno de los muchos canales de Ámsterdam.
Conclusión
Helm está a punto de convertirse en un proyecto CNCF de alto nivel. En los últimos años, se ha vuelto más maduro, ha ganado una comunidad fuerte y una gran popularidad. Si aún no lo está utilizando, pruébelo. Ofrece una de las formas más fáciles de crear plantillas y administrar artefactos de Kubernetes. Para aquellos que ya lo usan, Helm 3.0 debería disipar muchas preocupaciones de seguridad y proporcionar soporte explícito para la extensibilidad de Kubernetes a través de CRD.
PD del traductor
Se pueden encontrar otras impresiones del pasado Helm Summit y sus informes en Twitter usando la etiqueta
#HelmSummit .
Lea también en nuestro blog: