La esencia de la historia sobre el administrador de paquetes más popular para Kubernetes podría representarse usando un emoji:
- el cuadro es Helm (que es lo más parecido a la última versión de Emoji);
- cerradura - seguridad;
- el hombrecito es la solución al problema.
De hecho, todo será un poco más complicado y la historia está llena de detalles técnicos sobre Cómo hacer que Helm sea seguro.
- Brevemente qué es Helm por si no lo sabías o lo olvidaste. Qué problemas resuelve y dónde se ubica en el ecosistema.
- Veamos la arquitectura de Helm. Ninguna conversación sobre seguridad y cómo hacer que una herramienta o solución sea más segura está completa sin comprender la arquitectura del componente.
- Analicemos los componentes de Helm.
- La pregunta más candente es el futuro: la nueva versión de Helm 3.
Todo lo contenido en este artículo se aplica a Helm 2. Esta versión está actualmente en producción y probablemente sea la que está utilizando actualmente, y es la versión que contiene los riesgos de seguridad.
Sobre el orador: Alexander Khayorov () se ha estado desarrollando durante 10 años, ayudando a mejorar el contenido. y se unió al comité . Ahora trabaja en Chainstack como líder de desarrollo; este es un híbrido entre un gerente de desarrollo y una persona responsable de entregar las versiones finales. Es decir, se ubica en el campo de batalla, donde sucede todo desde la creación de un producto hasta su funcionamiento.
Chainstack es una pequeña startup en crecimiento activo cuya misión es permitir a los clientes olvidarse de la infraestructura y las complejidades de operar aplicaciones descentralizadas; el equipo de desarrollo está ubicado en Singapur. No le pida a Chainstack que venda o compre criptomonedas, pero ofrézcase a hablar sobre los marcos de blockchain empresarial y ellos le responderán con gusto.
Casco
Este es un administrador de paquetes (gráficos) para Kubernetes. La forma más intuitiva y universal de llevar aplicaciones a un clúster de Kubernetes.
Por supuesto, estamos hablando de un enfoque más estructural e industrial que crear sus propios manifiestos YAML y escribir pequeñas utilidades.
Helm es el mejor disponible y popular actualmente.
¿Por qué timón? Principalmente porque cuenta con el apoyo de la CNCF. Cloud Native es una organización grande y es la empresa matriz de los proyectos Kubernetes, etcd, Fluentd y otros.
Otro dato importante es que Helm es un proyecto muy popular. Cuando comencé a hablar sobre cómo hacer que Helm fuera seguro en enero de 2019, el proyecto tenía mil estrellas en GitHub. En mayo eran 12 mil.
Muchas personas están interesadas en Helm, por lo que incluso si aún no lo usas, te beneficiará conocer su seguridad. La seguridad es importante.
El equipo central de Helm cuenta con el respaldo de Microsoft Azure y, por lo tanto, es un proyecto bastante estable, a diferencia de muchos otros. El lanzamiento de Helm 3 Alpha 2 a mediados de julio indica que hay bastante gente trabajando en el proyecto y que tienen el deseo y la energía para desarrollar y mejorar Helm.
Helm resuelve varios problemas fundamentales de la gestión de aplicaciones en Kubernetes.
- Empaquetamiento de aplicaciones. Incluso una aplicación como “Hola mundo” en WordPress ya consta de varios servicios y desea empaquetarlos juntos.
- Gestionar la complejidad que conlleva la gestión de estas aplicaciones.
- Un ciclo de vida que no finaliza después de instalar o implementar la aplicación. Continúa vivo, necesita ser actualizado y Helm ayuda con esto e intenta implementar las medidas y políticas adecuadas para esto.
Harpillera está organizado de forma clara: hay metadatos que coinciden plenamente con el trabajo de un administrador de paquetes normal para Linux, Windows o MacOS. Es decir, un repositorio, dependencias de varios paquetes, metainformación para aplicaciones, configuraciones, funciones de configuración, indexación de información, etc. Helm le permite obtener y utilizar todo esto para aplicaciones.
Gestión de la complejidad. Si tiene muchas aplicaciones del mismo tipo, entonces es necesaria la parametrización. Las plantillas provienen de esto, pero para evitar tener que idear su propia forma de crear plantillas, puede usar lo que Helm ofrece de fábrica.
Gestión del ciclo de vida de las aplicaciones - En mi opinión, ésta es la cuestión más interesante y sin resolver. Por eso vine a Helm en su día. Necesitábamos estar atentos al ciclo de vida de las aplicaciones y queríamos trasladar nuestro CI/CD y los ciclos de aplicaciones a este paradigma.
Helm le permite:
- gestionar implementaciones, introduce el concepto de configuración y revisión;
- realizar la reversión con éxito;
- utilizar ganchos para diferentes eventos;
- agregue verificaciones de aplicaciones adicionales y responda a sus resultados.
por otra parte El timón tiene “baterías” - una gran cantidad de cosas deliciosas que se pueden incluir en forma de complementos, simplificando su vida. Los complementos se pueden escribir de forma independiente, están bastante aislados y no requieren una arquitectura armoniosa. Si desea implementar algo, le recomiendo hacerlo como un complemento y luego posiblemente incluirlo en el nivel ascendente.
Helm se basa en tres conceptos principales:
- Repositorio de gráficos — descripción y conjunto de parametrizaciones posibles para su manifiesto.
- Config —es decir, los valores que se aplicarán (texto, valores numéricos, etc.).
- tortugitas recoge los dos componentes superiores y juntos se convierten en Release. Se pueden versionar las versiones, logrando así un ciclo de vida organizado: pequeño en el momento de la instalación y grande en el momento de la actualización, degradación o reversión.
Arquitectura del timón
El diagrama representa conceptualmente la arquitectura de alto nivel de Helm.
Permítanme recordarles que Helm es algo relacionado con Kubernetes. Por tanto, no podemos prescindir de un clúster de Kubernetes (rectángulo). El componente kube-apiserver reside en el maestro. Sin Helm tenemos Kubeconfig. Helm trae un pequeño binario, si se le puede llamar así, la utilidad Helm CLI, que se instala en una computadora, computadora portátil, mainframe, en cualquier cosa.
Pero esto no es suficiente. Helm tiene un componente de servidor llamado Tiller. Representa los intereses de Helm dentro del cluster, es una aplicación dentro del cluster de Kubernetes, como cualquier otra.
El siguiente componente de Chart Repo es un repositorio con gráficos. Existe un repositorio oficial y puede haber un repositorio privado de una empresa o proyecto.
Interacción
Veamos cómo interactúan los componentes de la arquitectura cuando queremos instalar una aplicación usando Helm.
- Nosotros hablamos
Helm install, acceda al repositorio (Chart Repo) y obtenga un gráfico de Helm.
- La utilidad Helm (Helm CLI) interactúa con Kubeconfig para determinar con qué clúster contactar.
- Habiendo recibido esta información, la utilidad se refiere a Tiller, que se encuentra en nuestro clúster, como una aplicación.
- Tiller llama a Kube-apiserver para realizar acciones en Kubernetes, crear algunos objetos (servicios, pods, réplicas, secretos, etc.).
A continuación, complicaremos el diagrama para ver el vector de ataque al que puede estar expuesta toda la arquitectura Helm en su conjunto. Y luego intentaremos protegerla.
Vector de ataque
El primer punto débil potencial es API privilegiada-usuario. Como parte del plan, se trata de un hacker que obtuvo acceso de administrador a la CLI de Helm.
Usuario de API sin privilegios También puede suponer un peligro si se encuentra en algún lugar cercano. Dicho usuario tendrá un contexto diferente; por ejemplo, se le puede fijar en un espacio de nombres de clúster en la configuración de Kubeconfig.
El vector de ataque más interesante puede ser un proceso que reside dentro de un clúster en algún lugar cerca de Tiller y puede acceder a él. Puede ser un servidor web o un microservicio que ve el entorno de red del clúster.
Una variante de ataque exótica, pero cada vez más popular, implica Chart Repo. Un gráfico creado por un autor sin escrúpulos puede contener recursos inseguros y usted lo completará tomándolo por fe. O puede reemplazar el gráfico que descarga del repositorio oficial y, por ejemplo, crear un recurso en forma de políticas y escalar su acceso.
Intentemos defendernos de los ataques de estos cuatro lados y descubrir dónde hay problemas en la arquitectura de Helm y dónde, quizás, no los haya.
Ampliemos el diagrama, agreguemos más elementos, pero mantengamos todos los componentes básicos.
Helm CLI se comunica con Chart Repo, interactúa con Kubeconfig y el trabajo se transfiere al clúster al componente Tiller.
Tiller está representado por dos objetos:
- Tiller-deploy svc, que expone un determinado servicio;
- Pod de implementación de Tiller (en el diagrama en una sola copia en una réplica), en el que se ejecuta toda la carga, que accede al clúster.
Se utilizan diferentes protocolos y esquemas para la interacción. Desde el punto de vista de la seguridad, lo que más nos interesa es:
- El mecanismo por el cual Helm CLI accede al repositorio de gráficos: qué protocolo, si existe autenticación y qué se puede hacer con él.
- El protocolo mediante el cual Helm CLI, utilizando kubectl, se comunica con Tiller. Este es un servidor RPC instalado dentro del clúster.
- El propio Tiller es accesible para los microservicios que residen en el clúster e interactúa con Kube-apiserver.
Analicemos todas estas áreas en orden.
RBAC
No tiene sentido hablar de seguridad para Helm o cualquier otro servicio dentro del clúster a menos que RBAC esté habilitado.
Parece que esta no es la última recomendación, pero estoy seguro de que muchas personas todavía no han habilitado RBAC ni siquiera en producción, porque hay mucho alboroto y es necesario configurar muchas cosas. Sin embargo, te animo a que hagas esto.
— abogado del sitio web de RBAC. Contiene una gran cantidad de materiales interesantes que le ayudarán a configurar RBAC, le mostrarán por qué es bueno y cómo vivir básicamente con él en producción.
Intentaré explicar cómo funcionan Tiller y RBAC. Tiller trabaja dentro del clúster bajo una determinada cuenta de servicio. Normalmente, si RBAC no está configurado, este será el superusuario. En la configuración básica, Tiller será administrador. Es por eso que a menudo se dice que Tiller es un túnel SSH hacia su clúster. De hecho, esto es cierto, por lo que puede utilizar una cuenta de servicio dedicada separada en lugar de la cuenta de servicio predeterminada en el diagrama anterior.
Cuando inicializa Helm y lo instala en el servidor por primera vez, puede configurar la cuenta de servicio usando --service-account. Esto le permitirá utilizar un usuario con el conjunto mínimo de derechos requerido. Es cierto que tendrás que crear una "guirnalda": Role y RoleBinding.
Lamentablemente, Helm no hará esto por usted. Usted o el administrador del clúster de Kubernetes deben preparar un conjunto de roles y enlaces de roles para la cuenta de servicio con anticipación para poder aprobar Helm.
Surge la pregunta: ¿cuál es la diferencia entre Role y ClusterRole? La diferencia es que ClusterRole funciona para todos los espacios de nombres, a diferencia de los Roles y RoleBindings normales, que sólo funcionan para un espacio de nombres especializado. Puede configurar políticas para todo el clúster y todos los espacios de nombres, o personalizarlas para cada espacio de nombres individualmente.
Vale la pena mencionar que RBAC resuelve otro gran problema. Mucha gente se queja de que Helm, lamentablemente, no es multiinquilino (no admite multiinquilino). Si varios equipos consumen un clúster y usan Helm, es básicamente imposible configurar políticas y limitar su acceso dentro de este clúster, porque hay una determinada cuenta de servicio bajo la cual se ejecuta Helm y crea todos los recursos en el clúster desde debajo de ella. , lo que a veces es muy inconveniente. Esto es cierto, como el propio archivo binario, como el proceso, Helm Tiller no tiene concepto de multitenencia.
Sin embargo, existe una excelente manera que le permite ejecutar Tiller varias veces en un clúster. No hay ningún problema con esto, Tiller se puede iniciar en todos los espacios de nombres. Por lo tanto, puede utilizar RBAC, Kubeconfig como contexto y limitar el acceso a un Helm especial.
Se verá así.
Por ejemplo, hay dos Kubeconfigs con contexto para diferentes equipos (dos espacios de nombres): X Team para el equipo de desarrollo y el clúster de administración. El clúster de administración tiene su propio Tiller amplio, que se encuentra en el espacio de nombres del sistema Kube, una cuenta de servicio correspondientemente avanzada. Y un espacio de nombres separado para el equipo de desarrollo, podrán implementar sus servicios en un espacio de nombres especial.
Este es un enfoque viable, Tiller no consume tanta energía como para afectar en gran medida su presupuesto. Esta es una de las soluciones rápidas.
Siéntase libre de configurar Tiller por separado y proporcionar a Kubeconfig contexto para el equipo, para un desarrollador específico o para el entorno: Dev, Staging, Production (es dudoso que todo esté en el mismo clúster, sin embargo, esto se puede hacer).
Continuando con nuestra historia, pasemos de RBAC y hablemos de ConfigMaps.
Mapas de configuración
Helm utiliza ConfigMaps como almacén de datos. Cuando hablábamos de arquitectura, no había ninguna base de datos en ninguna parte que almacenara información sobre lanzamientos, configuraciones, reversiones, etc. Para esto se utiliza ConfigMaps.
Se conoce el principal problema de ConfigMaps: en principio, no son seguros; es imposible almacenar datos confidenciales. Estamos hablando de todo lo que no debe ir más allá del servicio, por ejemplo, las contraseñas. La forma más nativa para Helm en este momento es pasar del uso de ConfigMaps a secretos.
Esto se hace de forma muy sencilla. Anule la configuración de Tiller y especifique que el almacenamiento será secreto. Luego, para cada implementación, no recibirá un ConfigMap, sino un secreto.
Se podría argumentar que los secretos en sí mismos son un concepto extraño y no muy seguro. Sin embargo, vale la pena entender que los propios desarrolladores de Kubernetes lo están haciendo. A partir de la versión 1.10, es decir. Desde hace bastante tiempo es posible, al menos en las nubes públicas, conectar el almacenamiento correcto para almacenar secretos. El equipo ahora está trabajando en formas de distribuir mejor el acceso a secretos, grupos individuales u otras entidades.
Es mejor transferir Storage Helm a secretos y, a su vez, estarán protegidos de forma centralizada.
Por supuesto que quedará límite de almacenamiento de datos de 1 MB. Helm aquí usa etcd como almacenamiento distribuido para ConfigMaps. Y allí consideraron que se trataba de un fragmento de datos adecuado para la replicación, etc. Hay una discusión interesante sobre esto en Reddit. Recomiendo encontrar esta lectura divertida para el fin de semana o leer el extracto. .
Repositorios de gráficos
Los gráficos son los más vulnerables socialmente y pueden convertirse en una fuente de "hombre en el medio", especialmente si se utiliza una solución de stock. En primer lugar, estamos hablando de repositorios que se exponen a través de HTTP.
Definitivamente necesitas exponer Helm Repo a través de HTTPS; esta es la mejor opción y es económica.
Tenga en cuenta la mecanismo de firma del gráfico. La tecnología es increíblemente simple. Esto es lo mismo que usas en GitHub, una máquina PGP normal con claves públicas y privadas. Configure y asegúrese, teniendo las claves necesarias y firmando todo, de que este es realmente su gráfico.
Además, El cliente Helm admite TLS (no en el sentido HTTP del lado del servidor, sino TLS mutuo). Puede utilizar las claves del servidor y del cliente para comunicarse. Para ser honesto, no uso ese mecanismo porque no me gustan los certificados mutuos. Básicamente, - la herramienta principal para configurar Helm Repo para Helm 2 - también admite autenticación básica. Puede utilizar la autenticación básica si es más conveniente y silencioso.
También hay un complemento , que le permite alojar Chart Repos en Google Cloud Storage. Esto es bastante conveniente, funciona muy bien y es bastante seguro, porque todos los mecanismos descritos son reciclados.
Si habilita HTTPS o TLS, usa mTLS y habilita la autenticación básica para reducir aún más los riesgos, obtendrá un canal de comunicación seguro con Helm CLI y Chart Repo.
API GRPC
El siguiente paso es muy importante: proteger Tiller, que está ubicado en el clúster y es, por un lado, un servidor, por otro lado, él mismo accede a otros componentes e intenta hacerse pasar por alguien.
Como ya dije, Tiller es un servicio que expone gRPC, el cliente Helm llega a él a través de gRPC. Por defecto, por supuesto, TLS está deshabilitado. Por qué se hizo esto es una cuestión discutible; me parece que simplifica la configuración al principio.
Para producción e incluso puesta en escena, recomiendo habilitar TLS en gRPC.
En mi opinión, a diferencia de mTLS para gráficos, esto es apropiado aquí y se hace de manera muy simple: generar una infraestructura PQI, crear un certificado, iniciar Tiller y transferir el certificado durante la inicialización. Después de esto, puede ejecutar todos los comandos de Helm, presentándose con el certificado generado y la clave privada.
De esta manera se protegerá de todas las solicitudes a Tiller desde fuera del clúster.
Entonces, aseguramos el canal de conexión a Tiller, ya discutimos RBAC y ajustamos los derechos del apiserver de Kubernetes, reduciendo el dominio con el que puede interactuar.
Yelmo protegido
Veamos el diagrama final. Es la misma arquitectura con las mismas flechas.
Todas las conexiones ahora se pueden dibujar de forma segura en verde:
- para Chart Repo utilizamos TLS o mTLS y autenticación básica;
- mTLS para Tiller, y se expone como un servicio gRPC con TLS, utilizamos certificados;
- el clúster utiliza una cuenta de servicio especial con Role y RoleBinding.
Hemos asegurado significativamente el clúster, pero alguien inteligente dijo:
"Sólo puede haber una solución absolutamente segura: un ordenador apagado, que se encuentra en una caja de hormigón y está custodiado por soldados".
Existen diferentes formas de manipular datos y encontrar nuevos vectores de ataque. Sin embargo, confío en que estas recomendaciones lograrán un estándar básico de seguridad en la industria.
Prima
Esta parte no está directamente relacionada con la seguridad, pero también será útil. Te mostraré algunas cosas interesantes que pocas personas conocen. Por ejemplo, cómo buscar gráficos, oficiales y no oficiales.
en el repositorio Ahora hay alrededor de 300 gráficos y dos corrientes: estable e incubadora. Cualquiera que contribuya sabe perfectamente lo difícil que es pasar de la incubadora al establo y lo fácil que es salir volando del establo. Sin embargo, esta no es la mejor herramienta para buscar gráficos para Prometheus y cualquier otra cosa que desee, por una sencilla razón: no es un portal donde pueda buscar paquetes cómodamente.
Pero hay un servicio. , lo que hace que sea mucho más conveniente buscar gráficos. Lo más importante es que hay muchos más repositorios externos y casi 800 accesos disponibles. Además, puede conectar su repositorio si por alguna razón no desea enviar sus gráficos a la versión estable.
Pruebe hub.helm.sh y desarrollémoslo juntos. Este servicio forma parte del proyecto Helm e incluso puedes contribuir a su interfaz de usuario si eres un desarrollador front-end y solo quieres mejorar la apariencia.
También me gustaría llamar su atención sobre Integración de API de Open Service Broker. Suena engorroso y poco claro, pero resuelve los problemas a los que nos enfrentamos todos. Déjame explicarte con un ejemplo sencillo.
Hay un clúster de Kubernetes en el que queremos ejecutar una aplicación clásica: WordPress. Generalmente, se necesita una base de datos para una funcionalidad completa. Hay muchas soluciones diferentes, por ejemplo, puede iniciar su propio servicio completo de estado. Esto no es muy conveniente, pero mucha gente lo hace.
Otros, como nosotros en Chainstack, utilizan bases de datos administradas como MySQL o PostgreSQL para sus servidores. Es por eso que nuestras bases de datos están ubicadas en algún lugar de la nube.
Pero surge un problema: necesitamos conectar nuestro servicio con una base de datos, crear un tipo de base de datos, transferir la credencial y administrarla de alguna manera. Todo esto normalmente lo hace manualmente el administrador o desarrollador del sistema. Y no hay problema cuando hay pocas aplicaciones. Cuando hay muchos, necesitas una cosechadora. Existe tal recolector: es Service Broker. Le permite utilizar un complemento especial para un clúster de nube pública y solicitar recursos al proveedor a través de Broker, como si fuera una API. Para hacer esto, puede utilizar herramientas nativas de Kubernetes.
Es muy sencillo. Puede consultar, por ejemplo, MySQL administrado en Azure con un nivel base (esto se puede configurar). Utilizando la API de Azure, la base de datos se creará y preparará para su uso. No es necesario que interfieras con esto, el complemento es responsable de ello. Por ejemplo, OSBA (complemento de Azure) devolverá la credencial al servicio y la pasará a Helm. Podrás usar WordPress con MySQL en la nube, no tratar con bases de datos administradas en absoluto y no preocuparte por los servicios con estado completo en su interior.
Podemos decir que Helm actúa como un pegamento que, por un lado, permite implementar servicios y, por otro, consumir los recursos de los proveedores de la nube.
Puede escribir su propio complemento y utilizar toda esta historia en sus instalaciones. Entonces simplemente tendrás tu propio plugin para el proveedor de Cloud corporativo. Recomiendo probar este enfoque, especialmente si tiene una escala grande y desea implementar rápidamente el desarrollo, la puesta en escena o toda la infraestructura para una función. Esto le facilitará la vida a sus operaciones o DevOps.
Otro hallazgo que ya mencioné es complemento helm-gcs, que le permite utilizar Google-buckets (almacenamiento de objetos) para almacenar gráficos de Helm.
Sólo necesitas cuatro comandos para empezar a usarlo:
- instalar el complemento;
- iniciarlo;
- establezca la ruta al depósito, que se encuentra en gcp;
- publicar gráficos de la forma estándar.
Lo bueno es que se utilizará el método gcp nativo para la autorización. Puedes usar una cuenta de servicio, una cuenta de desarrollador, lo que quieras. Es muy conveniente y su funcionamiento no cuesta nada. Si usted, como yo, promueve la filosofía sin operaciones, esto será muy conveniente, especialmente para equipos pequeños.
Alternativas
Helm no es la única solución de gestión de servicios. Hay muchas preguntas al respecto, por lo que probablemente la tercera versión apareció tan rápidamente. Por supuesto que hay alternativas.
Pueden ser soluciones especializadas, por ejemplo, Ksonnet o Metaparticle. Puedes utilizar tus herramientas clásicas de gestión de infraestructura (Ansible, Terraform, Chef, etc.) para los mismos fines de los que hablé.
Por fin hay una solución , cuya popularidad está creciendo.
Operador Framework es la principal alternativa de Helm a considerar.
Es más nativo de CNCF y Kubernetes, pero la barrera de entrada es mucho mayor, necesita programar más y describir menos manifiestos.
Hay varios complementos, como Draft, Scaffold. Hacen la vida mucho más fácil, por ejemplo, simplifican el ciclo de envío e inicio de Helm para que los desarrolladores implementen un entorno de prueba. Yo los llamaría empoderadores.
Aquí hay un gráfico visual de dónde está todo.
En el eje x está el nivel de su control personal sobre lo que está sucediendo, en el eje y está el nivel de nativo de Kubernetes. La versión 2 de Helm se sitúa en algún punto intermedio. En la versión 3, no enormemente, pero se ha mejorado tanto el control como el nivel de natividad. Las soluciones a nivel de Ksonnet siguen siendo inferiores incluso a Helm 2. Sin embargo, vale la pena mirarlas para saber qué más hay en este mundo. Por supuesto, su administrador de configuración estará bajo su control, pero no es en absoluto nativo de Kubernetes.
Operador Framework es absolutamente nativo de Kubernetes y le permite administrarlo de manera mucho más elegante y escrupulosa (pero recuerde el nivel de entrada). Más bien, esto es más adecuado para una aplicación especializada y la creación de gestión para ella, en lugar de un recolector masivo para empaquetar una gran cantidad de aplicaciones usando Helm.
Los extensores simplemente mejoran un poco el control, complementan el flujo de trabajo o toman atajos en los procesos de CI/CD.
El futuro de Helm
La buena noticia es que se acerca Helm 3. La versión alfa de Helm 3.0.0-alpha.2 ya se lanzó, puedes probarla. Es bastante estable, pero la funcionalidad aún es limitada.
¿Por qué necesitas Helm 3? En primer lugar, esta es una historia sobre desaparición de timón, como componente. Esto, como ya comprenderéis, es un gran paso adelante, porque desde el punto de vista de la seguridad de la arquitectura, todo está simplificado.
Cuando se creó Helm 2, que fue alrededor de la época de Kubernetes 1.8 o incluso antes, muchos de los conceptos eran inmaduros. Por ejemplo, el concepto CRD se está implementando activamente y Helm utilizar CRDpara almacenar estructuras. Será posible utilizar sólo el cliente y no mantener la parte del servidor. En consecuencia, utilice comandos nativos de Kubernetes para trabajar con estructuras y recursos. Este es un gran paso adelante.
Aparecerá soporte para repositorios OCI nativos (Iniciativa de Contenedores Abiertos). Se trata de una iniciativa enorme y Helm está interesado principalmente en publicar sus gráficos. Llega al punto de que, por ejemplo, Docker Hub admite muchos estándares OCI. No lo estoy adivinando, pero tal vez los proveedores de repositorios clásicos de Docker comiencen a brindarle la oportunidad de alojar sus gráficos de Helm.
La historia controvertida para mí es soporte lua, como motor de plantillas para escribir guiones. No soy un gran admirador de Lua, pero esta sería una característica completamente opcional. Revisé esto 3 veces; no será necesario usar Lua. Por lo tanto, aquellos que quieran poder usar Lua, aquellos a quienes les guste Go, únanse a nuestro gran campamento y usen go-tmpl para esto.
Finalmente, lo que definitivamente me estaba perdiendo era aparición de esquemas y validación de tipos de datos. No habrá más problemas con int o string, no será necesario encerrar el cero entre comillas dobles. Aparecerá un esquema JSONS que le permitirá describirlo explícitamente para los valores.
Será fuertemente reelaborado modelo impulsado por eventos. Ya ha sido descrito conceptualmente. Mire la rama Helm 3 y verá cuántos eventos, ganchos y otras cosas se han agregado, lo que simplificará enormemente y, por otro lado, agregará control sobre los procesos de implementación y las reacciones a ellos.
Helm 3 será más simple, más seguro y más divertido, no porque no nos guste Helm 2, sino porque Kubernetes se está volviendo más avanzado. En consecuencia, Helm puede utilizar los desarrollos de Kubernetes y crear excelentes administradores para Kubernetes.
Otra buena noticia es que Alexander Khayorov te lo dirá, Recordemos que en Moscú se celebrará la conferencia sobre la integración de los procesos de desarrollo, pruebas y operación. 30 de septiembre y 1 de octubre. Aún puedes hacerlo hasta el 20 de agosto. y cuéntanos tu experiencia con la solución tareas del enfoque DevOps.
Siga los puntos de control y las noticias de la conferencia en и .
Fuente: habr.com