🙅🏿 🍴 🎩 Présentation de Helm 3 🗜️ ♿️ 🎑

Remarque perev. : Le 16 mai de cette année est une étape importante dans le développement du gestionnaire de packages pour Kubernetes - Helm. Ce jour-là, la première version alpha de la future version majeure du projet a été introduite - 3.0. Sa libération apportera des changements importants et attendus à Helm, pour lesquels de nombreux membres de la communauté de Kubernetes ont de grands espoirs. Nous les traitons nous-mêmes, car nous utilisons activement Helm pour déployer des applications: nous l'avons intégré à notre outil de mise en œuvre de CI / CD werf et nous apportons de temps en temps une contribution possible au développement en amont. Cette traduction rassemble 7 notes du blog officiel de Helm, qui sont synchronisées avec la première version alpha de Helm 3 et racontent l'histoire du projet et les principales caractéristiques de Helm 3. Leur auteur est Matt "bacongobbler" Fisher, un employé de Microsoft et l'un des principaux responsables de Helm.

Le 15 octobre 2015, le projet est né, maintenant connu sous le nom de Helm. Un an seulement après sa fondation, la communauté Helm a rejoint Kubernetes, tout en travaillant activement sur Helm 2. En juin 2018, Helm a rejoint CNCF en tant que projet d'incubation. Avance rapide vers le présent - et maintenant la première version alpha du nouveau Helm 3 est en route (cette version a déjà eu lieu à la mi-mai - environ la traduction) .

Dans cet article, je vais vous expliquer comment tout a commencé, comment nous sommes arrivés au stade actuel, présenter quelques fonctionnalités uniques disponibles dans la première version alpha de Helm 3 et expliquer comment nous prévoyons de continuer à développer.

Résumé:

histoire de la création de Helm;
adieu à Tiller;
dépôts de cartes;
gestion des versions;
changements dans les dépendances des graphiques;
cartes de bibliothèque;
quelle est la prochaine étape?

Histoire de Helm

Naissance

Helm 1 a commencé comme un projet open source créé par Deis. Nous étions une petite startup absorbée par Microsoft au printemps 2017. Notre autre projet Open Source, également appelé Deis, avait un outil deisctl qui a été utilisé (entre autres) pour installer et faire fonctionner la plate-forme Deis dans le cluster Fleet . À l'époque, Fleet était l'une des premières plates-formes d'orchestration de conteneurs.

À la mi-2015, nous avons décidé de changer de cap et transféré Deis (à l'époque renommé Deis Workflow) de Fleet à Kubernetes. L'un des premiers à repenser l' deisctl installation deisctl . Nous l'avons utilisé pour installer et gérer Deis Workflow dans un cluster Fleet.

Helm 1 a été créé à l'image de gestionnaires de packages bien connus tels que Homebrew, apt et yum. Sa tâche principale était de simplifier des tâches telles que l'empaquetage et l'installation d'applications dans Kubernetes. Helm a été officiellement présenté en 2015 lors de la conférence KubeCon à San Francisco.

Notre première tentative avec Helm a fonctionné, mais il y avait de sérieuses restrictions. Il a pris un ensemble de manifestes Kubernetes, aromatisés avec des générateurs comme blocs frontaux * YAML, et a téléchargé les résultats sur Kubernetes.

* Remarque perev. : À partir de la première version de Helm, la syntaxe YAML a été choisie pour décrire les ressources Kubernetes, et les modèles Jinja et les scripts Python ont été pris en charge lors de l'écriture des configurations. Nous avons écrit plus à ce sujet et sur le dispositif de la première version de Helm dans le chapitre «Une brève histoire de Helm» de ce matériel .

Par exemple, pour remplacer un champ dans un fichier YAML, vous avez dû ajouter la construction suivante au manifeste:

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

C'est cool qu'il y ait des moteurs de modèles aujourd'hui, n'est-ce pas?

Pour de nombreuses raisons, ce premier programme d'installation de Kubernetes nécessitait une liste codée en dur de fichiers manifestes et n'exécutait qu'une petite séquence fixe d'événements. Il était si difficile à utiliser que l'équipe R&D de Deis Workflow a eu du mal à transférer son produit sur cette plate-forme - cependant, les germes de l'idée étaient déjà semés. Notre première tentative a été une excellente opportunité d'apprentissage: nous avons réalisé que nous étions vraiment passionnés par la création d'outils pragmatiques qui résolvent les problèmes quotidiens pour nos utilisateurs.

Sur la base de l'expérience des erreurs passées, nous avons commencé à développer Helm 2.

Heaume de création 2

Fin 2015, l'équipe Google nous a contactés. Ils ont travaillé sur un outil similaire pour Kubernetes. Le gestionnaire de déploiement pour Kubernetes était le port de l'outil existant utilisé pour la plate-forme Google Cloud. "Aurions-nous," ont-ils demandé, "passé quelques jours à discuter des similitudes et des différences?"

En janvier 2016, les équipes Helm et Deployment Manager se sont réunies à Seattle pour échanger des idées. Les négociations se sont terminées sur un plan ambitieux: combiner les deux projets pour créer Helm 2. Avec Deis et Google, les gars de SkippBox (qui font maintenant partie de Bitnami - environ Transl.) Ont rejoint l'équipe de développement et nous avons commencé à travailler sur Helm 2.

Nous voulions maintenir la facilité d'utilisation de Helm, mais ajoutons ce qui suit:

modèles de graphiques pour la personnalisation;
gestion intracluster pour les équipes;
Dépôt de cartes de première classe
format de package stable avec la possibilité de signer;
Engagement fort envers le versionnage sémantique et le maintien de la compatibilité descendante entre les versions.

Pour atteindre ces objectifs, un deuxième élément a été ajouté à l'écosystème Helm. Ce composant intracluster s'appelait Tiller et a été impliqué dans l'installation des cartes Helm et leur gestion.

Depuis la sortie de Helm 2 en 2016, Kubernetes a gagné un certain nombre d'innovations majeures. Le contrôle d'accès basé sur les rôles ( RBAC ) a été introduit , qui a finalement remplacé le contrôle d'accès basé sur les attributs (ABAC). De nouveaux types de ressources ont été introduits (les déploiements à cette époque restaient toujours en version bêta). Des définitions de ressources personnalisées (à l'origine appelées ressources tierces ou TPR) ont été inventées. Et surtout, un ensemble de meilleures pratiques est apparu.

Au milieu de tous ces changements, Helm a continué de servir fidèlement les utilisateurs de Kubernetes. Après trois ans et de nombreux nouveaux ajouts, il est devenu clair qu'il était temps d'apporter des modifications importantes à la base de code afin que Helm puisse continuer à répondre aux besoins croissants d'un écosystème en développement.

Adieu à Tiller

Pendant le développement de Helm 2, nous avons introduit Tiller dans le cadre de notre intégration avec le gestionnaire de déploiement de Google. Tiller a joué un rôle important pour les équipes travaillant au sein d'un cluster commun: il a permis à divers spécialistes exploitant l'infrastructure d'interagir avec le même ensemble de versions.

Le contrôle d'accès basé sur les rôles (RBAC) étant activé par défaut dans Kubernetes 1.6, il est devenu plus difficile de travailler avec Tiller en production. En raison du grand nombre de politiques de sécurité possibles, notre position a été de proposer des autorisations par défaut. Cela a permis aux débutants d'expérimenter avec Helm et Kubernetes sans avoir à plonger dans les paramètres de sécurité au préalable. Malheureusement, cette configuration permissive pouvait conférer à l'utilisateur un éventail trop large d'autorisations dont il n'avait pas besoin. Les ingénieurs DevOps et SRE ont dû apprendre des étapes opérationnelles supplémentaires en installant Tiller dans un cluster multi-locataire.

Après avoir appris comment les membres de la communauté utilisent Helm dans des situations spécifiques, nous avons réalisé que le système de gestion des versions de Tiller n'avait pas besoin de s'appuyer sur un composant intra-cluster pour maintenir l'état ou fonctionner comme un hub central avec des informations sur les versions. Au lieu de cela, nous pourrions simplement obtenir des informations du serveur API Kubernetes, générer un graphique côté client et enregistrer l'enregistrement d'installation dans Kubernetes.

La tâche principale de Tiller pourrait être effectuée sans Tiller, donc l'une de nos premières décisions concernant Helm 3 a été un rejet complet de Tiller.

Avec le départ de Tiller, le modèle de sécurité Helm a été radicalement simplifié. Helm 3 prend désormais en charge toutes les méthodes modernes de sécurité, d'identification et d'autorisation des Kubernetes d'aujourd'hui. Les autorisations de barre sont déterminées à l' aide du fichier kubeconfig . Les administrateurs de cluster peuvent restreindre les droits des utilisateurs avec n'importe quel niveau de granularité. Les versions sont toujours stockées dans le cluster, le reste de la fonctionnalité Helm est conservé.

Référentiels de graphiques

À un niveau élevé, le référentiel de graphiques est un endroit où vous pouvez stocker et partager des graphiques. Le client Helm emballe et envoie les graphiques au référentiel. Autrement dit, le référentiel de graphiques est un serveur HTTP primitif avec un fichier index.yaml et des graphiques compressés.

Bien qu'il existe certains avantages dans la mesure où l'API du référentiel de graphiques satisfait aux exigences les plus élémentaires du référentiel, elle présente également plusieurs inconvénients:

Les référentiels de graphiques sont peu compatibles avec la plupart des implémentations de sécurité requises dans un environnement de production. La possession d'une API standard pour l'authentification et l'autorisation est cruciale dans les scénarios de production.
Les outils de Helm pour suivre l'origine du graphique, utilisés pour signer, vérifier l'intégrité et l'origine du graphique, sont une partie facultative du processus de publication du graphique.
Dans les scénarios multi-utilisateurs, le même graphique peut être chargé par un autre utilisateur, doublant la quantité d'espace requis pour stocker le même contenu. Des référentiels plus intelligents ont été développés pour résoudre ce problème, mais ils ne font pas partie de la spécification formelle.
L'utilisation d'un seul fichier d'index pour rechercher, stocker des métadonnées et obtenir des graphiques a compliqué le développement d'implémentations multi-utilisateurs sécurisées.

Le projet Docker Distribution (également connu sous le nom de Docker Registry v2) est le successeur du Docker Registry et agit en fait comme un ensemble d'outils pour l'empaquetage, l'envoi, le stockage et la livraison d'images Docker. De nombreux grands services cloud proposent des produits basés sur la distribution. Grâce à une attention accrue, le projet Distribution a bénéficié de nombreuses années d'améliorations, de meilleures pratiques dans le domaine de la sécurité et de tests en conditions de «combat», qui en ont fait l'un des héros méconnus les plus réussis du monde Open Source.

Mais saviez-vous que le projet Distribution a été conçu pour distribuer n'importe quelle forme de contenu, pas seulement des images de conteneurs?

Grâce aux efforts de l' Open Container Initiative (ou OCI), les graphiques Helm peuvent être placés sur n'importe quelle instance de Distribution. Jusqu'à présent, ce processus est expérimental. Les travaux sur le support des connexions et autres fonctions nécessaires à un Helm 3 à part entière ne sont pas encore terminés, mais nous sommes très heureux d'apprendre des découvertes faites par les équipes OCI et Distribution au fil des ans. Et grâce à leur mentorat et à leur leadership, nous apprenons ce qu'est le fonctionnement d'un service hautement accessible à grande échelle.

Une description plus détaillée de certaines des modifications à venir des référentiels Helm-charts est disponible ici .

Gestion des versions

Dans Helm 3, l'état d'une application est surveillé au sein d'un cluster par deux objets:

objet de libération - représente une instance de l'application;
release version secret - représente l'état souhaité de l'application à un moment donné (par exemple, la sortie d'une nouvelle version).

L'appel à l' helm install crée un objet de version et une version secrète. L'appel de helm upgrade nécessite un objet de version (qu'il peut changer) et crée un nouveau secret de version de version contenant de nouvelles valeurs et un manifeste préparé.

L'objet release contient des informations de release, où release est une installation spécifique d'un graphique nommé et de valeurs. Cet objet décrit les métadonnées de niveau supérieur sur la version. L'objet Release est conservé tout au long du cycle de vie de l'application et agit en tant que propriétaire de tous les secrets de version Release, ainsi que de tous les objets créés directement par le graphique Helm.

La version secrète de la version associe une version à une série de révisions (installation, mises à jour, annulations, désinstallation).

Dans Helm 2, les révisions étaient extrêmement cohérentes. L'appel d' helm install créé la v1, la mise à niveau de mise à niveau suivante v2, etc. La version et la version secrète de la version ont été regroupées en un seul objet, appelé révision. Les révisions étaient stockées dans le même espace de noms que Tiller, ce qui signifiait que chaque version était «globale» en termes d'espace de noms; par conséquent, une seule instance du nom a pu être utilisée.

Dans Helm 3, chaque version est associée à un ou plusieurs secrets de version de version. L'objet Release décrit toujours la version actuelle déployée dans Kubernetes. Chaque version secrète de version ne décrit qu'une seule version de cette version. Une mise à niveau, par exemple, créera un nouveau secret de version de version, puis modifiera l'objet de version pour pointer vers cette nouvelle version. Dans le cas d'une restauration, vous pouvez utiliser les secrets de la version précédente pour restaurer la version à son état précédent.

Après avoir abandonné Tiller, Helm 3 stocke les données de version dans un seul espace de noms avec la version. Une telle modification vous permet d'installer un graphique avec le même nom de version dans un espace de noms différent, et les données sont enregistrées entre les mises à jour / redémarrages de cluster dans etcd. Par exemple, vous pouvez installer Wordpress dans l'espace de noms «foo» puis dans l'espace de noms «bar», et les deux versions peuvent être appelées «wordpress».

Modifications des dépendances de graphique

Les graphiques emballés (à l'aide du helm package ) pour une utilisation avec Helm 2 peuvent être installés avec Helm 3, mais le flux de travail de développement de graphiques a été complètement révisé, donc certaines modifications doivent être apportées pour continuer à développer des graphiques avec Helm 3. En particulier, le système de gestion a changé dépendances de graphique.

Le système de gestion des dépendances des graphiques est passé de requirements.yaml et requirements.lock à Chart.yaml et Chart.lock . Cela signifie que les graphiques qui utilisent la helm dependency nécessitent une configuration pour fonctionner dans Helm 3.

Regardons un exemple. Ajoutez une dépendance au graphique dans Helm 2 et voyez ce qui change lorsque vous passez à Helm 3.

Dans Helm 2 requirements.yaml ressemblait à ceci:

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

Dans Helm 3, la même dépendance se reflétera dans votre Chart.yaml :

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

Les charts/ sont toujours chargés et placés dans le répertoire charts/ , de sorte que les sous- charts/ dans le répertoire charts/ continueront de fonctionner sans modifications.

Présentation des graphiques de bibliothèque

Helm 3 prend en charge une classe de graphique appelée graphique de bibliothèque . Ce graphique est utilisé par d'autres graphiques, mais ne crée pas à lui seul d'artefacts de version. Les modèles de graphiques de bibliothèque ne peuvent déclarer que des éléments de define . Tout autre contenu est simplement ignoré. Cela permet aux utilisateurs de réutiliser et de partager des fragments de code qui peuvent être utilisés sur de nombreux graphiques, évitant ainsi la duplication et adhérant au principe DRY .

Les graphiques de bibliothèque sont déclarés dans la section des dependencies du fichier Chart.yaml . Leur installation et leur gestion ne sont pas différentes des autres cartes.

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

Nous attendons avec impatience les cas d'utilisation que ce composant ouvrira aux développeurs de graphiques, ainsi que les meilleures pratiques pouvant découler des graphiques de bibliothèque.

Et ensuite?

Helm 3.0.0-alpha.1 - la base sur laquelle nous commençons à créer une nouvelle version de Helm. Dans l'article, j'ai décrit quelques fonctionnalités intéressantes de Helm 3. Beaucoup d'entre elles en sont encore aux premiers stades de développement et c'est normal; L'essence de la version alpha est de tester l'idée, de recueillir les commentaires des premiers utilisateurs et de confirmer nos hypothèses.

Dès que la version alpha sera publiée (rappelez-vous que cela s'est déjà produit - environ la traduction) , nous commencerons à recevoir des correctifs pour Helm 3 de la communauté. Il est nécessaire de créer une base solide qui vous permettra de développer et d'adopter de nouvelles fonctionnalités, et les utilisateurs pourront se sentir impliqués dans le processus, ouvrir des tickets et apporter des corrections.

Dans l'article, j'ai essayé de mettre en évidence de sérieuses améliorations qui apparaîtront dans Helm 3, mais cette liste n'est en aucun cas exhaustive. Le plan à grande échelle pour Helm 3 comprend des innovations telles que des stratégies de mise à jour améliorées, une intégration plus approfondie avec les registres OCI et l'utilisation de schémas JSON pour vérifier les valeurs des graphiques. Nous prévoyons également d'effacer la base de code et de mettre à jour les parties de celui-ci qui ont été négligées au cours des trois dernières années.

Si vous sentez que nous avons manqué quelque chose, nous serons heureux d'entendre vos pensées!

Rejoignez la discussion sur nos canaux Slack :

#helm-users de #helm-users pour des questions et une communication facile avec la communauté;
#helm-dev pour discuter des pull pulls, du code et des bugs.

Vous pouvez également discuter dans nos appels hebdomadaires publics pour développeurs le jeudi à 19h30 MSK. Les réunions sont consacrées à la discussion des tâches sur lesquelles travaillent les développeurs clés et la communauté, ainsi qu'aux sujets de discussion de la semaine. Tout le monde peut se joindre et participer à la réunion. Le lien est disponible dans le canal Slack #helm-dev .

PS du traducteur

Lisez aussi dans notre blog:

Présentation de Helm 3