Kubara : générez et pilotez vos plateformes Kubernetes

Temps de lecture : 8 min

Le vrai défi des plateformes Kubernetes

Un cluster Kubernetes seul ne fait pas une plateforme. Concrètement, les équipes applicatives ont besoin d’ingress, de certificats, de DNS, de secrets, de politiques, d’observabilité, de stockage, de sauvegardes et d’un pipeline de déploiement fiable. Installer ces briques techniques n’est que la partie émergée de l’iceberg. Le vrai problème, c’est de les combiner en un ensemble cohérent, reproductible, révisable et capable d’évoluer entre différents clusters et environnements.

C’est exactement là que kubara entre en jeu.

Pourquoi les équipes plateforme ont besoin de plus que des charts Helm

Très souvent, les équipes font face à trois défis interconnectés :

• Manque d’expertise et itérations coûteuses : Personne n’a envie de réévaluer et d’intégrer les mêmes outils encore et encore avant de livrer une plateforme utilisable.
• Écosystème Kubernetes complexe : Choisir le bon outil, c’est déjà un défi. Mais faire fonctionner leurs APIs, dépendances, configurations et cycles de vie ensemble, c’est un tout autre niveau.
• Changement permanent : L’écosystème Kubernetes évolue vite. Chaque mise à jour doit être testée, révisée et promue sans transformer l’architecture.

kubara répond à ces problèmes avec un catalogue maintenu de versions de composants, une génération reproductible et un modèle GitOps. Cela ne remplace pas le jugement des ingénieurs, mais leur donne une base solide pour prendre des décisions éclairées.

Le modèle central : contrat, catalogue et GitOps

Les concepts fondamentaux de kubara peuvent se résumer en quatre étapes.

1. Déclarez le contrat de la plateforme

Dans un fichier config.yaml, vous décrivez la plateforme souhaitée : clusters, environnements, fournisseurs cloud, services activés et leur configuration. Ce fichier sert de contrat machine-entre l’équipe et kubara.

2. Combinez-le avec un catalogue de composants

kubara embarque un catalogue intégré contenant des définitions de plateforme et des versions de composants. Les utilisateurs ne modifient pas ce catalogue directement. Les entreprises peuvent fournir un catalogue externe, que kubara fusionne avec le catalogue intégré pour produire un catalogue effectif.

Une analogie avec un gestionnaire de paquets est utile : un chart Helm empaquette une application, tandis qu’un catalogue kubara empaquette les définitions et les motifs de configuration pour une architecture de plateforme réutilisable. kubara ne se contente pas de gérer un catalogue, il génère l’état désiré et le prépare pour le delivery GitOps.

3. Générez un état de plateforme révisable

kubara combine le contrat de plateforme et le catalogue effectif pour produire des artefacts concrets. Deux résultats principaux :

• platform-components/ : pour les composants réutilisables générés.
• platform-configs/ : pour les valeurs et configurations spécifiques au cluster.

Les fichiers générés peuvent être inspectés, testés, versionnés et révisés comme du code traditionnel. Les personnalisations durables doivent être placées dans des fichiers de surcharge documentés, plutôt que modifiées directement dans les fichiers générés.

4. Laissez Argo CD concilier le résultat

kubara initialise Argo CD sur le cluster hub. Une fois l’état désiré révisé, commité et poussé, Argo CD le concilie en continu contre les clusters cibles.

Cette frontière de responsabilité est cruciale : kubara génère et initialise l’état de la plateforme, tandis qu’Argo CD assure la réconciliation continue. kubara n’a donc pas besoin de tourner en permanence dans chaque cluster.

Les composants disponibles dans le catalogue intégré

Le catalogue intégré fournit une base de plateforme par défaut. Voici les catégories principales :

• Delivery GitOps : Argo CD, pour le déploiement continu basé sur Git.
• Ingress et DNS : Controllers d’ingress, gestion de DNS et certificats (cert-manager).
• Gestion des secrets : External Secrets Operator, pour synchroniser les secrets depuis des backends externes.
• Politiques et sécurité : Kyverno, pour l’application de politiques Kubernetes.
• Observabilité : Collecte de métriques, logs et traces.
• Stockage et sauvegardes : Solutions de stockage persistant (Longhorn) et de sauvegarde.

Le choix des composants dépend de l’environnement. Un cluster managé (EKS, AKS, GKE) fournit déjà load balancing, stockage persistant et plan de contrôle. kubara ajoute alors les capacités de plateforme manquantes. Dans un environnement edge ou bare-metal, il faudra ajouter MetalLB pour les services LoadBalancer ou Longhorn pour le stockage distribué.

De l’architecture Hub-and-Spoke

kubara supporte une architecture hub-and-spoke centrale. Le cluster hub fait office de cluster de gestion. Argo CD y tourne et gère l’état désiré sur le hub lui-même et sur tous les spokes enregistrés. Les spokes peuvent fournir des frontières Kubernetes distinctes pour environnements, régions, équipes ou locataires.

Pas besoin de commencer avec des dizaines de clusters. Un seul cluster Kubernetes peut faire office de cluster initial et de cluster de gestion. Au fur et à mesure que des environnements supplémentaires ou des frontières d’isolation sont nécessaires, des spokes peuvent être enregistrés via le même contrat de plateforme.

Capacités clés de kubara

Amorcer et faire évoluer la plateforme

kubara peut initialiser une plateforme sur un cluster Kubernetes existant. Le hub initial héberge Argo CD et gère son propre état désiré. Des presets Terraform optionnels aident à provisionner l’infrastructure, mais ne sont pas requis.

Quand le contrat de plateforme, la configuration ou la version du catalogue changent, kubara regénère l’état désiré. Vous reviewz le diff Git, testez les changements, et les promouvez via le workflow Git standard. Argo CD applique ensuite l’état approuvé.

Intégrer des clusters spoke

Un cluster spoke doit exister et être accessible depuis le hub. Les credentials d’accès doivent être stockés dans un backend de secrets externe (AWS Secrets Manager, HashiCorp Vault…), et non commités dans Git. Ajoutez simplement la définition du spoke dans config.yaml, régénérez, reviewz, et commitez.

Les ApplicationSets générés par kubara peuvent ensuite cibler des clusters par étiquettes. Vous déployez ainsi une capacité uniquement sur les clusters correspondants, sans maintenir des définitions Argo CD en double.

Établir un delivery GitOps par locataire

kubara soutient le delivery GitOps multi-locataire via les AppProjects d’Argo CD. Chaque projet définit quels dépôts Git, clusters de destination, namespaces et types de ressources sont autorisés. Les Applications connectent un chemin de dépôt à un AppProject et à une destination permise.

Cette approche offre des frontières de delivery claires sans dupliquer la configuration. Attention cependant : l’isolation au niveau locataire (network policies, quotas, runtime isolation) doit être conçue séparément.

Ce que kubara n’est pas

kubara est délibérément concentré sur la génération et l’évolution de l’état désiré d’une plateforme Kubernetes. Il est important de comprendre ses limites :

• Ce n’est pas une distribution Kubernetes.
• Ce n’est pas un contrôleur de plateforme permanent.
• Il ne remplace pas Argo CD.
• Il ne nécessite pas Terraform et n’est pas un gestionnaire d’infrastructure cloud.
• Ce n’est pas un portail développeur, un hébergeur de code source ou un système CI.

Son périmètre commence au niveau Kubernetes. Les clusters existants sont des points de départ de première classe, tandis que les presets Terraform optionnels ne couvrent que des scénarios d’infrastructure spécifiques.

Où kubara se situe dans l’écosystème

kubara se place entre la définition de la plateforme et la réconciliation GitOps continue. Il combine un contrat déclaratif, un catalogue réutilisable, génère un état de plateforme transparent et en supporte l’évolution contrôlée.

Personnellement, j’apprécie particulièrement sa capacité à générer un état révisable sans cacher la complexité. Quand j’ai construit GymLog, j’ai expérimenté le même besoin de reproductibilité entre environnements de dev, staging et production. kubara apporte cette discipline au monde Kubernetes sans imposer de framework propriétaire.

Pour faciliter la découverte, n’hésitez pas à laisser une étoile sur GitHub.