Outils composables pour Kubernetes : dépasser le Helm monolithique

Temps de lecture : 6 min

Construire des outils, pas des temples

Dans mes articles précédents, j’avais présenté des outils de gestion des politiques par namespace sur ConfigHub : namespace-manager, rbac-manager, network-policy-manager. Cette fois, je suis passé aux workloads. Et j’ai voulu pousser la logique plus loin : montrer qu’il est possible de construire une suite d’outils spécialisés, chacun avec ses compétences d’agent, en un seul jour, sans avoir à réinventer la roue à chaque nouveau déploiement.

Concrètement, les workloads ont des interfaces spécifiques (flags CLI, variables d’environnement, config applicative, endpoints de probes). Leur configuration est mieux gérée avec des schémas et contraintes dédiés — je vous en reparlerai dans un prochain billet. Mais les workloads ont aussi des aspects sécuritaires et opérationnels qui sont transverses et souvent déterminés par l’environnement de déploiement : capacités système, ressources, scaling automatique, accès réseau, observabilité. Autant de dimensions qu’il serait absurde de reconfigurer manuellement pour chaque microservice.

La suite d’outils que j’ai construite

En m’appuyant sur ConfigHub et le principe de configuration as data, j’ai assemblé quatre agents spécialisés :

• workload-manager : vérifie que les workloads respectent les bonnes pratiques (spécifications de ressources, probes, budgets de disruption de pods, contexte de sécurité).
• scheduling-manager : configure les node selectors, l’affinité de nœud et les tolérances selon des profils prédéfinis.
• observability-manager : gère les ressources Prometheus ServiceMonitor et les sidecars collecteurs OpenTelemetry.
• autoscale-manager : vérifie et édite les ressources HorizontalPodAutoscaler et KEDA, et peut même convertir du HPA en KEDA.

Tous ces outils peuvent également appliquer des postures grâce aux Triggers ConfigHub, via des commandes de type guardrails.

Un exemple concret : gestion des workloads

Avec workload-manager, j’obtiens la liste des workloads déployés, un résumé de leur état, mais aussi une analyse détaillée de chaque ressource. Par exemple, il remonte des informations comme terminationMessagePolicy — un détail que j’affectionne particulièrement.

Plus précisément, si je veux un PodDisruptionBudget pour un workload, je peux le créer automatiquement en une commande : ./bin/cub-workload ensure-pdb appchat-prod/frontend. L’outil associe automatiquement le namespace et les labels du workload ciblé, comme le ferait kubectl expose — plus simple que de rédiger un YAML intégral. Même chose pour le spreading via anti-affinité de pods : ensure-spread. Ou pour définir les ressources CPU/mémoire, les probes, le contexte de sécurité. Plus besoin d’écrire du YAML à la main.

Les commandes s’exécutent d’abord en mode dry-run et produisent du JSON. Les agents IA peuvent ainsi analyser l’état courant et proposer des modifications. Avec une validation humaine, le changement peut être « commitée » en exécutant la même commande sans dry-run. La modification est ensuite validée automatiquement, et peut être revertie ou ajustée.

Configuration as data : le socle d’interopérabilité

Contrairement à une approche configuration as code (Helm, cdk8s, Tanka), où il faut cloner des repositories, modifier des fichiers, commiter, pousser et multiplier les PRs, la configuration as data stocke tout dans une base de données. Les outils peuvent alors directement lire et écrire via des APIs.

Sous le capot, mes outils utilisent des filtres et fonctions ConfigHub (set-container-resources, set-pod-container-security-context-defaults), de l’analyse côté client, des mutations via le SDK, et des sauvegardes d’invocations. Parce que les données de configuration sont autoritaires, ces outils peuvent interopérer avec d’autres fonctions (comme set-container-image-reference ou set-replicas) et avec des agents IA qui éditent directement la config.

Plus important encore, les outils ne sont pas monolithiques. Chacun couvre un domaine précis. Ils peuvent analyser, résumer, générer, backfiller, promouvoir, valider et enforce. Et ils fonctionnent pour tous les workloads, pas seulement ceux d’une application. Pas de dépendance à des interfaces propriétaires (comme les valeurs d’un chart Helm qui changent d’un chart à l’autre).

Pourquoi j’abandonne l’approche monolithique

Oui, pour une seule application, on pourrait utiliser un template paramétré lourd pour créer un HPA et y coller quelques valeurs. Mais le problème, c’est que chaque chart Helm expose des entrées différentes. Il n’y a pas d’API standard autour de laquelle construire des outils. Les alternatives courantes (webhook d’admission mutating, opérateurs) sont moins transparentes et plus complexes sur le plan opérationnel.

ConfigHub permet de modifier directement la configuration tout en maintenant plusieurs variantes similaires mais différentes de la même configuration, grâces à des mécanismes de synchronisation. C’est un des défis clés que nous résolvons.

Et maintenant ?

Je suis convaincu que cette approche d’outils composables sur de la configuration as data a un fort potentiel. J’expérimente aussi l’écriture d’intention de plus haut niveau via des annotations (sujet d’un futur article). Les outils sont disponibles dans la préversion de ConfigHub, et je vous invite à les tester ou à construire les vôtres.

Questions ouvertes

Quelles sont les customisations transverses que vous devez fréquemment apporter aux configurations de vos workloads Kubernetes ? Quels changements opérationnels courants ne sont pas supportés par les charts Helm que vous utilisez ? Comment les overriddir ? À quelle fréquence vos équipes « cassent la vitre » et modifient directement les clusters ? Avez-vous migré de HPA vers KEDA, ou d’Ingress vers Gateway ? Quels outils kubectl ou autres devrions-nous adapter à ConfigHub ?

Répondez ici ou contactez-moi sur LinkedIn, X ou Bluesky.

Nicolas D.

Développeur full-stack depuis 25 ans, je suis passé du PHP des années 2000 aux stacks modernes (Next.js, React Native, IA). J’accompagne entrepreneurs et créateurs dans leurs projets digitaux avec une approche pragmatique : du code aux résultats concrets.