Présenté sur HN : Glasskube – un gestionnaire de paquets Kubernetes open source comme alternative à Helm

 (github.com/glasskube)
3 points par GN⁺ 2024-06-27 | 1 commentaires | Partager sur WhatsApp
  • Glasskube est présenté comme un gestionnaire de paquets open source pour Kubernetes, qui rendrait le déploiement, les mises à jour et la configuration 20 fois plus rapides qu’avec des outils comme Helm ou Kustomize
  • Les utilisateurs peuvent déployer des paquets via l’UI Glasskube, la CLI ou une approche GitOps ; l’outil s’inspire de la simplicité de Homebrew et de npm
  • Ses principales fonctionnalités incluent l’installation de paquets depuis l’UI sans rechercher de dépôts Helm, la saisie de configuration typée, l’injection de valeurs entre paquets, l’installation tenant compte des dépendances et des mises à jour sûres prétestées
  • Tous les paquets Glasskube sont gérés comme des ressources personnalisées et peuvent être manipulés via GitOps ; plusieurs dépôts ainsi que le déploiement de private packages sont également pris en charge
  • Il prend actuellement en charge Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack, Cloud Native PG, etc. ; la version bêta peut être installée avec Homebrew

Le problème de gestion de paquets Kubernetes que Glasskube veut résoudre

  • Glasskube est un gestionnaire de paquets open source pour Kubernetes
  • Il est présenté comme rendant le déploiement, la mise à jour et la configuration de paquets dans Kubernetes 20 fois plus rapides qu’avec des outils comme Helm ou Kustomize
  • Inspiré par la simplicité de Homebrew et de npm, il permet aux utilisateurs de choisir l’une des approches suivantes
    • l’UI Glasskube
    • la CLI Glasskube
    • le déploiement direct de paquets via GitOps
  • Son développement part de l’expérience acquise pendant plus de cinq ans dans l’écosystème Kubernetes, avec des difficultés récurrentes autour de la gestion de paquets, de la configuration et du déploiement
  • Dans les workflows existants, beaucoup de temps était consacré à créer des modèles et à rédiger de la documentation pour des commandes et concepts difficiles à comprendre
  • Des outils comme Homebrew, apt et dnf, simples à utiliser et peu problématiques, ont servi de point de comparaison pour le développement de Glasskube

Flux d’installation et de configuration

  • La version bêta peut être installée avec Homebrew
brew install glasskube/tap/glasskube
  • Les autres options d’installation sont disponibles dans le guide d’installation
  • Après l’installation de la CLI, exécutez la commande suivante pour installer les composants nécessaires dans le cluster
glasskube bootstrap
  • Une fois le bootstrap du cluster terminé, vous pouvez démarrer l’UI du gestionnaire de paquets
glasskube serve
  • Cette commande ouvre http://localhost:8580 dans le navigateur par défaut, où l’utilisateur peut parcourir et installer les paquets disponibles

UI, configuration et gestion des dépendances

  • L’UI Glasskube regroupe tous les paquets au même endroit, permettant d’installer des paquets dans le cluster sans devoir rechercher séparément des dépôts Helm
  • La configuration des paquets peut être définie avec des entrées typées via l’UI ou un questionnaire interactif en CLI
    • Il est facile d’injecter des valeurs depuis d’autres paquets, ConfigMap ou Secret
    • L’approche proposée évite l’usage de fichiers values.yaml non typés et non documentés
  • La gestion des dépendances permet aux paquets Glasskube d’être utilisés et référencés par plusieurs autres paquets
    • Les paquets dépendants sont installés dans le namespace approprié
    • Le README décrit cela comme « la façon dont les umbrella charts auraient dû fonctionner dès le départ »

Mises à jour, GitOps et prise en charge des dépôts

  • Les mises à jour de paquets permettent de prévisualiser une pending update vers la version souhaitée, puis de l’exécuter en un clic ou via une commande CLI
  • Toutes les mises à jour sont prétestées avec la suite de tests Glasskube
  • Les réactions et commentaires sur les paquets peuvent être laissés dans les GitHub discussions ou directement dans l’UI Glasskube
  • L’intégration GitOps repose sur la gestion de tous les paquets Glasskube comme des ressources personnalisées
  • Une intégration avec Renovate est également en cours ; l’issue correspondante se trouve sur renovatebot/renovate#29322
  • Plusieurs dépôts et des private packages peuvent être utilisés
    • Cela peut servir à déployer des paquets de services internes à l’entreprise
    • Le scénario mis en avant consiste à permettre aux développeurs de configurer facilement des services internes à jour

Architecture d’installation des paquets

  • Le flux glasskube install [package] repose sur une architecture dans laquelle l’UI ou la CLI utilise à la fois le dépôt de paquets et l’API Kubernetes via le Client
  • L’UI se connecte au Client via le serveur local http://localhost:8580
  • La CLI se connecte au Client via la CLI cobra
  • Le Client consulte d’abord le Package Repo pour la validation du paquet
  • Après validation, il crée une ressource personnalisée Package dans l’API Kubernetes
  • Dans le cluster, PackageController et PackageInfoController effectuent la réconciliation (reconcile)
    • PackageController réconcilie Package et crée PackageInfo si nécessaire
    • PackageInfoController met à jour le manifest du paquet depuis le dépôt de paquets
    • Le manifest mis à jour est reflété dans PackageInfo
    • Ensuite, PackageController déploie le paquet dans Kubernetes
  • Kubernetes renvoie l’état du paquet au Client

Paquets pris en charge et informations sur le projet

À lire aussi

1 commentaires

 
GN⁺ 2024-06-27
Avis sur Hacker News

  • C’est peut-être un pas dans la bonne direction, mais le plus gros problème actuel de la gestion de paquets Kubernetes semble difficile à résoudre avec un gestionnaire de paquets
    Ce qui est le plus pénible au quotidien, c’est l’empilement de YAML imbriqué sur plusieurs niveaux, avec un résultat imprévisible
    Par exemple, un ArgoCD ApplicationSet crée plusieurs Applications, ces Applications rendent des charts Helm, et ces charts contiennent des CRD utilisés par des opérateurs arbitraires comme Strimzi, Grafana ou Vector
    YAML a une syntaxe pauvre et il n’existe pas non plus de standard pour le rendu de templates, si bien qu’il est presque impossible de savoir quel YAML sera réellement injecté dans l’API Kubernetes après une modification au niveau le plus haut
    Au final, cela mène chaque mois à des essais-erreurs, à des déploiements blue-green coûteux et à des centaines de minutes de débogage

    • L’adoption généralisée de YAML dans les outils autour de DevOps a été une erreur
      À mon avis, la bonne direction est de prendre en charge un vrai langage de programmation
      Idéalement, il faudrait un système de types statique qui ne soit pas Turing-complet et dont la terminaison soit garantie ; quelque chose comme un Starlark typé semblerait approprié
    • Je me demande si vous avez essayé le pattern des manifestes rendus : https://akuity.io/blog/the-rendered-manifests-pattern/
    • C’est le problème sur lequel Glasskube Cloud(https://glasskube.cloud/) veut se concentrer
      L’idée est que glasskube[bot] commente les pull requests GitOps avec le diff exact des ressources qui changeront réellement dans tous les clusters concernés
      Ce diff est produit par un contrôleur exécuté dans le cluster
      On peut voir cela comme une analyse à la codecov, mais dédiée aux changements de ressources
    • La solution, c’est de ne pas utiliser Kubernetes

  • Cela semble être une approche intéressante de la gestion de paquets, et ça paraît adapté à des usages du type cluster à la Homebrew
    Cela dit, personnellement, ne serait-ce que pour maintenir la cohérence dans le dépôt, je préfère la combinaison helmfile + Renovate + pipeline
    Par exemple, un bouton update all me semble assez effrayant sur un cluster qui compte vraiment
    Pour des projets personnels, cela reste un outil sympa
    Le contrôleur de paquets ressemble beaucoup au Tiller de l’ancien Helm, qui a posé de gros problèmes de sécurité dans de nombreuses entreprises avant d’être retiré dans Helm 3 au profit d’un traitement côté client basé sur des configmaps ; je suis curieux de voir comment ce projet compte dépasser ce problème

    • Les paquets Glasskube peuvent être placés dans un dépôt GitOps, car chaque paquet est une CR (custom resource)
      Il est aussi possible de les configurer dans le CLI avec les flags --dry-run et --output yaml, puis de les mettre dans Git
      Nous travaillons également sur des pull requests qui prennent en charge les mises à jour de paquets avec Renovate : https://github.com/renovatebot/renovate/issues/29322
      Helm 3 est désormais un outil côté client, il ne peut donc pas imposer lui-même de RBAC
      OLM a introduit les Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) afin de fournir des permissions au niveau des opérateurs
      On pourrait introduire quelque chose de similaire dans les paquets Glasskube ; Glasskube lui-même aura toujours besoin de permissions assez élevées, mais il serait possible de limiter la portée des paquets et d’ajouter des permissions plus granulaires

  • Traditionnellement, les packages d’applications sont des binaires immuables à version figée avec des étapes avant et après installation ; ils sont construits pour une plateforme donnée et des dépendances précises, et les possibilités de configuration à l’installation sont extrêmement limitées.
    Si les packages fonctionnent bien, c’est parce qu’ils sont conçus pour un environnement très spécifique et que l’on minimise ce qui peut être modifié à l’installation.
    Malgré cela, même dans ce cadre étroit, les packages de systèmes d’exploitation nécessitent en permanence énormément de tests, de développement et de correctifs.
    Si le package que vous installez aujourd’hui paraît simple, c’est peut-être parce que des centaines d’heures ont été consacrées à la plateforme, aux composants et aux versions actuels.
    Les « packages » Kubernetes ne sont pas vraiment des packages : ce sont plutôt des ensembles d’instructions décrivant les composants à installer et à configurer, et ils regroupent souvent plusieurs applications distinctes.
    Cette différence se manifeste de deux façons : les « packages » K8s ont une définition très lâche, donc beaucoup de variabilité, et toutes sortes de personnes les créent de toutes sortes de manières, avec toutes sortes d’hypothèses sur l’état du système cible.
    Pour qu’un « package » Kubernetes fonctionne, plusieurs couches de dépendances et de configuration doivent être alignées.
    La version de l’API K8s, la manière dont les composants K8s sont installés et exécutés, les ACL, l’absence de composants existants susceptibles d’entrer en conflit, le verrouillage des versions des composants et conteneurs installés par le package ainsi que leur compatibilité avec le reste du cluster, sans oublier la configuration utilisateur : tout doit correspondre.
    Les mises à niveau sont tout aussi confuses, faute de notion d’arbre de versions stables ou de rolling release ; c’est un peu comme installer des fichiers .deb, .rpm ou .dmg arbitraires sur un système d’exploitation en espérant que tout se passe bien.
    Aujourd’hui, rien ne prend tout cela en charge.
    Pour rendre le packaging Kubernetes aussi fluide que le packaging de binaires par plateforme, il faudrait toute une communauté de mainteneurs, ainsi qu’une approche de type rolling release à la Homebrew ou des branches de versions stables.
    Au final, il faudrait qu’un projet comme ArtifactHub ou Homebrew gère tous les packages d’une seule et même manière, ce qui représente un gros chantier et ne semble absolument pas rentable.

    • Glasskube a aussi commencé d’une manière similaire à Homebrew, en plaçant les packages dans un dépôt de packages Glasskube « core » (https://github.com/glasskube/packages).
      L’idée est de centraliser toutes les mises à jour et de les tester via des workflows CI/CD, afin que les utilisateurs bénéficient de mises à niveau testées et fluides.
      Les utilisateurs peuvent aussi héberger leurs propres dépôts et packages, mais par défaut nous voulons fournir directement un ensemble de packages assumé.
      Nous réfléchissons déjà à la construction pour différentes versions ou différents environnements Kubernetes, et ce sera probablement nécessaire un jour si l’on veut intégrer davantage de configuration à l’étape de build.

  • Je ne suis pas sûr qu’un gestionnaire de packages K8s puisse devenir aussi simple que brew ou apt.
    C’est particulièrement lié au fait que les valeurs varient selon l’environnement cible, et que presque tous les utilisateurs ont un environnement « flocon de neige » qui leur est propre.
    Utiliser des invites de type REPL ou une interface web pour configurer ces valeurs ne m’attire pas.
    La douleur principale reste non résolue : écrire des charts Helm est pénible, il faut gérer les valeurs par environnement, et j’aimerais qu’on n’ait pas à relier les valeurs entre charts.

    • Sur le terrain, il y a effectivement énormément de clusters flocon de neige, et c’était aussi un sujet brûlant lors d’une conférence cloud native à laquelle j’ai récemment assisté.
      Les équipes plateforme construisent des plateformes internes pour développeurs afin de standardiser davantage la configuration Kubernetes entre les équipes et les clusters, et de ne laisser aux développeurs que de petites modifications.
      D’expérience, ces configurations disparates doivent être réduites, et c’est aussi l’une des raisons pour lesquelles nous avons créé Glasskube.
      Je suis d’accord à 100 % pour dire qu’écrire des charts Helm est pénible, et nous voulons changer cela à l’avenir.
      Les packages Glasskube restent configurables, mais fournissent des valeurs par défaut pertinentes.
      Glasskube permet de référencer facilement les valeurs de configuration d’autres packages, afin de ne pas devoir fournir plusieurs fois la même valeur.

  • Je crée beaucoup d’opérateurs Kubernetes et je rencontre souvent les problèmes liés à Helm et OLM.
    La documentation dit que « les mises à niveau des CRD sont prises en charge par Glasskube afin d’éviter que les CR et les opérateurs ne divergent », mais chercher « CRD » dans la documentation ne donne aucun résultat concret.
    C’est aujourd’hui l’une des plus grandes douleurs avec Helm ; je me demande donc si vous pouvez partager votre plan.
    [1] <https://stackable.tech/en/>
    [2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

    • Les packages du dépôt public Glasskube sont configurés pour que les changements de CRD soient appliqués.
      C’est géré via Manifest ou helm-controller.
      La documentation sera mise à jour.

  • Je pense que Kubernetes est fondamentalement limité par un modèle d’opérateur trop simpliste.
    L’idée générale me plaît, mais réduire tout le modèle à « état actuel, état souhaité, prochaine action » est en pratique impossible.
    Au final, tout le workflow se retrouve dans la logique de prochaine action, et comme il y a trop d’opérateurs qui observent le même état du système, il est difficile de savoir comment les différents composants vont interagir.
    Les problèmes de Helm sont un sous-cas de ce problème plus large.
    Par analogie, c’est le même type de problème que celui que la programmation front-end rencontre avec le DOM.
    Introduire un paradigme de DOM virtuel/réducteur, comme React, aiderait beaucoup à résoudre ce type de problème.

    • « État actuel, état souhaité, prochaine action » correspond fondamentalement au fonctionnement de la théorie du contrôle classique.
      Il y a un état, un objectif et des perturbations par rapport à cet objectif ; si l’on veut un outil puissant et flexible, ce niveau d’abstraction me paraît approprié.
      Le problème, c’est que les caractéristiques physiques et la disposition de la machine font une telle différence que le coût pour les virtualiser ou les simuler de façon pertinente est trop élevé.
      À la place, on vérifie donc que l’état de configuration fonctionne sur un sous-ensemble de la structure physique.
      C’est l’approche consistant à avoir des environnements dev, staging et prod, et à utiliser des déploiements colorés, de l’analyse canary, des rollouts partiels, etc.

  • Si l’utilisation de K8s nécessite ce genre d’outil, il vaut probablement mieux choisir une autre solution.
    Kubernetes n’a pas été conçu pour être utilisé sans connaissances préalables, et il est difficile.
    À moins de construire un PaaS complet, il est difficile d’échapper à cette complexité.

  • Cet outil me semble mal orienté côté marketing
    Ça n’a pas grand-chose à voir avec Helm
    Pour moi, Helm est avant tout un langage de templating, pas un gestionnaire de paquets, et une façon de configurer et d’installer dans des clusters K8s via kubeapps, le CLI Helm et ArgoCD
    Cette approche casse aussi un excellent paradigme d’IaC
    Car une fois ArgoCD bootstrapé, l’idéal est d’avoir une architecture qui ne fait que référencer des dépôts Git
    La démo ne montre pas comment utiliser les fonctionnalités de templating comme la prise en charge des form, elle montre seulement le reste
    J’ai toujours le sentiment qu’il y a quelque chose qui cloche avec Helm, donc honnêtement l’outil lui-même me plaît, mais avec l’approche actuelle je pense qu’il va échouer
    Les grandes entreprises n’en ont pas besoin, il sera donc difficile d’obtenir une adoption suffisante
    Kubeapps comme Helm fonctionnent bien, et même si l’objectif est de remplacer Helm, il est probable que la prise en charge de Helm reste longtemps
    Le problème de Helm, c’est que plus les charts grossissent, plus ils deviennent complexes
    Avoir pratiquement tout dans un seul dossier templates, c’est le bazar ; YAML n’est pas adapté aux templates, et values.yaml devient beaucoup trop gros

    • La démo est davantage centrée sur l’utilisateur final
      Vous trouverez plus de détails sur les options de configuration dans la documentation de configuration des paquets : https://glasskube.dev/docs/design/package-config/
    • Je ne veux pas paraître arrogant ou méprisant, mais si vous pensez que Helm n’est pas principalement un gestionnaire de paquets, c’est que vous n’avez pas beaucoup travaillé avec de l’infrastructure déployée sur K8s

  • L’argument de vente selon lequel ce serait plus rapide que Helm ne m’attire pas vraiment
    Je n’ai jamais eu l’impression que le problème de Helm était la vitesse

  • Ça a l’air intéressant
    Une courte explication de la façon dont cela s’intègre aux outils existants comme ArgoCD, ou s’y compare, aiderait à comprendre
    J’ai regardé la vidéo, et comme l’un des outils installés était Argo, cela occupe clairement une autre niche, mais je ne vois pas encore vraiment laquelle

    • ArgoCD est un excellent outil pour synchroniser l’état d’un dépôt GitOps vers un cluster, visualiser les ressources installées et signaler les erreurs potentielles
      Il est souvent utilisé pour permettre aux développeurs de consulter l’état des applications cœur de métier de l’entreprise sans accès au cluster
      Glasskube se concentre sur les paquets dont dépendent ces applications principales
      Il gère le cycle de vie des composants d’infrastructure, teste les mises à jour et fournit des chemins de mise à niveau
      Vous pouvez aussi placer des paquets Glasskube dans un dépôt GitOps et les synchroniser vers le cluster avec ArgoCD ; PackageController s’occupe du reste