vCluster : des clusters Kubernetes virtuels pour le multi-tenant

Le réflexe pour isoler deux équipes sur un cluster Kubernetes, c'est un namespace chacune. Et ça tient jusqu'au jour où une équipe veut installer une CRD, l'autre une version différente d'un opérateur, et une troisième un webhook d'admission global. Là, le namespace montre sa vraie nature : c'est une cloison logique à l'intérieur d'un seul plan de contrôle partagé. Les Custom Resource Definitions sont à l'échelle du cluster, pas du namespace. Les webhooks d'admission s'appliquent à tout le monde. Le RBAC fuit dès qu'une équipe a besoin d'un droit cluster-wide. Et la version de Kubernetes est commune, donc personne ne teste une montée de version sans l'imposer aux autres. Le namespace isole les ressources applicatives, pas le control plane.

L'alternative classique, c'est un cluster complet par équipe. Isolation parfaite, mais facture qui explose : chaque cluster traîne son control plane, ses nœuds, son etcd, sa supervision, ses upgrades. Multiplié par le nombre d'équipes, ça devient un parc de clusters à opérer pour un usage qui ne le justifie pas. Entre le namespace qui n'isole pas assez et le cluster dédié qui coûte trop, il manquait un cran intermédiaire. C'est ce cran que comble vCluster.

vCluster, porté par vCluster Labs (ex-Loft Labs), fait tourner un control plane Kubernetes complet à l'intérieur d'un seul namespace du cluster hôte. Ce control plane virtuel embarque son propre API server, son controller manager et son magasin d'état. Du point de vue du tenant, c'est un vrai cluster Kubernetes : il a son endpoint, ses droits d'admin, ses CRD, sa version de Kubernetes. Il peut installer ce qu'il veut, déployer un opérateur, déclarer un webhook, sans toucher au cluster hôte ni aux autres tenants.

La pièce qui rend l'astuce viable, c'est le syncer. Les ressources de haut niveau (Deployments, StatefulSets, CRD) vivent uniquement dans le cluster virtuel et n'atteignent jamais l'API server de l'hôte. Mais un pod doit bien tourner quelque part sur du vrai matériel. Le syncer projette donc les ressources de bas niveau, les Pods, ConfigMaps, Secrets et Services, vers le namespace de l'hôte. L'ordonnanceur de l'hôte place ces pods sur ses nœuds, et le syncer maintient le pod virtuel et le pod hôte en miroir. Le tenant croit piloter ses propres nœuds ; en réalité il partage le pool de nœuds de l'hôte, et la couche basse reste invisible côté virtuel.

Par défaut, vCluster réutilise l'ordonnanceur de l'hôte pour économiser des ressources. Si un tenant a besoin de labels de nœuds, de taints, d'un ordonnanceur custom ou de drainer des nœuds, on active un ordonnanceur virtuel dédié. Et pour cloisonner le placement, on restreint un cluster virtuel à un sous-ensemble de nœuds de l'hôte via un sélecteur de labels.

Soyons précis, parce que c'est le point où les gens se font avoir. vCluster virtualise le control plane intégralement. La séparation est forte au niveau de l'API, du RBAC et des CRD : chaque tenant a son API server, sa version, ses droits, ses définitions de ressources personnalisées. Ça, les namespaces ne le donnent jamais. Un tenant peut être admin de son cluster virtuel sans avoir le moindre droit sur l'hôte. C'est précisément ce qui manque dans une isolation par namespace.

Mais l'isolation s'arrête au control plane. Tous les clusters virtuels tournent sur le même cluster hôte et schedulent leurs pods sur le même pool de nœuds partagé. Sans mécanisme supplémentaire, vCluster ne restreint pas le placement des pods. L'isolation réseau, l'isolation au niveau du nœud et les garanties de tenant fort demandent des briques en plus : NetworkPolicies, taints et affinités, ou des nœuds virtuels pour créer de vraies frontières de scheduling tout en partageant l'infrastructure sous-jacente. La règle qu'on applique : vCluster isole le plan de contrôle, pas le plan d'exécution. Pour du multi-tenant souple entre équipes de confiance, ça suffit largement. Pour du multi-tenant hostile entre clients qui ne se font pas confiance, il faut ajouter les couches d'isolation réseau et de scheduling, et là on rejoint les problématiques d'une politique d'admission avec OPA Gatekeeper.

Pour fixer le choix, voici comment se placent les niveaux d'isolation et leurs frontières.

Le namespace donne l'isolation la moins chère et la plus faible. Ressources applicatives cloisonnées, mais control plane, CRD, webhooks et version de Kubernetes partagés. Bon pour découper les workloads d'une même équipe ou d'équipes qui se coordonnent.

Le cluster virtuel donne un control plane par tenant pour un coût proche de celui d'un namespace, puisqu'il partage les nœuds de l'hôte. Chaque tenant a son API server, ses CRD, sa version, son admin. Bon pour le multi-tenant entre équipes, les environnements par équipe, et tout ce qui demande des droits cluster-wide sans cluster dédié.

Le cluster réel donne l'isolation maximale, control plane et nœuds dédiés, au prix d'un parc complet à opérer. Réservé à ce qui justifie vraiment la séparation physique : conformité stricte, charges critiques isolées, frontières de sécurité dures.

Trois usages où le calcul penche franchement en faveur des clusters virtuels.

La CI éphémère, d'abord. Un cluster virtuel se crée et se détruit en quelques secondes, le temps d'une pipeline. Chaque build ou chaque pull request tourne dans son cluster jetable, complètement isolé, sans le temps de provisioning ni le coût d'un cluster réel. À la fin, on supprime le namespace et tout disparaît. Pour tester un opérateur, une CRD ou une montée de version, c'est imbattable.

Les environnements par équipe, ensuite. Chaque équipe reçoit son cluster virtuel avec ses droits d'admin, installe ses outils, choisit ses versions, sans demander d'autorisation à la plateforme et sans risquer de casser les voisins. La plateforme opère un seul cluster hôte au lieu d'un par équipe.

Les démos et les environnements de dev, enfin. Un cluster virtuel par développeur ou par démo, isolé, à coût marginal, qu'on jette une fois l'usage terminé. Pas de cluster local à maintenir, pas de cluster réel à provisionner pour deux heures de test.

vCluster n'efface pas le partage du noyau. Les pods de tous les tenants tournent sur les mêmes nœuds physiques, donc une charge folle chez un tenant peut affecter les voisins si on n'a pas posé de quotas et de limites de ressources. Le syncer ajoute une couche : c'est une pièce de plus à comprendre quand on debug une projection de pod qui ne se fait pas. Et l'isolation réseau forte n'est pas gratuite, elle se construit avec les briques évoquées plus haut. vCluster déplace le curseur, il ne supprime pas le besoin de discipline opérationnelle.

Le verdict ops : dès qu'on a du multi-tenant entre équipes ou un besoin d'environnements jetables, vCluster est le bon niveau d'abstraction. Plus fort qu'un namespace, infiniment moins cher qu'un cluster dédié par tenant. On garde le cluster réel pour les frontières de sécurité dures et la conformité qui l'exige. Pour tout le reste du multi-tenant Kubernetes, c'est vCluster.

Pour cadrer vCluster dans une stratégie de plateforme plus large, voir notre guide sur la haute disponibilité d'un cluster Kubernetes, le retour terrain sur k3s en production, notre dossier PaaS interne multi-tenant et l'analyse platform engineering 2026.

• vCluster Architecture, documentation officielle : control plane virtuel, syncer, projection des pods vers l'hôte.
• What is vCluster? : définition, isolation au niveau control plane, cas d'usage.
• Solving Kubernetes Multi-Tenancy Challenges with vCluster : limites des namespaces, isolation API et RBAC, pool de nœuds partagé.
• Sync from host to virtual, documentation vCluster : ressources synchronisées, ordonnanceur, isolation du scheduling.