Nota. transl.: O 16 de maio deste ano marca un fito significativo no desenvolvemento do xestor de paquetes para Kubernetes - Helm. Neste día presentouse a primeira versión alfa da futura versión principal do proxecto - 3.0. O seu lanzamento traerá cambios significativos e moi esperados para Helm, nos que moitos da comunidade de Kubernetes teñen moitas esperanzas. Nós mesmos somos un destes, xa que utilizamos Helm activamente para a implantación de aplicacións: integrámolo na nosa ferramenta para implementar CI/CD e de cando en vez facemos a nosa contribución ao desenvolvemento de augas arriba. Esta tradución combina 7 notas do blog oficial de Helm, que están dedicadas á primeira versión alfa de Helm 3 e falan da historia do proxecto e das principais características de Helm 3. O seu autor é Matt “bacongobbler” Fisher, un empregado de Microsoft. e un dos principais mantedores de Helm.
O 15 de outubro de 2015 naceu o proxecto agora coñecido como Helm. Só un ano despois da súa fundación, a comunidade Helm uniuse a Kubernetes, mentres traballaba activamente en Helm 2. En xuño de 2018, Helm como un proxecto en desenvolvemento (incubación). Avance rápido ata o presente e a primeira versión alfa do novo Helm 3 está en camiño. (esta publicación a mediados de maio - aprox. transl.).
Neste artigo, falarei de onde comezou todo, de como chegamos ata onde estamos hoxe, presentarei algunhas das características únicas dispoñibles na primeira versión alfa de Helm 3 e explicarei como pensamos seguir desenvolvendo.
Resumo:
- a historia da creación de Helm;
- unha tenra despedida de Tiller;
- repositorios de gráficos;
- xestión de lanzamentos;
- cambios nas dependencias dos gráficos;
- gráficos da biblioteca;
- que segue?
A historia de Helm
Nacemento
Helm 1 comezou como un proxecto de código aberto creado por Deis. Eramos unha pequena startup Microsoft na primavera de 2017. O noso outro proxecto de código aberto, tamén chamado Deis, tiña unha ferramenta deisctl, que se utilizou (entre outras cousas) para instalar e operar a plataforma Deis en . Nese momento, Fleet foi unha das primeiras plataformas de orquestración de contedores.
A mediados de 2015, decidimos cambiar de rumbo e trasladamos Deis (naquel momento renomeado como Deis Workflow) de Fleet a Kubernetes. Un dos primeiros en ser redeseñado foi a ferramenta de instalación. deisctl. Usámolo para instalar e xestionar Deis Workflow no clúster Fleet.
Helm 1 foi creado a imaxe de xestores de paquetes famosos como Homebrew, apt e yum. O seu obxectivo principal era simplificar tarefas como empaquetar e instalar aplicacións en Kubernetes. Helm presentouse oficialmente en 2015 na conferencia KubeCon en San Francisco.
O noso primeiro intento con Helm funcionou, pero non estivo exento de serias limitacións. Tomou un conxunto de manifestos de Kubernetes, decorados con xeradores como bloques introdutorios de YAML (materia frontal)* e cargou os resultados en Kubernetes.
* Nota. transl.: Desde a primeira versión de Helm, escolleuse a sintaxe YAML para describir os recursos de Kubernetes, e os modelos Jinja e os scripts de Python foron compatibles ao escribir configuracións. Escribimos máis sobre isto e a estrutura da primeira versión de Helm en xeral no capítulo "Unha breve historia de Helm" .
Por exemplo, para substituír un campo nun ficheiro YAML, tivo que engadir a seguinte construción ao manifesto:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlÉ xenial que existan motores de modelos hoxe, non é?
Por moitas razóns, este primeiro instalador de Kubernetes requiría unha lista codificada de ficheiros de manifesto e só executaba unha pequena secuencia fixa de eventos. Foi tan difícil de usar que o equipo de I+D de Deis Workflow tivo dificultades cando tentaron transferir o seu produto a esta plataforma; con todo, as sementes da idea xa estaban sementadas. O noso primeiro intento foi unha gran oportunidade de aprendizaxe: decatámonos de que nos apaixonaba de verdade crear ferramentas pragmáticas que resolven os problemas cotiáns dos nosos usuarios.
Baseándonos na experiencia de erros pasados, comezamos a desenvolver Helm 2.
Facendo Helm 2
A finais de 2015, o equipo de Google púxose en contacto connosco. Estaban traballando nunha ferramenta similar para Kubernetes. O xestor de implementación para Kubernetes era un porto dunha ferramenta existente que se utilizou para Google Cloud Platform. "Gustaríanos", preguntaron, "pasar uns días discutindo as semellanzas e diferenzas?"
En xaneiro de 2016, os equipos Helm e Deployment Manager reuníronse en Seattle para intercambiar ideas. As negociacións remataron cun plan ambicioso: combinar ambos proxectos para crear Helm 2. Xunto a Deis e Google, os rapaces de (agora forma parte de Bitnami - trad. aprox.), e comezamos a traballar en Helm 2.
Queriamos manter a facilidade de uso de Helm, pero engadir o seguinte:
- modelos de gráficos para personalizar;
- xestión intra-clúster para equipos;
- repositorio de gráficos de clase mundial;
- formato de paquete estable con opción de sinatura;
- un forte compromiso coa versión semántica e o mantemento da compatibilidade cara atrás entre versións.
Para acadar estes obxectivos, engadiuse un segundo elemento ao ecosistema Helm. Este compoñente dentro do clúster chamábase Tiller e era o responsable de instalar e xestionar os gráficos Helm.
Desde o lanzamento de Helm 2 en 2016, Kubernetes engadiu varias innovacións importantes. Engadiuse o control de acceso baseado en funcións (), que finalmente substituíu o Control de Acceso Baseado en Atributos (ABAC). Introducíronse novos tipos de recursos (As implementacións aínda estaba en fase beta nese momento). Inventáronse as definicións de recursos personalizadas (orixinalmente chamadas Recursos de terceiros ou TPR). E o máis importante, xurdiu un conxunto de mellores prácticas.
Entre todos estes cambios, Helm continuou atendendo fielmente aos usuarios de Kubernetes. Despois de tres anos e moitas novas incorporacións, estaba claro que era hora de facer cambios significativos na base de código para garantir que Helm puidese seguir atendendo as necesidades crecentes dun ecosistema en evolución.
Unha tenra despedida de Tiller
Durante o desenvolvemento de Helm 2, presentamos Tiller como parte da nosa integración co xestor de implementación de Google. Tiller xogou un papel importante para os equipos que traballaban nun clúster común: permitiu que diferentes especialistas que operaban a infraestrutura interactuaran co mesmo conxunto de versións.
Dado que o control de acceso baseado en roles (RBAC) estaba habilitado por defecto en Kubernetes 1.6, traballar con Tiller na produción fíxose máis difícil. Debido ao gran número de políticas de seguranza posibles, a nosa posición foi ofrecer unha configuración permisiva por defecto. Isto permitiu aos novatos experimentar con Helm e Kubernetes sen ter que mergullarse antes na configuración de seguridade. Desafortunadamente, esta configuración de permisos podería dotar ao usuario dunha gama demasiado ampla de permisos que non necesitaba. Os enxeñeiros de DevOps e SRE tiveron que aprender pasos operativos adicionais ao instalar Tiller nun clúster de varios arrendatarios.
Despois de coñecer como a comunidade utilizaba Helm en situacións específicas, decatámonos de que o sistema de xestión de lanzamentos de Tiller non necesitaba confiar nun compoñente dentro do clúster para manter o estado ou funcionar como un centro central para a información de versións. No seu lugar, poderíamos simplemente recibir información do servidor da API de Kubernetes, xerar un gráfico no lado do cliente e almacenar un rexistro da instalación en Kubernetes.
O obxectivo principal de Tiller poderíase conseguir sen Tiller, polo que unha das nosas primeiras decisións con respecto a Helm 3 foi abandonar completamente a Tiller.
Con Tiller desaparecido, o modelo de seguridade de Helm simplificouse radicalmente. Helm 3 agora admite todos os métodos modernos de seguridade, identidade e autorización dos Kubernetes actuais. Os permisos de Helm determínanse mediante . Os administradores do clúster poden restrinxir os dereitos dos usuarios a calquera nivel de granularidade. As versións aínda se gardan dentro do clúster e o resto da funcionalidade de Helm permanece intacta.
Repositorios de gráficos
A un alto nivel, un repositorio de gráficos é un lugar onde se poden almacenar e compartir gráficos. O cliente Helm empaqueta e envía os gráficos ao repositorio. En pocas palabras, un repositorio de gráficos é un servidor HTTP primitivo cun ficheiro index.yaml e algúns gráficos empaquetados.
Aínda que a API Charts Repository ten algunhas vantaxes que cumpra os requisitos de almacenamento máis básicos, tamén hai algunhas desvantaxes:
- Os repositorios de gráficos non son compatibles coa maioría das implementacións de seguridade necesarias nun ambiente de produción. Ter unha API estándar para a autenticación e autorización é moi importante nos escenarios de produción.
- As ferramentas de procedencia dos gráficos de Helm, que se usan para asinar, verificar a integridade e a procedencia dun gráfico, son unha parte opcional do proceso de publicación do gráfico.
- En escenarios multiusuario, o mesmo gráfico pode ser cargado por outro usuario, duplicando a cantidade de espazo necesario para almacenar o mesmo contido. Desenvolvéronse repositorios máis intelixentes para resolver este problema, pero non forman parte da especificación formal.
- O uso dun único ficheiro de índice para buscar, almacenar metadatos e recuperar gráficos dificultou o desenvolvemento de implementacións seguras para varios usuarios.
Proxecto (tamén coñecido como Docker Registry v2) é o sucesor de Docker Registry e actúa esencialmente como un conxunto de ferramentas para empaquetar, enviar, almacenar e entregar imaxes de Docker. Moitos grandes servizos na nube ofrecen produtos baseados na distribución. Grazas a este aumento da atención, o proxecto de Distribución beneficiouse de anos de melloras, mellores prácticas de seguridade e probas de campo que o converteron nun dos heroes non coñecidos máis exitosos do mundo Open Source.
Pero sabías que o Proxecto de distribución foi deseñado para distribuír calquera forma de contido, non só imaxes de contedores?
Grazas aos esforzos (ou OCI), os gráficos Helm pódense colocar en calquera instancia de Distribución. Polo de agora, este proceso é experimental. A compatibilidade de inicio de sesión e outras funcións necesarias para un Helm 3 completo son un traballo en progreso, pero estamos encantados de aprender dos descubrimentos que fixeron os equipos de OCI e Distribución ao longo dos anos. E a través da súa tutoría e orientación, aprendemos como é operar un servizo de alta dispoñibilidade a escala.
Hai dispoñible unha descrición máis detallada dalgúns cambios que se realizarán nos repositorios de gráficos Helm .
Xestión de lanzamentos
En Helm 3, un par de obxectos rastrexa o estado da aplicación dentro do clúster:
- release object - representa unha instancia de aplicación;
- segredo da versión de lanzamento: representa o estado desexado da aplicación nun momento específico (por exemplo, o lanzamento dunha nova versión).
Chamar helm install crea un obxecto de lanzamento e un segredo de versión de lanzamento. Chamar helm upgrade require un obxecto de lanzamento (que pode cambiar) e crea un novo segredo de versión de lanzamento que contén os novos valores e un manifesto preparado.
O obxecto Release contén información sobre a versión, onde a versión é unha instalación específica dun gráfico e valores denominados. Este obxecto describe os metadatos de nivel superior sobre a versión. O obxecto de lanzamento persiste durante todo o ciclo de vida da aplicación e é o propietario de todos os segredos da versión de lanzamento, así como de todos os obxectos creados directamente polo gráfico Helm.
O segredo da versión de lanzamento asocia un lanzamento a unha serie de revisións (instalación, actualizacións, reversións, eliminación).
En Helm 2, as revisións foron moi consistentes. Chamar helm install creado v1, a actualización posterior (actualización) - v2, etc. O segredo de versións de lanzamento e versión colapsáronse nun único obxecto coñecido como revisión. As revisións almacenáronse no mesmo espazo de nomes que Tiller, o que significaba que cada versión era "global" en termos de espazo de nomes; como resultado, só se puido utilizar unha instancia do nome.
En Helm 3, cada versión está asociada a un ou máis segredos de versións. O obxecto de versión sempre describe a versión actual implantada en Kubernetes. Cada segredo da versión de lanzamento describe só unha versión desa versión. Unha actualización, por exemplo, creará un segredo de versión de nova versión e despois cambiará o obxecto de versión para que apunte a esa nova versión. No caso dunha reversión, podes usar os segredos da versión anterior para revertir a versión a un estado anterior.
Despois de abandonar Tiller, Helm 3 almacena os datos de versións no mesmo espazo de nomes que a versión. Este cambio permítelle instalar un gráfico co mesmo nome de versión nun espazo de nomes diferente e os datos gárdanse entre as actualizacións/reinicios do clúster en etcd. Por exemplo, pode instalar WordPress no espazo de nomes "foo" e despois no espazo de nomes "bar", e ambas as versións pódense chamar "wordpress".
Cambios nas dependencias dos gráficos
Gráficos empaquetados (usando helm package) para usar con Helm 2 pódese instalar con Helm 3, pero o fluxo de traballo de desenvolvemento de gráficos foi completamente revisado, polo que hai que facer algúns cambios para continuar o desenvolvemento de gráficos con Helm 3. En particular, o sistema de xestión de dependencias de gráficos cambiou.
O sistema de xestión de dependencias do gráfico pasou de requirements.yaml и requirements.lock en Chart.yaml и Chart.lock. Isto significa que os gráficos que usaron o comando helm dependency, require algunha configuración para funcionar en Helm 3.
Vexamos un exemplo. Engademos unha dependencia ao gráfico en Helm 2 e vexamos que cambia ao pasar a Helm 3.
En Helm 2 requirements.yaml parecía así:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
En Helm 3, a mesma dependencia reflectirase no teu Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Os gráficos aínda están descargados e colocados no directorio charts/, polo que os subgráficos (subgráficos), deitado no catálogo charts/, seguirá traballando sen cambios.
Presentación dos gráficos da biblioteca
Helm 3 admite unha clase de gráficos chamados gráficos de biblioteca (biblioteca). Este gráfico é usado por outros gráficos, pero non crea ningún artefacto de lanzamento por si só. Os modelos de gráficos da biblioteca só poden declarar elementos define. Outro contido simplemente ignorase. Isto permite aos usuarios reutilizar e compartir fragmentos de código que se poden usar en varios gráficos, evitando así a duplicación e unirse ao principio. .
Os gráficos da biblioteca están declarados na sección dependencies en arquivo Chart.yaml. Instalalos e xestionalos non é diferente doutros gráficos.
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioEstamos entusiasmados cos casos de uso que este compoñente abrirá para os desenvolvedores de gráficos, así como as mellores prácticas que poden xurdir dos gráficos de bibliotecas.
Cal é o próximo?
Helm 3.0.0-alpha.1 é a base sobre a que comezamos a construír unha nova versión de Helm. No artigo describín algunhas características interesantes de Helm 3. Moitas delas aínda están nas primeiras fases de desenvolvemento e isto é normal; O obxectivo dunha versión alfa é probar a idea, recoller comentarios dos primeiros usuarios e confirmar as nosas suposicións.
Tan pronto como se publique a versión alfa (lembra que isto é - aprox. transl.), comezaremos a aceptar parches para Helm 3 da comunidade. Debes crear unha base sólida que permita desenvolver e adoptar novas funcionalidades e que os usuarios se sintan implicados no proceso abrindo tickets e facendo correccións.
Tentei destacar algunhas das principais melloras que chegarán a Helm 3, pero esta lista non é exhaustiva. A folla de ruta completa para Helm 3 inclúe funcións como estratexias de actualización melloradas, unha integración máis profunda cos rexistros OCI e o uso de esquemas JSON para validar os valores dos gráficos. Tamén pensamos limpar a base de código e actualizar partes dela que foron descoidadas durante os últimos tres anos.
Se cres que perdemos algo, encantaríanos escoitar os teus pensamentos!
Únete á discusión sobre o noso :
-
#helm-userspara preguntas e comunicación sinxela coa comunidade; -
#helm-devpara discutir solicitudes de extracción, código e erros.
Tamén podes falar nas nosas chamadas públicas semanais para programadores os xoves ás 19:30 MSK. As reunións están dedicadas a discutir cuestións nos que están a traballar os desenvolvedores clave e a comunidade, así como os temas de debate da semana. Calquera persoa pode unirse e participar na reunión. Ligazón dispoñible na canle de Slack #helm-dev.
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com