{"id":34735,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/znakomstvo-s-helm-3\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"znakomstvo-s-helm-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introducci\u00f3n a Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introducci\u00f3n a Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota de traducci\u00f3n.<\/b>: 16 de mayo de este a\u00f1o \u2014 un hito significativo en la evoluci\u00f3n del gestor de paquetes para Kubernetes \u2014 Helm. En este d\u00eda se present\u00f3 la primera versi\u00f3n alfa de la futura gran versi\u00f3n del proyecto \u2014 3.0. Su lanzamiento traer\u00e1 a Helm cambios importantes y muy esperados, en los que muchos en la comunidad de Kubernetes tienen grandes esperanzas. Tambi\u00e9n nos incluimos, ya que utilizamos Helm de manera activa para el despliegue de aplicaciones: lo hemos integrado en nuestra herramienta para implementar CI\/CD. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> y de vez en cuando contribuimos en lo que podemos al desarrollo del upstream. Esta traducci\u00f3n re\u00fane 7 notas del blog oficial de Helm, que est\u00e1n relacionadas con el primer lanzamiento alfa de Helm 3 y que hablan sobre la historia del proyecto y las principales caracter\u00edsticas de Helm 3. Su autor es Matt \u00abbacongobbler\u00bb Fisher, empleado de Microsoft y uno de los principales mantenedores de Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>El 15 de octubre de 2015 naci\u00f3 el proyecto que hoy se conoce como Helm. Apenas un a\u00f1o despu\u00e9s de su fundaci\u00f3n, la comunidad de Helm se uni\u00f3 a Kubernetes, mientras trabajaba activamente en Helm 2. En junio de 2018, Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">se integr\u00f3 en la CNCF<\/a><\/noindex> como un proyecto en incubaci\u00f3n. Volvamos al presente: ya est\u00e1 pr\u00f3ximo el primer lanzamiento alfa del nuevo Helm 3 <i>(este lanzamiento <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">ya se llev\u00f3 a cabo<\/a><\/noindex> a mediados de mayo \u2014 nota del traductor.)<\/i>.<\/p>\n<p>En este material, hablar\u00e9 sobre c\u00f3mo comenz\u00f3 todo, c\u00f3mo llegamos a esta etapa actual, presentar\u00e9 algunas caracter\u00edsticas \u00fanicas disponibles en el primer lanzamiento alfa de Helm 3, y explicar\u00e9 c\u00f3mo planeamos desarrollarnos en el futuro.<\/p>\n<p>Resumen:<\/p>\n<ul>\n<li>historia de la creaci\u00f3n de Helm;<\/li>\n<li>un despedida entra\u00f1able de Tiller;<\/li>\n<li>repositorios de charts;<\/li>\n<li>gesti\u00f3n de lanzamientos;<\/li>\n<li>cambios en las dependencias de charts;<\/li>\n<li>library charts;<\/li>\n<li>\u00bfy ahora qu\u00e9?<\/li>\n<\/ul>\n<p><\/p>\n<h2>Historia de la creaci\u00f3n de Helm<\/h2>\n<p><\/p>\n<h3>Nacimiento<\/h3>\n<p>\nHelm 1 comenz\u00f3 como un proyecto de c\u00f3digo abierto, creado por la empresa Deis. \u00c9ramos una peque\u00f1a startup, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">absorbida<\/a><\/noindex> por Microsoft en primavera de 2017. Nuestro otro proyecto de c\u00f3digo abierto, tambi\u00e9n llamado Deis, ten\u00eda una herramienta <code>deisctl<\/code>, que se usaba (entre otras cosas) para instalar y operar la plataforma Deis en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">un cl\u00faster Fleet<\/a><\/noindex>. En ese momento, Fleet era una de las primeras plataformas para la orquestaci\u00f3n de contenedores.<\/p>\n<p>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\u00f3n <code>deisctl<\/code>. La utilizamos para instalar y gestionar Deis Workflow en un cl\u00faster Fleet.<\/p>\n<p>Helm 1 se cre\u00f3 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\u00f3n de aplicaciones en Kubernetes. Helm fue presentado oficialmente en 2015 durante la conferencia KubeCon en San Francisco.<\/p>\n<p>Nuestro primer intento con Helm funcion\u00f3, pero no estuvo exento de graves limitaciones. Tomaba un conjunto de manifiestos de Kubernetes, aderezados con generadores como bloques YAML de entrada. <i>(front-matter)<\/i>*, y cargaba los resultados en Kubernetes.<\/p>\n<p><i>* <b>Nota de traducci\u00f3n.<\/b>: Desde la primera versi\u00f3n de Helm, se eligi\u00f3 la sintaxis YAML para describir los recursos de Kubernetes, y al redactar configuraciones se soportaban plantillas Jinja y scripts de Python. Hablamos m\u00e1s sobre esto y sobre la estructura de la primera versi\u00f3n de Helm en el cap\u00edtulo \u00abBreve Historia de Helm\u00bb <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">de este material.<\/a><\/noindex>.<\/i><\/p>\n<p>Por ejemplo, para reemplazar un campo en un archivo YAML, hab\u00eda que a\u00f1adir la siguiente construcci\u00f3n al manifiesto:<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\nEs genial que hoy en d\u00eda existan generadores de plantillas, \u00bfverdad?<\/p>\n<p>Por muchas razones, este primer instalador de Kubernetes requer\u00eda una lista de archivos de manifiesto estrictamente definida y solo ejecutaba una peque\u00f1a secuencia fija de eventos. Era tan dif\u00edcil de usar que al equipo de I+D de Deis Workflow le result\u00f3 complicado cuando intentaron migrar su producto a esta plataforma; sin embargo, las semillas de la idea ya se hab\u00edan sembrado. Nuestro primer intento fue una excelente oportunidad de aprendizaje: nos dimos cuenta de que est\u00e1bamos realmente apasionados por crear herramientas pragm\u00e1ticas que resolvieran problemas cotidianos para nuestros usuarios.<\/p>\n<p>Bas\u00e1ndonos en las lecciones de errores pasados, comenzamos a desarrollar Helm 2.<\/p>\n<h3>Creaci\u00f3n de Helm 2<\/h3>\n<p>\nA 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. \u00ab\u00bfNo querr\u00edamos\u00bb, preguntaron, \u00abpasar unos d\u00edas discutiendo similitudes y diferencias?\u00bb<\/p>\n<p>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: combinar ambos proyectos para crear Helm 2. Junto con Deis y Google, se unieron al equipo de desarrollo algunos chicos de <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(ahora parte de Bitnami \u2014 nota de traducci\u00f3n)<\/i>, y comenzamos a trabajar en Helm 2.<\/p>\n<p>Quer\u00edamos mantener la simplicidad del uso de Helm, pero a\u00f1adir lo siguiente:<\/p>\n<ul>\n<li> plantillas de charts para personalizaci\u00f3n;<\/li>\n<li> gesti\u00f3n interna del cl\u00faster para equipos;<\/li>\n<li> un repositorio de charts de primera clase;<\/li>\n<li> un formato de paquetes estable con la posibilidad de firma;<\/li>\n<li> un fuerte compromiso con el versionado sem\u00e1ntico y el mantenimiento de la compatibilidad hacia atr\u00e1s entre versiones.<\/li>\n<\/ul>\n<p>\nPara lograr estos objetivos, se agreg\u00f3 un segundo componente a la ecosistema de Helm. Este componente interno del cl\u00faster se llam\u00f3 Tiller y se encargaba de la instalaci\u00f3n y gesti\u00f3n de los charts de Helm.<\/p>\n<p>Desde el lanzamiento de Helm 2 en 2016, Kubernetes ha introducido varias innovaciones importantes. Se implement\u00f3 el control de acceso basado en roles (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), que eventualmente reemplaz\u00f3 el control de acceso basado en atributos (ABAC). Se presentaron nuevos tipos de recursos (Deployments que todav\u00eda estaban en beta en ese momento). Se inventaron las Definiciones de Recursos Personalizados (originalmente llamadas Recursos de Terceros o TPRs). Y, lo m\u00e1s importante, surgi\u00f3 un conjunto de mejores pr\u00e1cticas.<\/p>\n<p>En medio de todos estos cambios, Helm continu\u00f3 sirviendo fielmente a los usuarios de Kubernetes. Despu\u00e9s de tres a\u00f1os y muchas nuevas adiciones, qued\u00f3 claro que era el momento de realizar cambios significativos en la base de c\u00f3digo para que Helm pudiera seguir satisfaciendo las crecientes necesidades de la ecosistema en desarrollo.<\/p>\n<h2>Una despedida entra\u00f1able de Tiller<\/h2>\n<p>\nDurante el desarrollo de Helm 2, presentamos a Tiller como parte de nuestra integraci\u00f3n con Deployment Manager de Google. Tiller desempe\u00f1\u00f3 un papel importante para los equipos que trabajaban dentro de un cl\u00faster compartido: permit\u00eda a diversos especialistas que operaban la infraestructura interactuar con el mismo conjunto de lanzamientos.<\/p>\n<p>Dado que el control de acceso basado en roles (RBAC) estaba habilitado por defecto en Kubernetes 1.6, trabajar con Tiller en producci\u00f3n se volv\u00eda m\u00e1s complicado. Debido al gran n\u00famero de pol\u00edticas de seguridad posibles, nuestra postura era proponer una configuraci\u00f3n permisiva de forma predeterminada. Esto permit\u00eda a los novatos experimentar con Helm y Kubernetes sin necesidad de profundizar primero en la configuraci\u00f3n de seguridad. Lamentablemente, esta configuraci\u00f3n permisiva pod\u00eda otorgar al usuario un rango de permisos demasiado amplio que no necesitaba. Los ingenieros de DevOps y SRE ten\u00edan que aprender pasos operativos adicionales al instalar Tiller en un cl\u00faster de m\u00faltiples inquilinos (multi-tenant).<\/p>\n<p>Al conocer c\u00f3mo los representantes de la comunidad utilizan Helm en situaciones espec\u00edficas, nos dimos cuenta de que el sistema de gesti\u00f3n de lanzamientos de Tiller no necesitaba depender de un componente interno del cl\u00faster para mantener estados o funcionar como un centro central con informaci\u00f3n sobre los lanzamientos. En su lugar, podr\u00edamos simplemente obtener informaci\u00f3n del servidor API de Kubernetes, generar un chart del lado del cliente y guardar un registro de instalaci\u00f3n en Kubernetes.<\/p>\n<p>La tarea principal de Tiller se pod\u00eda realizar sin Tiller, por lo que una de nuestras primeras decisiones respecto a Helm 3 fue eliminar por completo a Tiller.<\/p>\n<p>Con la salida de Tiller, el modelo de seguridad de Helm se simplific\u00f3 radicalmente. Helm 3 ahora admite todos los m\u00e9todos modernos de seguridad, identificaci\u00f3n y autorizaci\u00f3n del actual Kubernetes. Los permisos de Helm se definen mediante <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">el archivo kubeconfig<\/a><\/noindex>. Los administradores del cl\u00faster pueden restringir los derechos de los usuarios con cualquier nivel de detalle. Los lanzamientos a\u00fan se mantienen dentro del cl\u00faster, y el resto de la funcionalidad de Helm se conserva.<\/p>\n<h2>Los repositorios de charts<\/h2>\n<p>\nA un alto nivel, un repositorio de charts es un lugar donde se pueden almacenar y compartir charts. El cliente de Helm empaqueta y env\u00eda charts al repositorio. En t\u00e9rminos simples, un repositorio de charts es un servidor HTTP primitivo con un archivo index.yaml y algunos charts empaquetados.<\/p>\n<p>Aunque hay algunas ventajas en que la API del repositorio de charts cumpla con los requisitos b\u00e1sicos de almacenamiento, tambi\u00e9n tiene algunas desventajas:<\/p>\n<ul>\n<li> Los repositorios de charts son poco compatibles con la mayor\u00eda de las implementaciones de seguridad necesarias en un entorno de producci\u00f3n. La existencia de una API est\u00e1ndar para la autenticaci\u00f3n y autorizaci\u00f3n es crucial en escenarios de producci\u00f3n.<\/li>\n<li> Las herramientas de Helm para rastrear el origen del chart, utilizadas para la firma, verificaci\u00f3n de integridad y origen del chart, son una parte opcional del proceso de publicaci\u00f3n del chart.<\/li>\n<li> 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\u00e1s inteligentes, aunque no forman parte de la especificaci\u00f3n formal.<\/li>\n<li> El uso de un \u00fanico archivo \u00edndice para buscar, almacenar metadatos y obtener charts ha dificultado el desarrollo de implementaciones multiusuario seguras.<\/li>\n<\/ul>\n<p>\nProyecto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (tambi\u00e9n conocido como Docker Registry v2) es el sucesor de Docker Registry y de hecho act\u00faa como un conjunto de herramientas para empaquetar, enviar, almacenar y entregar im\u00e1genes de Docker. Muchos grandes servicios en la nube ofrecen productos basados en Distribution. Debido a esta atenci\u00f3n aumentada, el proyecto Distribution se benefici\u00f3 de mejoras a lo largo de los a\u00f1os, mejores pr\u00e1cticas en seguridad y pruebas en condiciones de 'producci\u00f3n', convirti\u00e9ndose en uno de los h\u00e9roes no cantados m\u00e1s exitosos del mundo del Open Source.<\/p>\n<p>Pero, \u00bfsab\u00edas que el proyecto Distribution fue desarrollado para distribuir cualquier forma de contenido, no solo im\u00e1genes de contenedores?<\/p>\n<p>Gracias a los esfuerzos de <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (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\u00f3n y otras funciones necesarias para un Helm 3 a pleno rendimiento a\u00fan 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\u00f1os. Gracias a su mentor\u00eda y orientaci\u00f3n, estamos aprendiendo lo que significa operar un servicio de alta disponibilidad a gran escala.<\/p>\n<p>Una descripci\u00f3n m\u00e1s detallada de algunos de los pr\u00f3ximos cambios en los repositorios de charts de Helm est\u00e1 disponible. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">en el enlace<\/a><\/noindex>.<\/p>\n<h2>Gesti\u00f3n de lanzamientos<\/h2>\n<p>\nEn Helm 3, el estado de la aplicaci\u00f3n se rastrea dentro del cl\u00faster mediante un par de objetos:<\/p>\n<ul>\n<li> el objeto de lanzamiento \u2014 representa una instancia de la aplicaci\u00f3n;<\/li>\n<li> el secreto de la versi\u00f3n de lanzamiento \u2014 representa el estado deseado de la aplicaci\u00f3n en un momento espec\u00edfico (por ejemplo, el lanzamiento de una nueva versi\u00f3n).<\/li>\n<\/ul>\n<p>\nmountsnoop.py <code>helm install<\/code> crea el objeto de lanzamiento y el secreto de la versi\u00f3n de lanzamiento. Invocaci\u00f3n <code>helm upgrade<\/code> requiere un objeto de lanzamiento (que puede cambiar) y crea un nuevo secreto de versi\u00f3n de lanzamiento que contiene nuevos valores y un manifiesto preparado.<\/p>\n<p>El objeto de lanzamiento contiene informaci\u00f3n sobre el lanzamiento, donde el lanzamiento es una instalaci\u00f3n espec\u00edfica de un gr\u00e1fico nombrado y sus valores. 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\u00f3n y act\u00faa como propietario de todos los secretos de la versi\u00f3n de lanzamiento, as\u00ed como de todos los objetos que se crean directamente con el gr\u00e1fico de Helm.<\/p>\n<p>El secreto de la versi\u00f3n de lanzamiento vincula el lanzamiento con una serie de revisiones (instalaci\u00f3n, actualizaciones, retrocesos, eliminaci\u00f3n).<\/p>\n<p>En Helm 2, las revisiones eran exclusivamente secuenciales. La invocaci\u00f3n <code>helm install<\/code> se cre\u00f3 v1, la siguiente actualizaci\u00f3n (upgrade) fue v2, y as\u00ed sucesivamente. El lanzamiento y el secreto de la versi\u00f3n de lanzamiento se fusionaron en un solo objeto, conocido como revisi\u00f3n. Las revisiones se almacenaron en el mismo espacio de nombres que Tiller, lo que significaba que cada lanzamiento era \"global\" en t\u00e9rminos de espacio de nombres; como resultado, solo se pod\u00eda usar una instancia del nombre.<\/p>\n<p>En Helm 3, cada lanzamiento est\u00e1 asociado con uno o varios secretos de versi\u00f3n de lanzamiento. El objeto de lanzamiento siempre describe el lanzamiento actual desplegado en Kubernetes. Cada secreto de versi\u00f3n de lanzamiento describe solo una versi\u00f3n de ese lanzamiento. La actualizaci\u00f3n (upgrade), por ejemplo, crear\u00e1 un nuevo secreto de versi\u00f3n de lanzamiento y luego modificar\u00e1 el objeto de lanzamiento para que apunte a esta nueva versi\u00f3n. En caso de un retroceso (rollback), se pueden usar los secretos de versi\u00f3n de lanzamiento anteriores para restaurar el lanzamiento a su estado anterior.<\/p>\n<p>Despu\u00e9s de la eliminaci\u00f3n de Tiller, Helm 3 almacena los datos del lanzamiento en el mismo espacio de nombres del lanzamiento. Este cambio permite instalar un gr\u00e1fico con el mismo nombre de lanzamiento en otro espacio de nombres, y los datos se conservan entre actualizaciones\/reinicios del cl\u00faster en etcd. Por ejemplo, se puede instalar WordPress en el espacio de nombres \"foo\", y luego en el espacio de nombres \"bar\", y ambas versiones pueden llamarse \"wordpress\".<\/p>\n<h2>Cambios en las dependencias de gr\u00e1ficos<\/h2>\n<p>\nGr\u00e1ficos empaquetados (usando <code>helm package<\/code>) para usar con Helm 2, se puede instalar con Helm 3, sin embargo, el flujo de trabajo para desarrollar gr\u00e1ficos ha sido completamente revisado, por lo que se deben hacer algunos cambios para continuar desarrollando gr\u00e1ficos con Helm 3. En particular, ha cambiado el sistema de gesti\u00f3n de dependencias de los gr\u00e1ficos.<\/p>\n<p>El sistema de gesti\u00f3n de dependencias del gr\u00e1fico ha pasado de <code>requirements.yaml<\/code> y <code>requirements.lock<\/code> en <code>Chart.yaml<\/code> y <code>Chart.lock<\/code>. Esto significa que los gr\u00e1ficos que usaron el comando <code>helm dependency<\/code>, requieren cierta configuraci\u00f3n para funcionar en Helm 3.<\/p>\n<p>Veamos un ejemplo. Agreguemos una dependencia al gr\u00e1fico en Helm 2 y veamos qu\u00e9 cambiar\u00e1 al pasar a Helm 3.<\/p>\n<p>En Helm 2 <code>requirements.yaml<\/code> se ve\u00eda de la siguiente manera:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nEn Helm 3, la misma dependencia se reflejar\u00e1 en su <code>Chart.yaml<\/code>:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nLos gr\u00e1ficos a\u00fan se descargan y se colocan en el directorio <code>charts\/<\/code>, por lo que los subgr\u00e1ficos <i>(subcharts)<\/i>, que se encuentran en el directorio <code>charts\/<\/code>, seguir\u00e1n funcionando sin cambios.<\/p>\n<h2>Presentamos Library Charts<\/h2>\n<p>\nHelm 3 admite una clase de gr\u00e1ficos llamada gr\u00e1ficos de biblioteca <i>(library chart)<\/i>. Este gr\u00e1fico es utilizado por otros gr\u00e1ficos, pero no crea artefactos de lanzamiento por s\u00ed mismo. Las plantillas de gr\u00e1ficos de biblioteca pueden declarar solo elementos <code>define<\/code>. Otro contenido simplemente se ignora. Esto permite a los usuarios reutilizar y compartir fragmentos de c\u00f3digo que pueden ser utilizados en muchos gr\u00e1ficos, evitando as\u00ed la duplicaci\u00f3n y adhiri\u00e9ndose al principio de <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>Los gr\u00e1ficos de biblioteca se declaran en la secci\u00f3n <code>dependencies<\/code> en el archivo <code>Chart.yaml<\/code>. La instalaci\u00f3n y gesti\u00f3n de estos no difiere de otros gr\u00e1ficos.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nEsperamos con entusiasmo las posibles aplicaciones que este componente abrir\u00e1 para los desarrolladores de gr\u00e1ficos, as\u00ed como las mejores pr\u00e1cticas que pueden surgir debido a los gr\u00e1ficos de biblioteca.<\/p>\n<h2>\u00bfQu\u00e9 sigue?<\/h2>\n<p>\nHelm 3.0.0-alpha.1 es la base sobre la cual comenzamos a construir una nueva versi\u00f3n de Helm. En este art\u00edculo, describ\u00ed algunas caracter\u00edsticas interesantes de Helm 3. Muchas de ellas a\u00fan se encuentran en las primeras etapas de desarrollo y eso es normal; la esencia de la versi\u00f3n alfa es probar la idea, recopilar comentarios de los primeros usuarios y validar nuestras suposiciones.<\/p>\n<p>Una vez que se publique la versi\u00f3n alfa <i>(recordemos que esto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">ya ha ocurrido<\/a><\/noindex> \u2014 nota del traductor)<\/i>, comenzaremos a aceptar parches para Helm 3 de la comunidad. Es necesario crear una base s\u00f3lida que permita desarrollar y aceptar nuevas funcionalidades, y los usuarios podr\u00e1n sentirse involucrados en el proceso, abriendo tickets y haciendo correcciones.<\/p>\n<p>En este art\u00edculo, he intentado resaltar algunas mejoras importantes que llegar\u00e1n con Helm 3, sin embargo, esta lista no se puede considerar exhaustiva. El plan completo para Helm 3 incluye innovaciones como estrategias de actualizaci\u00f3n mejoradas, una integraci\u00f3n m\u00e1s profunda con los registros OCI y el uso de esquemas JSON para la validaci\u00f3n de valores de charts. Tambi\u00e9n planeamos limpiar la base de c\u00f3digo y actualizar aquellas partes que han estado descuidadas durante los \u00faltimos tres a\u00f1os.<\/p>\n<p>Si sientes que hemos pasado algo por alto, \u00a1nos encantar\u00eda escuchar tus comentarios!<\/p>\n<p>\u00danete a la discusi\u00f3n en nuestros <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">canales de Slack<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> para preguntas y comunicaci\u00f3n informal con la comunidad;<\/li>\n<li> <code>#helm-dev<\/code> para discutir pull requests, c\u00f3digo y errores.<\/li>\n<\/ul>\n<p>\nTambi\u00e9n puedes participar en nuestras llamadas semanales de desarrolladores p\u00fablicos 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\u00ed como los temas de discusi\u00f3n de la semana. Cualquiera puede unirse y participar en la reuni\u00f3n. El enlace est\u00e1 disponible en el canal de Slack <code>#helm-dev<\/code>.<\/p>\n<h2>P.D. del traductor<\/h2>\n<p>\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">El gestor de paquetes para Kubernetes \u2014 Helm: pasado, presente, futuro<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">Una mirada sobria a Helm 2: \"As\u00ed es como es...\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Introducci\u00f3n pr\u00e1ctica al gestor de paquetes para Kubernetes \u2014 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Consejos y trucos de Kubernetes: traducci\u00f3n de recursos en cl\u00faster bajo la gesti\u00f3n de Helm 2<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Pr\u00e1ctica con dapp. Parte 2. Despliegue de im\u00e1genes Docker en Kubernetes utilizando Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: 16 \u043c\u0430\u044f \u044d\u0442\u043e\u0433\u043e \u0433\u043e\u0434\u0430 \u2014 \u0437\u043d\u0430\u0447\u0438\u043c\u0430\u044f \u0432\u0435\u0445\u0430 \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0430 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0434\u043b\u044f Kubernetes \u2014 Helm. \u0412 \u044d\u0442\u043e\u0442 \u0434\u0435\u043d\u044c \u0431\u044b\u043b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0435\u0440\u0432\u044b\u0439 \u0430\u043b\u044c\u0444\u0430-\u0440\u0435\u043b\u0438\u0437 \u0431\u0443\u0434\u0443\u0449\u0435\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u2014 3.0. \u0415\u0451 \u0432\u044b\u0445\u043e\u0434 \u043f\u0440\u0438\u043d\u0435\u0441\u0451\u0442 \u0432 Helm \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0435 \u0438 \u0434\u043e\u043b\u0433\u043e\u0436\u0434\u0430\u043d\u043d\u044b\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0432 Kubernetes-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0435 \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u044e\u0442 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043d\u0430\u0434\u0435\u0436\u0434\u044b. \u041a \u0442\u0430\u043a\u043e\u0432\u044b\u043c \u043e\u0442\u043d\u043e\u0441\u0438\u043c\u0441\u044f \u0438 \u043c\u044b \u0441\u0430\u043c\u0438, \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0430\u043a\u0442\u0438\u0432\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Introducci\u00f3n a Helm 3 | ProHoster","description":"Ej.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/znakomstvo-s-helm-3","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:06+00:00","article:modified_time":"2019-10-31T19:00:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:26:53","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 23:08:04","updated":"2026-01-21 20:26:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}