KuboCD : déployer sur Kubernetes sans maîtriser Helm

Presque toutes les applications prêtes pour Kubernetes sont livrées avec un chart Helm. Et presque tous ces charts sont conçus pour couvrir le plus grand nombre de cas possible : c'est leur qualité, et c'est aussi leur problème. La documentation de KuboCD le pose sans détour — ces charts sont « conçus pour être très flexibles et couvrir un large éventail de cas d'usage, ce qui rend souvent leur configuration complexe ».

La conséquence est connue de toutes les équipes plateforme : déployer une application suppose de comprendre l'écosystème Kubernetes en profondeur, donc le déploiement finit par retomber sur les administrateurs. Et même pour eux, la verbosité des valeurs Helm et la répétition des mêmes variables d'un environnement à l'autre restent, toujours selon la documentation, « fastidieuses et sources d'erreurs ».

KuboCD attaque ce problème par le packaging. L'idée : qu'un ingénieur plateforme emballe une fois pour toutes un chart et ses réglages, et qu'un développeur puisse ensuite le déployer sans connaître Helm.

Deux objets, et c'est tout

Le modèle tient en deux concepts.

Un Package est une image de conteneur conforme à OCI qui embarque un descripteur d'application et un ou plusieurs charts Helm. Point important, souvent mal compris : ce n'est pas une ressource Kubernetes. La documentation l'écrit noir sur blanc — « A KuboCD Package is NOT a native Kubernetes resource ». On l'écrit en YAML, on le construit, et on le pousse dans un registre d'images comme n'importe quelle image.

Une Release, elle, est bien un objet Kubernetes : une ressource personnalisée du groupe kubocd.kubotal.io/v1alpha1. Elle désigne un Package par son dépôt OCI et son tag, lui passe des paramètres, et représente son déploiement dans le cluster.

Un Package contient une liste de modules, un par chart Helm à déployer. La source de chaque chart doit être l'une de quatre origines exactement : helmRepository, git, oci ou local. Le champ values d'un module n'est pas un fichier de valeurs figé mais un gabarit : KuboCD le rend lui-même, en y injectant les paramètres de la Release, puis transmet le YAML obtenu au chart.

Ce sont ces paramètres qui font tout l'intérêt de l'exercice. Le Package déclare sous schema.parameters ce qu'il accepte — un schéma JSON/OpenAPI standard, ou le format simplifié de KuboCD. Un Package sans schéma n'accepte aucun paramètre. Autrement dit : l'ingénieur plateforme décide exactement quels boutons il expose, et le reste du chart devient un détail d'implémentation.

Ce qui se passe réellement dans le cluster

KuboCD ne déploie rien lui-même. C'est le point le plus utile à comprendre, et celui qui rassure quand quelque chose ne marche pas : son contrôleur se contente de fabriquer des ressources Flux, qui font le travail.

Pour une Release nommée podinfo1, il crée :

• une OCIRepository et une HelmRepository, toutes deux préfixées kcd- — donc kcd-podinfo1 ;
• une HelmRelease par module, nommée <release>-<module>, soit podinfo1-main. Celle-là ne porte pas le préfixe.

Le chart étant enfermé dans l'image OCI du Package, KuboCD l'expose à Flux via une HelmRepository interne qui pointe vers son propre service. Tout reste inspectable avec les outils habituels :

kubectl describe release podinfo1

Events:
  Type    Reason                 Age   From     Message
  ----    ------                 ----  ----     -------
  Normal  OCIRepositoryCreated   49s   release  Created OCIRepository "kcd-podinfo1"
  Normal  HelmRepositoryCreated  45s   release  Created HelmRepository "kcd-podinfo1"
  Normal  HelmReleaseCreated     44s   release  Created HelmRelease "podinfo1-main"

Quand un déploiement se bloque, le statut dit où regarder : WAIT_OCI renvoie à l'OCIRepository — URL erronée ou image privée — et WAIT_HREL à la HelmRelease. Le délai d'attente de Helm vaut par défaut la valeur de configuration defaultHelmTimeout, fixée à 3 minutes, et se surcharge aussi bien dans le Package que dans la Release.

Un détail de confort qui en dit long sur la maturité de l'outil : un module nommé noname supprime le suffixe dans les noms générés, ce qui évite les podinfo1-podinfo1. Comme les noms de modules doivent être uniques, un Package ne peut en contenir qu'un seul.

Le Context, ou comment un même Package tourne partout

Reste le problème qui fait échouer la plupart des tentatives de standardisation : le même déploiement doit s'adapter au cluster où il atterrit. Domaine d'ingress, classe de stockage, émetteur de certificats — rien de tout cela n'est portable.

KuboCD isole ça dans une troisième ressource, le Context. C'est un objet Kubernetes à part entière dont le champ spec.context est un dictionnaire libre, sans schéma imposé. Une Release peut y puiser, en ajouter, ou ignorer les contextes par défaut. Dans la section parameters d'une Release, le templating est volontairement restreint : seule la racine .Context est disponible.

Le résultat est net : le Package décrit quoi déployer, le Context décrit où, et la Release ne fait que les marier.

Ce qu'il faut savoir avant de s'y mettre

Quelques points ne sautent pas aux yeux à la lecture de la page d'accueil.

Flux n'est pas une option, c'est une dépendance. La documentation range KuboCD parmi les compagnons des outils GitOps « comme Flux ou ArgoCD », ce qui peut laisser croire à une neutralité. En pratique, l'installation commence par flux install et le contrôleur ne sait produire que des ressources Flux. ArgoCD peut au mieux synchroniser depuis Git les manifestes de Release ; l'exécution du déploiement, elle, passe obligatoirement par Flux.

L'API est en alpha. Les ressources sont en v1alpha1, et le manifeste de Package utilise même un apiVersion nu, sans groupe. À traiter comme tel : les schémas peuvent bouger.

Tous les registres ne conviennent pas. Les registres testés et cités sont quay.io, ghcr.io et distribution. Les autres registres conformes OCI devraient fonctionner, mais Docker Hub n'est explicitement pas supporté à ce jour.

La protection contre la suppression exige le webhook. Le drapeau protected, sur une Release comme sur un Context, ne fait rien si le webhook de KuboCD n'est pas installé.

Côté ergonomie, la CLI offre l'outil qu'on espère : kubocd render permet de tester une Release et d'inspecter les valeurs produites sans rien déployer. La documentation le recommande d'ailleurs plutôt que d'écrire le contexte résolu dans le statut, qui devient vite volumineux. Pour les tags de Packages, la convention proposée reprend la version du chart principal suivie d'une révision de packaging — 6.7.1-p01 pour le chart podinfo 6.7.1.

Alors, pour qui ?

KuboCD n'essaie pas de remplacer Helm — la documentation insiste sur ce point, et le fonctionnement le confirme puisque tout finit en HelmRelease. Il ajoute une couche au-dessus : Helm reste le moteur de templating, Flux reste le contrôleur GitOps, et KuboCD devient la couche de packaging et d'abstraction entre les deux.

Le calcul devient intéressant quand plusieurs équipes déploient les mêmes briques sur plusieurs environnements, et qu'on souhaite exposer trois paramètres plutôt que trois cents lignes de valeurs. Il l'est encore davantage pour amorcer un cluster de zéro : l'outil sait aussi provisionner les composants système — contrôleur d'ingress, répartiteur de charge, opérateurs — ce qui ouvre la voie à un bootstrap intégralement automatisé.

À l'inverse, si une seule équipe déploie une seule application, la couche supplémentaire coûtera plus qu'elle ne rapporte. Un chart Helm et un values.yaml restent la bonne réponse.