🥇Introducció a Helm 3

Nota. transl.: El 16 de maig d'aquest any marca una fita significativa en el desenvolupament del gestor de paquets per a Kubernetes - Helm. Aquest dia, es va presentar la primera versió alfa de la futura versió principal del projecte, la 3.0. El seu llançament aportarà canvis significatius i esperats a Helm, en els quals molts de la comunitat de Kubernetes tenen moltes esperances. Nosaltres som un d'aquests, ja que utilitzem activament Helm per al desplegament d'aplicacions: l'hem integrat a la nostra eina per implementar CI/CD. werf i de tant en tant fem la nostra contribució al desenvolupament de l'aigua amunt. Aquesta traducció combina 7 notes del blog oficial de Helm, que estan dedicades a la primera versió alfa de Helm 3 i parlen de la història del projecte i les principals característiques d'Helm 3. El seu autor és Matt “bacongobbler” Fisher, un empleat de Microsoft. i un dels principals mantenedors de Helm.

El 15 d'octubre de 2015 va néixer el projecte que ara es coneix com Helm. Tot just un any després de la seva fundació, la comunitat Helm es va unir a Kubernetes, mentre treballava activament en Helm 2. El juny de 2018, Helm es va incorporar al CNCF com a projecte en desenvolupament (incubació). Avanceu ràpidament fins al present, i la primera versió alfa del nou Helm 3 està en camí. (aquest llançament ja ha tingut lloc a mitjans de maig - aprox. trad.).

En aquest article, parlaré d'on va començar tot, de com hem arribat fins on som avui, presentaré algunes de les funcions úniques disponibles a la primera versió alfa d'Helm 3 i explicaré com pensem seguir desenvolupant-nos.

Resum:

la història de la creació de Helm;
un tendre comiat de Tiller;
dipòsits de gràfics;
gestió de llançaments;
canvis en les dependències dels gràfics;
gràfics de la biblioteca;
que segueix?

La història de Helm

Naixement

Helm 1 va començar com un projecte de codi obert creat per Deis. Érem una petita startup absorbit Microsoft a la primavera de 2017. El nostre altre projecte de codi obert, també anomenat Deis, tenia una eina deisctl, que es va utilitzar (entre altres coses) per instal·lar i operar la plataforma Deis Clúster de flotes. En aquell moment, Fleet va ser una de les primeres plataformes d'orquestració de contenidors.

A mitjans del 2015, vam decidir canviar de rumb i vam traslladar Deis (aleshores es va anomenar Deis Workflow) de Fleet a Kubernetes. Un dels primers a redissenyar va ser l'eina d'instal·lació. deisctl. L'hem utilitzat per instal·lar i gestionar Deis Workflow al clúster Fleet.

Helm 1 es va crear a imatge de gestors de paquets famosos com Homebrew, apt i yum. El seu objectiu principal era simplificar tasques com empaquetar i instal·lar aplicacions a Kubernetes. Helm es va presentar oficialment el 2015 a la conferència KubeCon a San Francisco.

El nostre primer intent amb Helm va funcionar, però no va estar exempt de serioses limitacions. Va agafar un conjunt de manifests de Kubernetes, aromatitzats amb generadors com a blocs introductoris de YAML (matèria frontal)* i va carregar els resultats a Kubernetes.

* Nota. transl.: Des de la primera versió d'Helm, es va triar la sintaxi YAML per descriure els recursos de Kubernetes, i les plantilles Jinja i els scripts de Python eren compatibles a l'hora d'escriure configuracions. Vam escriure més sobre això i l'estructura de la primera versió d'Helm en general al capítol "Una breu història d'Helm" aquest material.

Per exemple, per substituir un camp d'un fitxer YAML, heu d'afegir la construcció següent al manifest:

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

És fantàstic que existeixin motors de plantilles avui, no?

Per moltes raons, aquest primer instal·lador de Kubernetes requeria una llista codificada de fitxers de manifest i només executava una petita seqüència fixa d'esdeveniments. Va ser tan difícil d'utilitzar que l'equip d'R+D de Deis Workflow va tenir dificultats quan va intentar transferir el seu producte a aquesta plataforma; tanmateix, les llavors de la idea ja havien estat sembrades. El nostre primer intent va ser una gran oportunitat d'aprenentatge: ens vam adonar que ens apassiona realment la creació d'eines pragmàtiques que resolguin els problemes quotidians dels nostres usuaris.

A partir de l'experiència d'errors passats, vam començar a desenvolupar Helm 2.

Fer Helm 2

A finals del 2015, l'equip de Google es va posar en contacte amb nosaltres. Estaven treballant en una eina similar per a Kubernetes. Deployment Manager for Kubernetes era un port d'una eina existent que s'utilitzava per a Google Cloud Platform. "Ens agradaria", van preguntar, "passar uns dies discutint les similituds i les diferències?"

El gener de 2016, els equips de Helm i Deployment Manager es van reunir a Seattle per intercanviar idees. Les negociacions van acabar amb un pla ambiciós: combinar ambdós projectes per crear Helm 2. Juntament amb Deis i Google, els nois de SkippBox (ara forma part de Bitnami - traducció aprox.), i vam començar a treballar en Helm 2.

Volíem mantenir la facilitat d'ús de Helm, però afegim el següent:

plantilles de gràfics per a la personalització;
gestió intra-clúster per a equips;
dipòsit de gràfics de classe mundial;
format de paquet estable amb opció de signatura;
un fort compromís amb la versió semàntica i el manteniment de la compatibilitat enrere entre les versions.

Per aconseguir aquests objectius, s'ha afegit un segon element a l'ecosistema Helm. Aquest component intra-clúster s'anomenava Tiller i s'encarregava d'instal·lar els gràfics Helm i gestionar-los.

Des del llançament de Helm 2 el 2016, Kubernetes ha afegit diverses innovacions importants. S'ha afegit control d'accés basat en rols (RBAC), que finalment va substituir el control d'accés basat en atributs (ABAC). Es van introduir nous tipus de recursos (els desplegaments encara es trobaven en fase beta en aquell moment). Es van inventar les definicions de recursos personalitzades (originalment anomenades Recursos de tercers o TPR). I el més important, ha sorgit un conjunt de bones pràctiques.

Enmig de tots aquests canvis, Helm va continuar servint fidelment als usuaris de Kubernetes. Després de tres anys i moltes incorporacions noves, era clar que era hora de fer canvis significatius a la base de codi per garantir que Helm pogués continuar satisfent les creixents necessitats d'un ecosistema en evolució.

Un tendre comiat de Tiller

Durant el desenvolupament de Helm 2, vam presentar Tiller com a part de la nostra integració amb el Gestor de desplegament de Google. Tiller va tenir un paper important per als equips que treballaven dins d'un clúster comú: va permetre que diferents especialistes que operaven la infraestructura interactuessin amb el mateix conjunt de versions.

Com que el control d'accés basat en rols (RBAC) estava habilitat per defecte a Kubernetes 1.6, treballar amb Tiller en producció es va fer més difícil. A causa del gran nombre de polítiques de seguretat possibles, la nostra posició ha estat oferir una configuració permissiva per defecte. Això va permetre als novells experimentar amb Helm i Kubernetes sense haver de capbussar-se primer en la configuració de seguretat. Malauradament, aquesta configuració de permisos podria dotar l'usuari d'un ventall massa ampli de permisos que no necessitava. Els enginyers de DevOps i SRE van haver d'aprendre passos operatius addicionals en instal·lar Tiller en un clúster multi-inquilí.

Després d'aprendre com la comunitat utilitzava Helm en situacions específiques, ens vam adonar que el sistema de gestió de llançaments de Tiller no havia de dependre d'un component dins del clúster per mantenir l'estat o funcionar com a concentrador central per a la informació de llançament. En canvi, només podríem rebre informació del servidor de l'API de Kubernetes, generar un gràfic al costat del client i emmagatzemar un registre de la instal·lació a Kubernetes.

L'objectiu principal de Tiller es podria haver aconseguit sense Tiller, així que una de les nostres primeres decisions respecte a Helm 3 va ser abandonar completament Tiller.

Amb Tiller desaparegut, el model de seguretat d'Helm s'ha simplificat radicalment. Helm 3 ara admet tots els mètodes moderns de seguretat, identitat i autorització de Kubernetes actuals. Els permisos de Helm es determinen mitjançant fitxer kubeconfig. Els administradors de clúster poden restringir els drets dels usuaris a qualsevol nivell de granularitat. Les versions encara es guarden dins del clúster i la resta de la funcionalitat de Helm roman intacte.

Repositoris de gràfics

A un alt nivell, un dipòsit de gràfics és un lloc on es poden emmagatzemar i compartir gràfics. El client Helm empaqueta i envia els gràfics al repositori. En poques paraules, un dipòsit de gràfics és un servidor HTTP primitiu amb un fitxer index.yaml i alguns gràfics empaquetats.

Tot i que l'API Charts Repository té alguns avantatges que compleixen els requisits d'emmagatzematge més bàsics, també hi ha alguns desavantatges:

Els repositoris de gràfics no són compatibles amb la majoria de les implementacions de seguretat necessàries en un entorn de producció. Tenir una API estàndard per a l'autenticació i l'autorització és extremadament important en escenaris de producció.
Les eines de procedència dels gràfics de Helm, que s'utilitzen per signar, verificar la integritat i la procedència d'un gràfic, són una part opcional del procés de publicació de gràfics.
En escenaris multiusuari, un altre usuari pot carregar el mateix gràfic, duplicant l'espai necessari per emmagatzemar el mateix contingut. S'han desenvolupat repositoris més intel·ligents per resoldre aquest problema, però no formen part de l'especificació formal.
L'ús d'un sol fitxer d'índex per cercar, emmagatzemar metadades i recuperar gràfics ha dificultat el desenvolupament d'implementacions segures per a diversos usuaris.

Projecte Distribució Docker (també conegut com a Docker Registry v2) és el successor de Docker Registry i actua bàsicament com un conjunt d'eines per empaquetar, enviar, emmagatzemar i lliurar imatges de Docker. Molts grans serveis al núvol ofereixen productes basats en la distribució. Gràcies a aquesta atenció creixent, el projecte de distribució s'ha beneficiat d'anys de millores, bones pràctiques de seguretat i proves de camp que l'han convertit en un dels herois no reconeguts amb més èxit del món de codi obert.

Però sabíeu que el Projecte de distribució estava dissenyat per distribuir qualsevol forma de contingut, no només imatges de contenidors?

Gràcies als esforços Iniciativa de contenidors oberts (o OCI), els gràfics Helm es poden col·locar a qualsevol instància de distribució. De moment, aquest procés és experimental. El suport d'inici de sessió i altres funcions necessàries per a un Helm 3 complet són un treball en curs, però estem encantats d'aprendre dels descobriments que han fet els equips d'OCI i de distribució al llarg dels anys. I gràcies a la seva tutorització i orientació, aprenem com és operar un servei d'alta disponibilitat a escala.

Hi ha disponible una descripció més detallada d'alguns canvis propers als dipòsits de gràfics Helm по ссылке.

Gestió de llançaments

A Helm 3, un parell d'objectes fan un seguiment de l'estat de l'aplicació dins del clúster:

objecte de llançament: representa una instància d'aplicació;
secret de la versió de llançament: representa l'estat desitjat de l'aplicació en un moment concret (per exemple, el llançament d'una versió nova).

Desafiament helm install crea un objecte de llançament i un secret de versió de llançament. Anomenada helm upgrade requereix un objecte de llançament (que pot canviar) i crea un secret de versió nova que conté els nous valors i un manifest preparat.

L'objecte de llançament conté informació sobre el llançament, on el llançament és una instal·lació específica d'un gràfic i valors amb nom. Aquest objecte descriu les metadades de nivell superior sobre la versió. L'objecte de llançament persisteix al llarg del cicle de vida de l'aplicació i és el propietari de tots els secrets de la versió de llançament, així com de tots els objectes creats directament pel gràfic Helm.

El secret de la versió de llançament associa un llançament a una sèrie de revisions (instal·lació, actualitzacions, retrocessos, supressió).

A Helm 2, les revisions eren extremadament coherents. Anomenada helm install creat v1, l'actualització posterior (actualització) - v2, i així successivament. El secret de la versió de llançament i llançament s'ha reduït en un únic objecte conegut com a revisió. Les revisions es van emmagatzemar al mateix espai de noms que Tiller, la qual cosa significava que cada llançament era "global" en termes d'espai de noms; com a resultat, només es podria utilitzar una instància del nom.

A Helm 3, cada llançament s'associa amb un o més secrets de versió de llançament. L'objecte de llançament sempre descriu la versió actual desplegada a Kubernetes. Cada secret de versió de llançament descriu només una versió d'aquesta versió. Una actualització, per exemple, crearà un secret de versió de llançament nova i després canviarà l'objecte de llançament per apuntar a aquesta versió nova. En el cas d'una recuperació, podeu utilitzar els secrets de la versió de la versió anterior per retrocedir la versió a un estat anterior.

Després d'abandonar Tiller, Helm 3 emmagatzema les dades del llançament al mateix espai de noms que el llançament. Aquest canvi us permet instal·lar un gràfic amb el mateix nom de llançament en un espai de noms diferent i les dades es desen entre les actualitzacions/reinicis del clúster a etcd. Per exemple, podeu instal·lar WordPress a l'espai de noms "foo" i després a l'espai de noms "bar", i ambdues versions es poden anomenar "wordpress".

Canvis a les dependències dels gràfics

Gràfics empaquetats (usant helm package) per utilitzar-lo amb Helm 2 es pot instal·lar amb Helm 3, però el flux de treball de desenvolupament de gràfics s'ha revisat completament, de manera que s'han de fer alguns canvis per continuar el desenvolupament de gràfics amb Helm 3. En particular, el sistema de gestió de dependències de gràfics ha canviat.

S'ha mogut el sistema de gestió de dependències del gràfic requirements.yaml и requirements.lock en Chart.yaml и Chart.lock. Això vol dir que els gràfics que utilitzaven l'ordre helm dependency, requereix una mica de configuració per funcionar a Helm 3.

Vegem-ne un exemple. Afegim una dependència al gràfic a Helm 2 i veiem què canvia quan passem a Helm 3.

A Helm 2 requirements.yaml semblava així:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

A Helm 3, la mateixa dependència es reflectirà en el vostre Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Els gràfics encara es descarreguen i es col·loquen al directori charts/, així que subgràfics (subgràfics), al catàleg charts/, seguirà treballant sense canvis.

Presentació dels gràfics de la biblioteca

Helm 3 admet una classe de gràfics anomenada gràfics de biblioteca (diagrama de la biblioteca). Aquest gràfic és utilitzat per altres gràfics, però no crea cap artefacte de llançament per si sol. Les plantilles de gràfics de biblioteca només poden declarar elements define. La resta de contingut simplement s'ignora. Això permet als usuaris reutilitzar i compartir fragments de codi que es poden utilitzar en diversos gràfics, evitant així la duplicació i adherint-se al principi. SEC.

Els gràfics de la biblioteca es declaren a la secció dependencies a l'arxiu Chart.yaml. Instal·lar-los i gestionar-los no és diferent d'altres gràfics.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Estem entusiasmats amb els casos d'ús que obrirà aquest component per als desenvolupadors de gràfics, així com les millors pràctiques que poden sorgir dels gràfics de biblioteques.

Què serà el següent?

Helm 3.0.0-alpha.1 és la base sobre la qual comencem a construir una nova versió d'Helm. A l'article vaig descriure algunes característiques interessants de Helm 3. Moltes d'elles encara es troben en les primeres etapes de desenvolupament i això és normal; L'objectiu d'una versió alfa és provar la idea, recollir comentaris dels primers usuaris i confirmar les nostres suposicions.

Tan aviat com es publica la versió alfa (recordeu que això és ja ha passat -aprox. trad.), començarem a acceptar pedaços per a Helm 3 de la comunitat. Heu de crear una base sòlida que permeti desenvolupar i adoptar noves funcionalitats i que els usuaris se sentin implicats en el procés obrint entrades i fent correccions.

He intentat ressaltar algunes de les millores principals que arriben a Helm 3, però aquesta llista no és de cap manera exhaustiva. El full de ruta complet per a Helm 3 inclou funcions com ara estratègies d'actualització millorades, una integració més profunda amb els registres OCI i l'ús d'esquemes JSON per validar els valors dels gràfics. També tenim previst netejar la base de codi i actualitzar-ne parts que s'han deixat de banda durant els darrers tres anys.

Si creieu que ens hem perdut alguna cosa, ens encantaria escoltar els vostres pensaments!

Uneix-te a la discussió al nostre Canals Slack:

#helm-users per a preguntes i comunicació senzilla amb la comunitat;
#helm-dev per parlar de sol·licituds d'extracció, codi i errors.

També podeu xatejar a les nostres trucades públiques setmanals per a desenvolupadors els dijous a les 19:30 MSK. Les reunions es dediquen a debatre qüestions en què estan treballant els desenvolupadors clau i la comunitat, així com els temes de discussió de la setmana. Qualsevol persona pot participar i participar en la reunió. Enllaç disponible al canal Slack #helm-dev.

PS del traductor

Llegeix també al nostre blog:

Font: www.habr.com

Presentació de Helm 3