Remarque perev. : L'intérêt accru pour le «gestionnaire de paquets Kubernetes» - Helm, qui a été observé récemment, est facile à expliquer. La mise à jour majeure tant attendue de Helm v3, dont nous avons déjà parlé, est au stade actif - et pas seulement de développement, mais aussi de versions. Sa dernière version bêta, la troisième d'affilée , est sortie début septembre. Et tout récemment, un événement assez important (pour un projet Open Source aussi spécialisé) a eu lieu, les impressions à partir desquelles partagent ses visiteurs de CloudARK, qui propose iPaaS (plateforme d'intégration en tant que service) pour Kubernetes.
Photo originale prise depuis le compte Flickr du CNCFLe sommet Helm s'est tenu à Amsterdam la semaine dernière. Il a réuni environ 150 passionnés représentant divers utilisateurs et fournisseurs de services sur Kubernetes. Voici cinq points clés de cet événement.
1. Dans Helm 3.0 - meilleure sécurité, prise en charge de CRD et quelques changements qui cassent l'approche habituelle
Certains des principaux membres de l'équipe de développement centrale de Helm ont assisté au sommet. À partir de leurs discours et communications en marge, il est devenu clair que Helm 3.0 sera une étape importante pour le projet. Beaucoup d'entre vous ont probablement entendu dire que la troisième version n'aura pas Tiller - le composant serveur Helm.
( Remarque : Vous trouverez plus d'informations à ce sujet dans cet article .) Il y aura d'autres innovations importantes dans Helm 3.0, telles que des contrôles de sécurité plus étroits et une meilleure prise en charge des définitions de ressources personnalisées (CRD). Voici trois aspects clés dont je me souviens particulièrement:
- Dans la zone de sécurité, l'ensemble des autorisations préconfigurées pour les utilisateurs par défaut sera minimal. Contrairement à Tiller, qui a automatiquement reçu les droits d'administrateur sur l'ensemble du cluster, dans Helm 3.0, vous devrez accorder manuellement des privilèges aux comptes d'utilisateur (utilisateur) et de service (service) conçus pour fonctionner avec Helm. Cette modification garantit une prise de décision éclairée des administrateurs sur la sécurité de leurs clusters.
- Le deuxième changement majeur est la prise en charge améliorée de CRD. Dans la version actuelle de Helm, CRD est installé via le crochet
crd-install , défini comme une annotation. Cependant, tous les développeurs et opérateurs CRD ne l'utilisent pas. Cela rend les graphiques Helm vulnérables aux erreurs d'installation, car la définition correcte des graphiques nécessite que les CRD soient placés devant les manifestes de ressources personnalisées. Helm 3.0 portera le support CRD à un nouveau niveau. Le sous-répertoire chrts apparaîtra dans le répertoire des crd . Il suffira à l'utilisateur d'ajouter tous les fichiers CRD YAML à ce répertoire. Helm le traitera avant de définir le reste du graphique. Cette procédure garantit que CRD est installé avant d'installer les manifestes de ressources personnalisées. - Des changements majeurs affecteront le travail avec la CLI. Par exemple, maintenant lors de l'installation du graphique, un nom de version aléatoire est généré s'il n'est pas spécifié comme paramètre d'entrée. Dans Helm 3.0, la situation sera inverse: un paramètre avec un nom deviendra obligatoire. Pour conserver la dénomination aléatoire des versions, vous devrez spécifier un indicateur spécial lors de la saisie de la commande.
2. Consolidation des artefacts natifs du cloud
Plusieurs séances ont été consacrées aux problèmes de stockage des cartes Helm. Ces séances étaient dirigées par
Josh Dolitsky , auteur du
ChartMuseum . Il a présenté le problème, les solutions existantes et a parlé des tendances générales dans cet espace. La principale conclusion est que le travail avec les divers artefacts que vous devez traiter dans l'approche native du cloud (images Docker, graphiques Helm, fichiers de correctifs Kustomize) doit être cohérent.
Le projet
ORAS - OCI Registry as Storage est appelé à assurer le stockage de tous ces artefacts dans un seul registre. Pour les utilisateurs de Kubernetes, c'est certainement un pas dans la bonne direction, car cela vous permettra de consolider divers artefacts dans un registre, tout en fournissant un support pour des choses comme le fractionnement du registre, le contrôle d'accès, etc.
3. Casque et opérateurs
Plusieurs intervenants ont abordé le sujet des contrôleurs et opérateurs utilisateurs dans leurs discours.
La présentation de CloudARK s'est concentrée sur les meilleures pratiques pour créer des graphiques Helm pour les opérateurs.
L'équipe Red Hat a parlé des opérateurs et du
hub opérateur .
Des représentants de
Workday ,
Weaveworks et de l'
Université de Notre Dame ont discuté dans leur discours de l'approche native de Kubernetes pour négocier en continu les versions basées sur Helm dans un cluster à l'aide d'un processus appelé GitOps.
( Note à traduire : En savoir plus sur GitOps ici .)La conclusion clé de toutes ces performances est que Helm et les opérateurs se complètent bien. Alors que le premier (Helm) se concentre sur le modèle et la simplicité de gestion des artefacts, le second (opérateurs) se concentre sur la gestion des tâches du jour 2
(c'est-à-dire au stade du cycle de vie du système, lorsqu'il commence à porter ses fruits pour ses créateurs - env. ) pour les logiciels tiers tels que les bases de données relationnelles / non relationnelles exécutées dans un cluster Kubernetes.
4. Problèmes de gestion des graphiques de barre
En ce qui concerne les applications de grande entreprise, un graphique Helm ne suffit pas. Quelques graphiques sont nécessaires.
La présentation de GitLab a été une véritable découverte dans ce sens. Ils ont de nombreux graphiques, tandis que la taille moyenne du graphique est également assez grande (plusieurs milliers de lignes). La gestion de tous ces graphiques n'est pas une tâche facile en soi.
Il y a eu deux présentations intéressantes sur divers aspects de ce problème. Dans l'un
, l'équipe IBM a présenté son outil interne qui simplifie la recherche de graphiques Helm selon divers critères. Ils se sont concentrés sur la résolution du problème des ingénieurs DevOps, qui ont été forcés de sélectionner et d'installer des graphiques dans leurs clusters. Dans un autre,
l'équipe répliquée a parlé de tenter de résoudre le problème de la gestion des modifications des graphiques Helm sans créer de copies ou de fourchettes. L'essence de leur approche consiste à séparer le graphique Helm de base et à créer des graphiques Helm personnalisés en empruntant l'idée de la personnalisation à partir des fichiers de correctifs. À l'avenir, nous pourrons assister à une activité rapide dans cette direction alors que divers fournisseurs se concentrent sur divers aspects des graphiques Helm qui influencent leur gestion. Par exemple, chez CloudARK, nous nous
concentrons sur les graphiques Helm pour les opérateurs qui reçoivent des annotations spéciales de
platform-as-code pour faciliter la découverte et faciliter l'utilisation des ressources personnalisées.
5. Communauté hospitalière
Les développeurs de casques et les membres clés de la communauté se sont avérés être des gens très sympathiques. Ils étaient ouverts et disponibles pour toutes les discussions et questions, telles que les dates de sortie, les réflexions sur Helm et kustomize, les événements communs avec KubeCon, etc.
Ils ont également parlé du processus de participation au développement de Helm. Il ne semblait pas trop compliqué. Le projet Helm n'a pas encore adopté le processus KEP (Kubernetes Enhancement Proposal). Cependant, cela peut changer une fois la phase d'incubation terminée.
CloudARK au Helm Summit
Notre présentation au sommet était consacrée aux principes et aux meilleures pratiques de création de cartes Helm pour les opérateurs. Nous proposons iPaaS, qui permet aux équipes DevOps de créer leurs propres piles de plateforme Kubernetes sans aucune connexion au fournisseur Kubernetes ou aux interfaces propriétaires. Les CRD / opérateurs nécessaires sont regroupés sous forme de graphiques Helm avec un accent particulier sur la compatibilité des ressources personnalisées de divers opérateurs.
La présentation était basée sur les enseignements tirés du développement indépendant de plusieurs opérateurs et de l'analyse de plus d'une centaine d'opérateurs accessibles au public afin d'obtenir une couche de plateforme Kubernetes Native personnalisée, prête à être utilisée par l'entreprise.
Amsterdam
Le lieu de la conférence offre une vue panoramique sur l'un des nombreux canaux d'Amsterdam.
Conclusion
Helm est sur le point de devenir un projet CNCF de haut niveau. Au cours des dernières années, il est devenu plus mature, a acquis une forte communauté et une grande popularité. Si vous ne l'utilisez pas encore, essayez-le. Il offre l'un des moyens les plus simples de modèle et de gestion des artefacts Kubernetes. Pour ceux qui l'utilisent déjà massivement, Helm 3.0 devrait dissiper de nombreux problèmes de sécurité et fournir un support explicite pour l'extensibilité de Kubernetes via CRD.
PS du traducteur
D'autres impressions du dernier Helm Summit et de ses rapports peuvent être trouvées sur Twitter en utilisant la balise
#HelmSummit .
Lisez aussi dans notre blog: