Comment bitnami a plié le Kube…

🤬 On l'avait presque pas vu venir !

Annoncé pendant les vacances d'été : https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2025/08/18/how-to-prepare-for-the-bitnami-changes-coming-soon nous avons eu la très désagréable surprise de découvrir que le projet bitnami était devenu payant !

L'ensemble des nos clusters Kubernetes s'appuient sur des composants issus de ce projet et ont donc tous été directement impactés. Remettons un peu de contexte...

Pourquoi utiliser bitnami ?

Imagine, tu souhaites déployer un système de gestion de base de données, un serveur web, un outil de cache, etc., sur un cluster Kubernetes. Il faut composer avec des fichiers YAML, des configurations, des dépendances, des versions, des compatibilités… Bref, ça peut très vite se transformer en usine à gaz pour certaines applications. Nos clients préfèrent toujours de très loin la simplicité à la complexité technicienne !

Les charts Helm (et par extension les charts Bitnami) empaquettent toutes les ressources nécessaires (Deployments, Services, ConfigMaps, etc.) pour déployer une application sur Kubernetes de façon standardisée et répétable. On saupoudre de quelques variables adaptées, on lance la commande helm install, et le composant se déploie (dépendances incluses). C’est comme un kit IKEA pour Kubernetes (mais sans la notice 😂)

Les charts Bitnami, en particulier, étaient les plus populaires car il s'agissait d'une collection bien maintenue, des choix par défaut raisonnables, des versions stables, et surtout une confiance assez large dans la communauté. Ils faisaient partie du "kit de démarrage" pour beaucoup de nos clusters.

Enfin, au delà même des charts helm, beaucoup de projets open-source s'appuyaient sur certaines images publiques et génériques de bitnami pour simplifier le déploiement de leur propre composant comment les images : kubectl, os-shell, python...

Le grand virage de Broadcom...

A partir du 28 août 2025, toute la communauté Kubernetes / DevOps s’est prise une belle claque : Bitnami (via son dépôt public docker.io/bitnami) a commencé à retirer ou restreindre l’accès à de nombreuses images versionnées, et à migrer vers un modèle "paid / sécurisé / restreint": bref comprenez une solution payante et plutôt très chère de surcroît : comptez 72.000,00 $/an !

Ce n'est pas le premier coup d'essai de Broadcom pour rentabiliser ses investissements : on se souvient de VMWare intégré dans le même giron quelques temps avant, qui a lui aussi a connu une période de tarification très agitée : https://redresscompliance.com/why-broadcom-killed-perpetual-vmware-licenses-and-what-it-means-for-you/ doublant au passage ses revenus !

Mais ce choix soudain de "rentabiliser" une bibliothèque de logiciels open-source, enfin, on devrait plutôt dire, "le packaging de logiciels open-source" n'aurait jamais dû nous étonner au vue du contexte passé ! Mais bon, je vous avoue que le choc a quand même été rude...

Que faire alors ?

Plusieurs solutions existent bien heureusement pour faire face à cette nouvelle situation !

• Solution 1 - on change presque rien (vision court terme) : les images utilisées existent encore sous un nom différent : bitnamilegacy ! Il suffit de rediriger les références des images vers docker.io/bitnamilegacy/... et maintenir le même tag. Cela donne un peu de répit, mais attention : ce dépôt ne recevra aucune mise à jour ni correctifs. C’est une simple rustine en attendant mieux...
• Solution 2 - on change de crémerie : beaucoup des charts proposés par bitnami ont leur équivalent chez l'éditeur ou le responsable du projet. Il n'est pas rare de trouver mêmes des opérateurs kubernetes très aboutis qui simplifient énormément le déploiement. Il suffit de faire son marché ici : https://artifacthub.io/ ou ici pour les opérateurs : https://operatorhub.io/
• Solution 3 - on sort VSCode et les manifest : plus rare, c'est un vrai retour en arrière, je dois l'admettre, mais certains opérateurs (encore en bêta version pour certains) ne sont pas suffisamment aboutis pour les mettre en production. En plus, on devient méfiant sur les charts helm tout prêt d'une source inconnue... Un bon fichier manifest ou développer ses propres charts est parfois la solution la plus adaptée !