KubeSphere 4.x : la plateforme Kubernetes multi-cloud et edge, entre micro-noyau et extensions

Le problème que KubeSphere attaque, et pour qui

Un cluster Kubernetes brut ne fournit ni console unifiée, ni découpage multi-tenant prêt à l'emploi, ni chaîne CI/CD intégrée. Les équipes qui exploitent plusieurs clusters, répartis entre fournisseurs cloud, salles machines et sites de périphérie, finissent par recoller une dizaine de briques : un tableau de bord, un gestionnaire de politiques, une pile de journalisation, un moteur de pipeline, un registre d'applications. KubeSphere vise précisément cet assemblage. Le README le formule ainsi : une plateforme conteneurisée pensée pour la gestion multi-cloud, datacenter et edge de Kubernetes, avec une architecture plug-and-play permettant d'intégrer des applications tierces.

Le public visé est donc l'équipe plateforme d'une entreprise, pas le développeur isolé qui déploie une application sur un cluster unique. Le projet revendique une interface web par assistants, une multi-tenancy avec contrôle d'accès par rôles et une gestion des quotas. Les sujets listés dans le dépôt incluent multi-cluster, multi-tenancy, observability et servicemesh, ce qui décrit bien la cible : une organisation qui a déjà plusieurs clusters et qui veut une couche de gouvernance au-dessus.

Micro-noyau plus extensions : ce que change l'architecture 4.x

La version 4.x adopte une architecture dite micro-noyau avec composants d'extension, nom de code LuBan dans la documentation. Le noyau reste Kubernetes. Tout le reste, DevOps, observabilité, service mesh, App Store, gestion de la périphérie, se branche comme extension. C'est un renversement par rapport à un modèle monolithique où chaque fonctionnalité est livrée avec le produit.

La conséquence pratique est double. D'un côté, vous ne payez en ressources que ce que vous activez : une installation qui se limite à la console et à la multi-tenancy n'embarque pas la pile d'observabilité. De l'autre, la surface de compatibilité se déplace. Ce n'est plus la version de KubeSphere seule qui détermine ce qui fonctionne ensemble, mais la combinaison noyau plus extensions, chacune ayant son propre cycle. Le README ne donne pas de matrice de compatibilité entre extensions dans les éléments fournis. C'est un point à vérifier avant de planifier une montée de version, parce que c'est exactement là que ce type d'architecture casse.

Multi-cluster, multi-tenancy et périphérie : les mécanismes revendiqués

Le README décrit un plan de contrôle centralisé pour administrer plusieurs clusters Kubernetes, avec la possibilité de propager une application vers plusieurs clusters répartis chez différents fournisseurs. La multi-tenancy repose sur des espaces de travail isolés, avec contrôle d'accès par rôles et gestion des quotas. Ces deux briques se combinent : un espace de travail délimite qui voit quoi, le RBAC précise les droits à l'intérieur, les quotas plafonnent la consommation.

Pour la périphérie, KubeSphere intègre KubeEdge, ce qui permet de déployer des applications sur des équipements distants et de consulter leurs journaux et métriques depuis la console. Le service mesh est basé sur Istio et couvre la gestion fine du trafic, l'observabilité et le traçage, avec une visualisation de la topologie. Le volet DevOps s'appuie sur Argo CD pour le déploiement continu en GitOps et sur Jenkins comme moteur d'intégration continue.

Il faut noter que ces briques sont des intégrations de projets tiers, pas des implémentations propres. Adopter KubeSphere sur le volet mesh, c'est adopter Istio avec une couche d'interface et d'exploitation par-dessus. La valeur ajoutée se situe dans l'unification et la console, pas dans le remplacement des moteurs sous-jacents.

Mise en route : le chart Helm et ks-installer

Les éléments disponibles indiquent deux chemins. Le premier passe par l'image ks-installer, publiée sur Docker Hub sous kubesphere/ks-installer, ce qui correspond à un déploiement de type installateur dans le cluster. Le second passe par le chart Helm, dont la dernière version publiée porte le tag helm-chart-1.1.5, daté du 18 avril 2025, tandis que la version applicative v4.1.3 est datée du 24 mars 2025.

La configuration se fait par un fichier de valeurs du chart, où les composants optionnels s'activent individuellement. Le README renvoie à la page d'installation de la documentation v4.1 pour la procédure détaillée, et ne reproduit pas les clés de configuration dans le texte fourni. Je ne peux donc pas citer ici les noms exacts des clés d'activation sans risquer d'inventer. Ce que le matériel confirme, c'est le principe : une installation de base, puis des extensions activées une à une, avec la possibilité de déployer en mode air-gapped, c'est-à-dire sans accès Internet, ce que le README mentionne explicitement pour le provisionnement de clusters.

Le fait que le chart et l'application aient des numéros de version distincts, 1.1.5 contre 4.1.3, est un détail qui compte en exploitation : votre outillage doit suivre deux numérotations séparées.

Là où le modèle par extensions devient contraignant

Le revers du micro-noyau est le nombre de composants à faire cohabiter. Une plateforme complète signifie KubeSphere, Argo CD, Jenkins, Istio, la pile d'observabilité, KubeEdge si vous avez de la périphérie, et le stockage ou le réseau selon vos choix. Chacun a ses versions, ses ressources et ses propres exigences. Le README mentionne le support de GlusterFS, CephRBD, NFS et LocalPV, ainsi que des plugins CSI pour consommer du stockage de plusieurs fournisseurs cloud, et le support de Calico, Flannel et Kube-OVN côté réseau. Autant de décisions à prendre avant le premier déploiement.

KubeSphere est aussi le mauvais outil dans plusieurs cas identifiables. Si vous n'avez qu'un seul cluster et que votre besoin se limite à kubectl et à un pipeline, la plateforme ajoute une couche d'administration sans contrepartie. Si votre organisation impose une pile d'observabilité déjà standardisée, remplacer celle-ci par celle de KubeSphere crée un doublon. Et si vous cherchez un produit avec un support commercial éditeur unique pour l'ensemble des briques, cette architecture par intégration rend la chose plus difficile à obtenir, puisque les composants sous-jacents vivent leurs propres vies.

Un dernier point, plus prosaïque : la licence. Le dépôt porte la mention NOASSERTION, ce qui signifie que GitHub n'a pas su rattacher le fichier de licence à un identifiant SPDX connu. Ce n'est pas la même chose qu'une absence de licence, mais cela veut dire qu'il faut lire le fichier vous-même avant tout usage en entreprise. Je ne peux pas en dire plus à partir des éléments fournis.

Face à un assemblage manuel de la pile

L'alternative la plus directe n'est pas un produit concurrent, c'est de ne pas prendre de plateforme du tout. Vous installez Kubernetes, puis vous ajoutez séparément un tableau de bord, un moteur GitOps comme Argo CD, une pile de métriques et de journaux, et vous écrivez vos propres politiques de cloisonnement. La différence n'est pas dans les composants, puisque KubeSphere s'appuie sur plusieurs des mêmes. Elle est dans ce qui est fourni au-dessus : console unique, espaces de travail, RBAC et quotas reliés entre eux, assistants de création de charges de travail, et une gestion de cycle de vie des applications Helm via l'App Store.

Autrement dit, l'assemblage manuel vous donne un contrôle total sur chaque version et chaque paramètre, au prix du travail d'intégration et de l'absence d'interface commune. KubeSphere vous donne cette interface et cette cohérence, au prix d'une dépendance à ses choix d'intégration et à son rythme de publication. Le compromis se joue là, pas sur des fonctionnalités isolées.

Coût de maintenance et de montée de version

Le rythme de publication observé est régulier : v4.1.3 en mars 2025, helm-chart-1.1.5 en avril 2025, avec des versions candidates avant les versions stables. Le dépôt n'est pas archivé et la dernière poussée connue est récente. Cela indique un projet actif, mais ne dit rien de la qualité, et il faut se garder de lire ces signaux comme une garantie.

Le vrai coût de maintenance vient du nombre de composants. Une montée de version de KubeSphere peut impliquer de valider la compatibilité d'Istio, d'Argo CD, de Jenkins et de la pile d'observabilité avec le noyau, en plus du chart lui-même. Les versions publiées séparément pour le chart et pour l'application ajoutent une étape de coordination. Sur un parc de plusieurs clusters, chaque montée doit être testée sur un cluster de recette avant d'être propagée, ce que la fonction de propagation d'applications rend possible mais ne rend pas gratuit.

Côté licence, la mention NOASSERTION impose une lecture directe du fichier avant adoption. Aucune conclusion juridique ne peut être tirée des seules métadonnées du dépôt.

Conclusion éditoriale

KubeSphere convient aux équipes qui exploitent plusieurs clusters Kubernetes, sur site ou en périphérie, et qui veulent une console unique avec multi-tenancy et RBAC déjà câblés, sans assembler elles-mêmes la pile. Il ne convient pas à celles qui cherchent un outil minimal à greffer sur un cluster unique, ni à celles qui refusent de dépendre d'un ensemble d'extensions dont la compatibilité mutuelle n'est pas documentée dans les éléments disponibles. Avant de vous engager, vérifiez deux points précis : dans le fichier de valeurs du chart, quels composants sont activés par défaut et lesquels vous devrez activer explicitement, puis la licence exacte du dépôt, dont le fichier porte la mention NOASSERTION et non un identifiant SPDX reconnu.

Sources officielles

1. Issues
2. kubesphere/kubesphere on GitHub
3. Project website
4. README
5. Releases