🥇Introduction à Helm 3

Note de traduction.Le 16 mai de cette année — une date marquante dans le développement du gestionnaire de paquets 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 à Helm des changements significatifs et très attendus, sur lesquels beaucoup dans la communauté Kubernetes fondent de grands espoirs. Nous nous incluons parmi ceux-là, car nous utilisons activement Helm pour déployer des applications : nous l'avons intégré dans notre outil de mise en œuvre CI/CD. werf et au fil du temps, nous contribuons modestement à l'évolution du projet en amont. Cette traduction regroupe 7 notes du blog officiel de Helm, qui sont liées à la première version alpha de Helm 3 et racontent l'histoire du projet ainsi que les principales caractéristiques de Helm 3. Leur auteur est Matt « bacongobbler » Fisher, employé chez Microsoft et l'un des principaux mainteneurs de Helm.

Le 15 octobre 2015, le projet aujourd'hui connu sous le nom de Helm est né. À peine un an après sa création, la communauté Helm a rejoint Kubernetes, tout en travaillant activement sur Helm 2. En juin 2018, Helm est devenu un projet de la CNCF en tant que projet en incubation. Remontons le temps jusqu'à aujourd'hui — et voilà que la première version alpha du nouveau Helm 3 approche. (cette version a déjà eu lieu mi-mai — note de la traduction.).

Dans cet article, je vais raconter comment tout a commencé, comment nous en sommes arrivés à ce stade actuel, présenter quelques caractéristiques uniques disponibles dans la première version alpha de Helm 3, et expliquer comment nous prévoyons d'évoluer à l'avenir.

Résumé :

l'histoire de la création de Helm;
un doux adieu à Tiller;
les dépôts de charts;
la gestion des versions;
les changements dans les dépendances des charts;
les charts de bibliothèque;
que faire ensuite ?

L'histoire de la création de Helm

Naissance

Helm 1 a commencé comme un projet Open Source, créé par la société 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 était utilisé (entre autres) pour installer et exploiter la plateforme Deis dans un cluster Fleet.À l'époque, Fleet était l'une des premières plateformes d'orchestration de conteneurs.

Au milieu de 2015, nous avons décidé de changer de cap et de migrer Deis (à l'époque renommé Deis Workflow) de Fleet vers Kubernetes. L'un des premiers outils à être repensé était l'installateur. deisctlNous l'avons utilisé pour installer et gérer Deis Workflow dans un cluster Fleet.

Helm 1 a été créé à l'image de gestionnaires de paquets bien connus comme Homebrew, apt et yum. Sa principale tâche consistait à simplifier des tâches telles que le conditionnement 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 elle n'a pas été sans limitations sérieuses. Il prenait un ensemble de manifestes Kubernetes, enrichis par des générateurs, comme blocs YAML d'entrée. (front-matter)*, et téléchargeait les résultats dans Kubernetes.

* Note de traduction.: Depuis la première version de Helm, la syntaxe YAML a été choisie pour décrire les ressources Kubernetes, et lors de la rédaction des configurations, des modèles Jinja et des scripts Python étaient pris en charge. Nous avons écrit plus en détail à ce sujet et sur la conception de la première version de Helm dans le chapitre « Brève histoire de Helm » de ce matériau..

Par exemple, pour remplacer un champ dans un fichier YAML, il fallait ajouter la construction suivante au manifeste :

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

C'est génial qu'il existe aujourd'hui des générateurs de modèles, n'est-ce pas ?

Pour de nombreuses raisons, ce premier installateur Kubernetes nécessitait une liste de fichiers manifeste rigoureusement définie et exécutait seulement une petite séquence d'événements fixes. Son utilisation était si difficile que l'équipe R&D de Deis Workflow a eu du mal lorsqu'elle a tenté de porter 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 occasion d'apprentissage : nous avons réalisé que nous étions réellement passionnés par la création d'outils pragmatiques, résolvant les problèmes quotidiens de nos utilisateurs.

S'appuyant sur l'expérience des erreurs passées, nous avons commencé à développer Helm 2.

Création de Helm 2

À la fin de 2015, l'équipe de Google nous a contactés. Ils travaillaient sur un outil similaire pour Kubernetes. Le Deployment Manager pour Kubernetes était un port d'un outil existant utilisé pour Google Cloud Platform. « Ne voulons-nous pas, a-t-on demandé, passer quelques jours à discuter des similarités et des différences ? »

En janvier 2016, les équipes de Helm et de Deployment Manager se sont rencontrées à Seattle pour échanger des idées. Les négociations se sont terminées par un plan ambitieux : fusionner les deux projets pour créer Helm 2. Avec Deis et Google, des gars de SkippBox (qui fait maintenant partie de Bitnami - note du traducteur), et nous avons commencé à travailler sur Helm 2.

Nous voulions maintenir la simplicité d'utilisation de Helm, tout en ajoutant ce qui suit :

des modèles de charts pour la personnalisation ;
la gestion intra-cluster pour les équipes ;
un référentiel de charts de premier ordre ;
un format de packages stable avec une possibilité de signature ;
un engagement ferme envers le versionnage sémantique et le maintien de la compatibilité rétroactive entre les versions.

Pour atteindre ces objectifs, un deuxième élément a été ajouté à l'écosystème Helm. Ce composant intra-cluster a été appelé Tiller et était responsable de l'installation et de la gestion des charts Helm.

Depuis la sortie de Helm 2 en 2016, Kubernetes a connu plusieurs innovations majeures. Un accès basé sur les rôles (RBAC), qui a finalement remplacé le contrôle d'accès basé sur les attributs (ABAC). De nouveaux types de ressources ont été introduits (les Deployments étaient encore en version bêta à l'époque). Les définitions de ressources personnalisées ont été inventées (elles étaient initialement appelées Third Party Resources ou TPRs). Et surtout, un ensemble de meilleures pratiques est apparu.

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

Un adieu doux au Tiller

Lors du développement de Helm 2, nous avons présenté Tiller comme partie intégrante de notre intégration avec Deployment Manager de Google. Tiller jouait un rôle clé pour les équipes travaillant dans un cluster partagé : il permettait à divers spécialistes de l'infrastructure d'interagir avec un 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 complexe. En raison du grand nombre de politiques de sécurité possibles, notre position était de proposer par défaut une configuration permissive. Cela permettait aux nouveaux utilisateurs d'expérimenter avec Helm et Kubernetes sans avoir à plonger d'abord dans les configurations de sécurité. Malheureusement, cette configuration permissive pouvait accorder à l'utilisateur un éventail trop large de permissions dont il n'avait pas besoin. Les ingénieurs DevOps et SRE devaient apprendre des étapes opérationnelles supplémentaires pour installer Tiller dans un cluster multi-locataire.

En découvrant comment les membres de la communauté utilisent Helm dans des situations spécifiques, nous avons compris que le système de gestion des versions de Tiller ne devait pas dépendre d'un composant intra-cluster pour maintenir des états ou fonctionner comme un hub central d'informations sur les versions. Au lieu de cela, nous pourrions simplement obtenir des informations à partir de l'API Kubernetes, générer le chart côté client et conserver un enregistrement de l'installation dans Kubernetes.

La fonctionnalité principale de Tiller pouvait être réalisée sans Tiller, donc l'une de nos premières décisions concernant Helm 3 a été de se passer complètement de 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 de sécurité, d'identification et d'autorisation modernes de Kubernetes. Les permissions de Helm sont définies à l'aide du fichier kubeconfig. Les administrateurs de cluster peuvent restreindre les droits des utilisateurs avec un degré de détail variable. Les versions sont toujours conservées dans le cluster, et le reste de la fonctionnalité de Helm est préservé.

Dépôts de charts

À un niveau élevé, un dépôt de charts est un endroit où l'on peut stocker et partager des charts. Le client Helm empaquete et envoie des charts au dépôt. En termes simples, un dépôt de charts est un serveur HTTP primitif avec un fichier index.yaml et quelques charts empaquetés.

Bien qu'il y ait certains avantages à ce que l'API du dépôt de charts réponde aux exigences de base du stockage, elle présente aussi plusieurs inconvénients :

Les dépôts de charts sont mal compatibles avec la plupart des implémentations de sécurité nécessaires dans un environnement de production. La disponibilité 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 des charts, utilisés pour la signature, la vérification de l'intégrité et l'origine des charts, font partie intégrante du processus de publication d'un chart.
Dans des scénarios multi-utilisateurs, le même chart peut être chargé par un autre utilisateur, doublant ainsi l'espace nécessaire pour stocker le même contenu. Pour résoudre ce problème, des dépôts plus intelligents ont été développés, mais ils ne font pas partie de la spécification formelle.
L'utilisation d'un unique fichier d'index pour rechercher, stocker des métadonnées et obtenir des charts a compliqué le développement d'implémentations multi-utilisateurs sécurisées.

Projet Docker Distribution aussi connu sous le nom de Docker Registry v2, est le successeur de Docker Registry et constitue en réalité un ensemble d'outils pour empaqueter, envoyer, stocker et livrer des images Docker. De nombreux grands services cloud proposent des produits basés sur Distribution. Grâce à cette attention accrue, le projet Distribution a bénéficié de nombreuses améliorations au fil des ans, des meilleures pratiques en matière de sécurité et de tests en conditions réelles, en le transformant en l'un des héros méconnus les plus réussis du monde de l'Open Source.

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

Grâce aux efforts de Open Container Initiative ou OCI, les charts Helm peuvent être hébergés sur n'importe quelle instance de Distribution. Bien que ce processus soit encore expérimental. Le travail sur le support des connexions et d'autres fonctions nécessaires à un Helm 3 pleinement fonctionnel n'est pas encore terminé, mais nous sommes très enthousiastes à l'idée d'apprendre des découvertes faites par les équipes OCI et Distribution au fil des ans. Grâce à leur mentorat et à leurs conseils, nous découvrons ce qu'implique l'exploitation d'un service hautement disponible à grande échelle.

Une description plus détaillée de certains changements à venir dans les dépôts de charts Helm est disponible. via le lien.

Gestion des versions

Dans Helm 3, l'état de l'application est suivi à l'intérieur du cluster par une paire d'objets :

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

de system-nspawn helm install crée un objet release et un secret de version de release. L'appel helm upgrade nécessite un objet release (qu'il peut modifier) et crée un nouveau secret de version de release contenant de nouvelles valeurs et un manifeste préparé.

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

Le secret de version de release lie la release à une série de révisions (installation, mises à jour, retours en arrière, suppression).

Dans Helm 2, les révisions étaient exclusivement séquentielles. L'appel helm install créait v1, la mise à jour suivante (upgrade) — v2, et ainsi de suite. Release et secret de version de release étaient fusionnés en un seul objet, connu sous le nom de révision. Les révisions étaient stockées dans le même espace de noms que Tiller, ce qui signifiait que chaque release était « globale » en termes d'espace de noms ; par conséquent, un seul exemplaire d'un nom pouvait être utilisé.

Dans Helm 3, chaque release est liée à un ou plusieurs secrets de version de release. L'objet release décrit toujours la release actuelle déployée dans Kubernetes. Chaque secret de version de release décrit uniquement une version de cette release. Une mise à jour (upgrade), par exemple, créera un nouveau secret de version de release et modifiera ensuite l'objet release pour qu'il pointe vers cette nouvelle version. En cas de retour en arrière (rollback), vous pouvez utiliser les précédents secrets de version de release pour restaurer la release à son état précédent.

Après l'abandon de Tiller, Helm 3 conserve les données de la release dans le même espace de noms que la release. Ce changement permet d'installer un chart avec le même nom de release dans un autre espace de noms, et les données sont conservées entre les mises à jour/les 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 releases peuvent être appelées « wordpress ».

Changements dans les dépendances des charts

Charts, empaquetés (à l'aide de helm package) pour une utilisation avec Helm 2, il peut être installé avec Helm 3, cependant, le processus de développement des charts a été complètement révisé, donc certaines modifications doivent être apportées pour continuer le développement des charts avec Helm 3. En particulier, le système de gestion des dépendances des charts a changé.

Le système de gestion des dépendances des charts est passé de requirements.yaml et requirements.lock sur Chart.yaml et Chart.lock. Cela signifie que les charts ayant utilisé la commande helm dependency, nécessitent une certaine configuration pour fonctionner dans Helm 3.

Prenons un exemple. Ajoutons une dépendance à un chart dans Helm 2 et voyons ce qui change lors de la migration vers Helm 3.

Dans Helm 2 requirements.yaml il apparaissait comme suit :

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 charts continuent d'être téléchargés et placés dans le répertoire charts/, donc les sous-charts (subcharts), situés dans le répertoire charts/, continueront de fonctionner sans modifications.

Présentation des Library Charts

Helm 3 prend en charge une classe de charts appelée charts-libraries (library chart). Ce chart est utilisé par d'autres charts, mais ne génère aucun artefact de release par lui-même. Les modèles des library charts peuvent uniquement déclarer des éléments define. Tout autre contenu est simplement ignoré. Cela permet aux utilisateurs de réutiliser et d'échanger des morceaux de code qui peuvent être utilisés dans de nombreux charts, évitant ainsi la duplication et respectant le principe de DRY.

Les Library charts sont déclarés dans la section dépendances dans le fichier Chart.yaml. L'installation et la gestion de ceux-ci ne diffèrent pas des autres charts.

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

Nous attendons avec impatience les cas d'utilisation que ce composant ouvrira aux développeurs de charts, ainsi que les meilleures pratiques qui pourraient émerger grâce aux library charts.

Et après ?

Helm 3.0.0-alpha.1 est la base sur laquelle nous commençons à créer une nouvelle version de Helm. Dans cet article, j'ai décrit certaines fonctionnalités intéressantes de Helm 3. Beaucoup d'entre elles sont encore à un stade précoce de développement et c'est normal ; l'idée d'une version alpha est de tester l'idée, de recueillir des retours des premiers utilisateurs et de valider nos hypothèses.

Dès que la version alpha sera publiée (rappelons que cela est déjà arrivé — n.d.t.), nous commencerons à accepter les patches pour Helm 3 de la part de la communauté. Il est nécessaire de créer une base solide qui permettra de développer et d’accepter de nouvelles fonctionnalités, et les utilisateurs pourront s’impliquer dans le processus en ouvrant des tickets et en soumettant des corrections.

Dans cet article, j'ai essayé de mettre en lumière certaines améliorations majeures qui apparaîtront dans Helm 3, cependant, cette liste ne peut en aucun cas être considérée comme exhaustive. Le plan à grande échelle pour Helm 3 inclut des nouveautés telles que des stratégies de mise à jour améliorées, une intégration plus profonde avec les registres OCI et l'utilisation de schémas JSON pour valider les valeurs des charts. Nous prévoyons également de nettoyer la base de code et de mettre à jour les parties qui sont restées sans attention ces trois dernières années.

Si vous pensez que nous avons omis quelque chose, nous serions ravis d'entendre vos idées !

Rejoignez la discussion dans nos canaux Slack:

#helm-users pour poser des questions et simplement discuter avec la communauté;
#helm-dev pour discuter des pull requests, du code et des bugs.

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

P.S. de l'auteur

Lisez aussi dans notre blog :

Source : habr.com

Introduction à Helm 3.