Faire tourner plusieurs équipes ou plusieurs clients sur la même plateforme Kubernetes se résout à trois niveaux d’isolation distincts, chacun avec un coût opérationnel proportionnel à la force de l’isolation qu’il apporte. Aucun n’est gratuit : le choix se fait en fonction du niveau de confiance réel entre les tenants, pas d’une préférence technique abstraite.

Niveau 1 : namespaces + RBAC + ResourceQuota

Le modèle le plus léger sépare les tenants par namespace, avec RBAC pour restreindre qui peut agir où et ResourceQuota pour plafonner la consommation de chaque namespace. Le coût opérationnel est minimal (un cluster unique à opérer), mais l’isolation reste logicielle et partielle : tous les tenants partagent le même plan de contrôle Kubernetes, le même kube-apiserver, le même etcd, et une faille dans l’API server ou une NetworkPolicy mal configurée expose potentiellement tous les tenants à la fois.

# Isolation "soft" : RBAC + quota par namespace,
# mais le plan de contrôle reste partagé par tous les tenants
apiVersion: v1
kind: ResourceQuota
metadata:
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi

Ce niveau convient à des équipes internes qui se font mutuellement confiance : la séparation protège contre l’erreur (un déploiement mal configuré qui déborde sur les ressources d’une autre équipe), pas contre une intention malveillante.

Niveau 2 : vcluster, un plan de contrôle virtuel par tenant

vcluster fait tourner un serveur API Kubernetes virtuel complet par tenant, à l’intérieur d’un namespace du cluster hôte : chaque tenant croit disposer de son propre cluster (son propre datastore — une base SQLite embarquée par défaut, etcd n’étant qu’une option à activer — ses propres CRD, sa propre version de Kubernetes potentiellement différente), tout en partageant les nœuds physiques et le plan de données du cluster hôte.

# Chaque tenant obtient un plan de contrôle isolé,
# les workloads finissent quand même sur les mêmes nœuds physiques
vcluster create tenant-a --namespace vc-tenant-a

Ce niveau intermédiaire isole ce qui compte le plus en pratique (les CRD, les webhooks d’admission, les versions de Kubernetes) sans multiplier les nœuds physiques : un tenant peut installer ses propres CRD sans jamais entrer en conflit avec ceux d’un autre. Le compromis reste réel : les workloads de tenants différents continuent de partager les mêmes nœuds physiques, donc la même surface d’attaque au niveau kernel et la même contention de ressources sous-jacente, sans le niveau de garantie qu’apporte un vrai cluster séparé.

Niveau 3 : clusters physiquement séparés

L’isolation maximale attribue un cluster Kubernetes complet et distinct à chaque tenant, avec son propre plan de contrôle et ses propres nœuds physiques. Aucune ressource n’est partagée, ce qui élimine toute possibilité d’un tenant qui affecte un autre, que ce soit par erreur ou par malveillance.

# Chaque tenant a son propre cluster complet :
# aucune ressource, physique ou logique, n'est partagée
# → géré typiquement via un ApplicationSet ArgoCD par cluster,
#   voir l'article sur le GitOps à l'échelle

Le coût grimpe en conséquence : chaque cluster impose ses propres coûts de plan de contrôle (souvent facturé par le fournisseur cloud, indépendamment de la charge réelle), sa propre gestion de mises à jour de version, et une orchestration multi-cluster (voir l’article sur le GitOps à l’échelle) pour éviter que chaque cluster ne devienne une île gérée à la main.

Le critère qui décide : la confiance, pas la préférence technique

Le choix entre ces trois niveaux ne se pose pas d’abord en termes de fonctionnalités mais de niveau de confiance réel entre les tenants. Des équipes internes d’une même organisation, soumises aux mêmes contraintes de conformité, se contentent souvent du niveau 1. Des clients externes payants, avec des exigences de conformité distinctes (santé, finance) ou une méfiance mutuelle justifiée, réclament généralement le niveau 3, quel qu’en soit le coût. vcluster occupe le terrain intermédiaire : suffisant quand l’isolation logicielle du niveau 1 est jugée insuffisante, mais où le coût du niveau 3 reste disproportionné par rapport au risque réel.

À retenir

La multi-tenancy Kubernetes se résout à trois niveaux d’isolation croissante : namespaces + RBAC + ResourceQuota (léger, isolation logicielle partagée), vcluster (plan de contrôle virtuel isolé, nœuds physiques partagés), clusters séparés (isolation totale, coût opérationnel maximal). Le critère de choix est le niveau de confiance réel entre tenants, pas une préférence d’architecture : une isolation plus forte que nécessaire coûte cher sans bénéfice réel, une isolation plus faible que nécessaire expose à un risque qui ne se révèle qu’à l’incident, un arbitrage central dès qu’une migration Kubernetes doit accueillir plusieurs équipes ou plusieurs clients sur la même plateforme.