Noter. trad.: Le 16 mai de cette année marque 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 - 3.0 - a été présentée. Sa sortie apportera des changements importants et tant attendus à Helm, pour lesquels de nombreux membres de la communauté Kubernetes fondent de grands espoirs. Nous en faisons nous-mêmes partie, puisque nous utilisons activement Helm pour le déploiement d'applications : nous l'avons intégré à notre outil d'implémentation de CI/CD et de temps en temps nous apportons notre contribution au développement de l'amont. Cette traduction combine 7 notes du blog officiel Helm, dédiées à la première version alpha de Helm 3 et parlant de l'histoire du projet et des principales fonctionnalités de Helm 3. Leur auteur est Matt « bacongobbler » Fisher, un employé de Microsoft et l'un des principaux responsables de la maintenance de Helm.
Le 15 octobre 2015, le projet désormais connu sous le nom de Helm est né. Un an seulement après sa création, la communauté Helm a rejoint Kubernetes, tout en travaillant activement sur Helm 2. En juin 2018, Helm en tant que projet en développement (en incubation). Avance rapide jusqu’au présent, et la première version alpha du nouveau Helm 3 est en route. (cette version à la mi-mai - env. trad.).
Dans cet article, je parlerai de l'endroit où tout a commencé, de la façon dont nous en sommes arrivés là où nous en sommes aujourd'hui, je présenterai certaines des fonctionnalités uniques disponibles dans la première version alpha de Helm 3 et j'expliquerai comment nous prévoyons d'aller de l'avant.
Résumé:
- l'histoire de la création de Helm ;
- un tendre adieu à Tiller;
- référentiels de graphiques ;
- gestion des versions;
- changements dans les dépendances graphiques ;
- graphiques de bibliothèque ;
- et ensuite?
L'histoire de Helm
Naissance
Helm 1 a commencé comme un projet Open Source créé par Deis. Nous étions une petite startup Microsoft au printemps 2017. Notre autre projet Open Source, également nommé Deis, disposait d'un outil deisctl, qui a servi (entre autres) à installer et exploiter la plateforme Deis en . À l’époque, Fleet était l’une des premières plateformes d’orchestration de conteneurs.
À la mi-2015, nous avons décidé de changer de cap et avons déplacé Deis (à l'époque rebaptisé Deis Workflow) de Fleet vers Kubernetes. L'un des premiers à être repensé a été l'outil d'installation. deisctl. Nous l'avons utilisé pour installer et gérer Deis Workflow dans le cluster Fleet.
Helm 1 a été créé à l'image de gestionnaires de paquets célèbres tels que Homebrew, apt et yum. Son objectif principal était de simplifier des tâches telles que le packaging et l'installation d'applications sur 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 elle n’a pas été sans sérieuses limites. Il a pris un ensemble de manifestes Kubernetes, agrémentés de générateurs comme blocs YAML d'introduction. (avant-propos)*, et chargé les résultats dans Kubernetes.
* Noter. trad.: Dès 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 la structure de la première version de Helm en général dans le chapitre « Une brève histoire de Helm ». .
Par exemple, pour remplacer un champ dans un fichier YAML, vous deviez ajouter la construction suivante au manifeste :
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlC'est formidable que les moteurs de modèles existent 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. Son utilisation était si difficile que l'équipe R&D de Deis Workflow a eu du mal à transférer son produit sur cette plateforme. Cependant, les graines de l'idée avaient déjà été semées. 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 de nos utilisateurs.
Sur la base de l'expérience des erreurs passées, nous avons commencé à développer Helm 2.
Faire le casque 2
Fin 2015, l'équipe Google nous a contactés. Ils travaillaient sur un outil similaire pour Kubernetes. Deployment Manager for Kubernetes était un portage d'un outil existant utilisé pour Google Cloud Platform. « Voudrions-nous, » ont-ils demandé, « passer 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 par un plan ambitieux : combiner les deux projets pour créer Helm 2. Avec Deis et Google, les gars de (fait maintenant partie de Bitnami - traduction approximative.), et nous avons commencé à travailler sur Helm 2.
Nous voulions conserver la facilité d'utilisation de Helm, mais ajoutons ce qui suit :
- modèles de graphiques pour la personnalisation ;
- gestion intra-cluster des équipes ;
- référentiel de cartes de classe mondiale ;
- format de package stable avec option de signature ;
- un engagement fort en faveur du versionnage sémantique et du maintien de la compatibilité ascendante entre les versions.
Pour atteindre ces objectifs, un deuxième élément a été ajouté à l'écosystème Helm. Ce composant intra-cluster s'appelait Tiller et était chargé d'installer les chartes Helm et de les gérer.
Depuis la sortie de Helm 2 en 2016, Kubernetes a ajouté plusieurs innovations majeures. Ajout du contrôle d'accès basé sur les rôles (), 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 étaient encore en version bêta à l'époque). Des définitions de ressources personnalisées (appelées à l'origine ressources tierces ou TPR) ont été inventées. Et surtout, un ensemble de bonnes pratiques a émergé.
Au milieu de tous ces changements, Helm a continué à servir fidèlement les utilisateurs de Kubernetes. Après trois ans et de nombreux nouveaux ajouts, il était clair qu'il était temps d'apporter des modifications significatives à la base de code pour garantir que Helm puisse continuer à répondre aux besoins croissants d'un écosystème en évolution.
Un tendre adieu à Tiller
Lors du 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 à différents spécialistes exploitant l'infrastructure d'interagir avec le même ensemble de versions.
Depuis que le contrôle d'accès basé sur les rôles (RBAC) a été activé par défaut dans Kubernetes 1.6, travailler avec Tiller en production est devenu plus difficile. En raison du grand nombre de politiques de sécurité possibles, notre position a été de proposer une configuration permissive par défaut. Cela a permis aux débutants d’expérimenter Helm et Kubernetes sans avoir à se plonger au préalable dans les paramètres de sécurité. Malheureusement, cette configuration des autorisations pourrait donner à 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 lors de l'installation de Tiller dans un cluster multi-tenant.
Après avoir appris comment la communauté utilisait 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 une plaque tournante centrale pour les informations sur les versions. Au lieu de cela, nous pourrions simplement recevoir des informations du serveur API Kubernetes, générer un graphique côté client et stocker un enregistrement de l'installation dans Kubernetes.
L'objectif principal de Tiller aurait pu être atteint sans Tiller, c'est pourquoi l'une de nos premières décisions concernant Helm 3 a été d'abandonner complètement Tiller.
Avec le départ de Tiller, le modèle de sécurité de Helm a été radicalement simplifié. Helm 3 prend désormais en charge toutes les méthodes modernes de sécurité, d'identité et d'autorisation de Kubernetes actuel. Les autorisations Helm sont déterminées à l'aide . Les administrateurs de cluster peuvent restreindre les droits des utilisateurs à n'importe quel niveau de granularité. Les versions sont toujours enregistrées dans le cluster et le reste des fonctionnalités de Helm reste intact.
Référentiels de graphiques
À un niveau élevé, un référentiel de graphiques est un endroit où les graphiques peuvent être stockés et partagés. Le client Helm regroupe et envoie les graphiques au référentiel. En termes simples, un référentiel de graphiques est un serveur HTTP primitif avec un fichier index.yaml et des graphiques packagés.
Bien que l'API Charts Repository présente certains avantages en répondant à la plupart des exigences de stockage de base, elle présente également quelques inconvénients :
- Les référentiels de graphiques ne sont pas compatibles avec la plupart des implémentations de sécurité requises dans un environnement de production. Disposer d'une API standard pour l'authentification et l'autorisation est extrêmement important dans les scénarios de production.
- Les outils de provenance des cartes de Helm, utilisés pour signer et vérifier l'intégrité et la provenance d'une carte, sont une partie facultative du processus de publication des cartes.
- Dans les scénarios multi-utilisateurs, le même graphique peut être téléchargé par un autre utilisateur, doublant ainsi 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 récupérer des graphiques a rendu difficile le développement d’implémentations multi-utilisateurs sécurisées.
Projet (également connu sous le nom de Docker Registry v2) est le successeur de Docker Registry et agit essentiellement comme un ensemble d'outils pour emballer, expédier, stocker et livrer des images Docker. De nombreux grands services cloud proposent des produits basés sur la distribution. Grâce à cette attention accrue, le projet Distribution a bénéficié d'années d'améliorations, de meilleures pratiques de sécurité et de tests sur le terrain 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 de distribution a été conçu pour distribuer toute forme de contenu, pas seulement des images de conteneurs ?
Grâce aux efforts (ou OCI), les graphiques Helm peuvent être placés sur n'importe quelle instance de distribution. Pour l'instant, ce processus est expérimental. La prise en charge de la connexion et les autres fonctionnalités nécessaires à un Helm 3 complet sont en cours de développement, mais nous sommes ravis d'apprendre des découvertes faites par les équipes OCI et de distribution au fil des ans. Et grâce à leur mentorat et à leurs conseils, nous apprenons ce que signifie exploiter un service hautement disponible à grande échelle.
Une description plus détaillée de certaines modifications à venir dans les référentiels de cartes Helm est disponible .
Gestion des versions
Dans Helm 3, l'état de l'application est suivi au sein du cluster par une paire d'objets :
- objet release - représente une instance d'application ;
- secret de la version de publication - représente l'état souhaité de l'application à un moment précis (par exemple, la sortie d'une nouvelle version).
Défi helm install crée un objet de version et un secret de version de version. Appel helm upgrade nécessite un objet de version (qu'il peut modifier) et crée un nouveau secret de version contenant les nouvelles valeurs et un manifeste préparé.
L'objet Release contient des informations sur la version, où release est une installation spécifique d'un graphique et de valeurs nommés. Cet objet décrit les métadonnées de niveau supérieur concernant la version. L'objet de version persiste tout au long du cycle de vie de l'application et est propriétaire de tous les secrets de version de version, ainsi que de tous les objets directement créés par la charte Helm.
Le secret de version de version associe une version à une série de révisions (installation, mises à jour, restaurations, suppression).
Dans Helm 2, les révisions étaient extrêmement cohérentes. Appel helm install créé v1, la mise à jour ultérieure (mise à niveau) - v2, et ainsi de suite. La version et le secret de la version ont été regroupés 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 pouvait être utilisée.
Dans Helm 3, chaque version est associée à un ou plusieurs secrets de version. L'objet release décrit toujours la version actuelle déployée sur Kubernetes. Chaque secret de version de version décrit une seule version de cette version. Une mise à niveau, par exemple, créera un nouveau secret de version, puis modifiera l'objet de version pour qu'il pointe vers cette nouvelle version. En cas de restauration, vous pouvez utiliser les secrets de la version précédente pour restaurer la version à un état antérieur.
Une fois Tiller abandonné, Helm 3 stocke les données de version dans le même espace de noms que la version. Cette 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 du 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 nommées « wordpress ».
Modifications apportées aux dépendances des graphiques
Graphiques compressés (en utilisant helm package) à utiliser avec Helm 2 peut être installé avec Helm 3, mais le flux de travail de développement des graphiques a été complètement remanié, certaines modifications doivent donc être apportées pour continuer le développement des graphiques avec Helm 3. En particulier, le système de gestion des dépendances des graphiques a changé.
Le système de gestion des dépendances du graphique est passé de requirements.yaml и requirements.lock sur Chart.yaml и Chart.lock. Cela signifie que les graphiques qui ont utilisé la commande helm dependency, nécessite une configuration pour fonctionner dans Helm 3.
Regardons un exemple. Ajoutons une dépendance au graphique dans Helm 2 et voyons ce qui change lors du passage à Helm 3.
Dans Helm 2 requirements.yaml ça ressemblait à ça :
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Dans Helm 3, la même dépendance sera reflétée dans votre Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database
Les graphiques sont toujours téléchargés et placés dans le répertoire charts/, donc des sous-graphiques (sous-graphiques), couché dans le catalogue charts/, continuera à fonctionner sans changements.
Présentation des graphiques de bibliothèque
Helm 3 prend en charge une classe de graphiques appelés graphiques de bibliothèque (graphique de la bibliothèque). Ce graphique est utilisé par d'autres graphiques, mais ne crée pas d'artefacts de version à lui seul. Les modèles de graphiques de bibliothèque ne peuvent déclarer que des éléments define. Les autres contenus sont tout simplement ignorés. Cela permet aux utilisateurs de réutiliser et de partager des extraits de code pouvant être utilisés dans plusieurs graphiques, évitant ainsi la duplication et adhérant au principe .
Les cartes de bibliothèque sont déclarées dans la section dependencies dans le fichier Chart.yaml. Leur installation et leur gestion ne sont pas différentes des autres cartes.
dependencies:
- name: mylib
version: 1.x.x
repository: quay.ioNous sommes enthousiasmés par les cas d'utilisation que ce composant ouvrira aux développeurs de graphiques, ainsi que par les meilleures pratiques qui peuvent émerger des graphiques de bibliothèque.
Quelle est la prochaine?
Helm 3.0.0-alpha.1 est la base sur laquelle nous commençons à construire 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 ; Le but d'une version alpha est de tester l'idée, de recueillir les commentaires des premiers utilisateurs et de confirmer nos hypothèses.
Dès la sortie de la version alpha (rappelez-vous que c'est - environ. trad.), nous commencerons à accepter les correctifs pour Helm 3 de la part de la communauté. Vous devez créer une base solide qui permette le développement et l'adoption de nouvelles fonctionnalités, et pour que les utilisateurs se sentent impliqués dans le processus en ouvrant des tickets et en apportant des correctifs.
J'ai essayé de mettre en évidence certaines des améliorations majeures apportées à Helm 3, mais cette liste n'est en aucun cas exhaustive. La feuille de route complète de Helm 3 inclut des fonctionnalités 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 valider les valeurs des graphiques. Nous prévoyons également de nettoyer la base de code et de mettre à jour les parties qui ont été négligées au cours des trois dernières années.
Si vous pensez que nous avons raté quelque chose, nous serions ravis de connaître votre avis !
Rejoignez la discussion sur notre :
-
#helm-userspour des questions et une communication simple avec la communauté ; -
#helm-devpour discuter des demandes d'extraction, du code et des bugs.
Vous pouvez également discuter lors de nos appels publics hebdomadaires aux développeurs le jeudi à 19h30 MSK. Les réunions sont consacrées à discuter des problèmes sur lesquels les principaux développeurs et la communauté travaillent, ainsi que des sujets de discussion de la semaine. Tout le monde peut rejoindre et participer à la réunion. Lien disponible dans la chaîne Slack #helm-dev.
PS du traducteur
A lire aussi sur notre blog :
- «";
- «";
- «";
- «";
- «».
Source: habr.com