Multi-tenancy Kubernetes : modèles, couches d'isolation et bonnes pratiques

TL;DR

• La multi-tenancy Kubernetes consiste à faire tourner plusieurs équipes, projets ou clients sur un même cluster partagé plutôt que sur un cluster dédié chacun — et rien dans l'isolation ne se fait automatiquement.
• Quatre couches fondamentales la font tenir : namespaces, RBAC, network policies et resource quotas (LimitRanges compris), auxquelles s'ajoutent les Pod Security Standards au niveau des workloads. Négligez-en une, et un tenant censé rester isolé commence à impacter tous les autres.
• Trois modèles d'isolation existent : soft (basé sur les namespaces, le moins cher, isolation purement logique), hard (clusters virtuels comme vCluster ou Capsule) et physique (node pools ou clusters dédiés, isolation la plus forte, coût le plus élevé). La plupart des organisations combinent les trois plutôt que d'en standardiser un seul.
• La plupart des échecs viennent de la dérive, pas d'une mauvaise configuration initiale : les équipes configurent correctement quotas et RBAC une fois, puis n'y reviennent jamais alors que les workloads évoluent.

Mettez dix équipes sur un même cluster Kubernetes et, par défaut, rien n'empêche l'équipe A de lire les secrets de l'équipe B, de consommer son CPU ou de faire tomber un control plane dont l'équipe B dépend aussi. La multi-tenancy Kubernetes comble cette faille grâce à quatre couches configurables : namespaces, RBAC, network policies et resource quotas.

La multi-tenancy permet aux organisations d'arrêter de payer des dizaines de control planes inutilisés et de partager l'infrastructure entre équipes, projets ou clients (les tenants). Elle ne fonctionne que si chacune de ces couches est réellement configurée — et le reste dans la durée. Kubernetes n'est pas multi-tenant d'origine. Les namespaces tracent une frontière logique, pas une frontière de sécurité. Omettez une couche, et un tenant censé rester isolé commence à impacter tout le monde sur le cluster, qu'il s'agisse d'une frontière de sécurité ou simplement d'un workload qui dévore le CPU d'un autre.

Pourquoi partager un cluster, au juste

Trois raisons reviennent dans presque tous les cas : le coût, la charge opérationnelle et la vélocité des développeurs.

Faire tourner dix clusters, c'est dix control planes, dix jeux de node pools surprovisionnés, dix load balancers qui tournent à vide la majeure partie de la journée. Consolider en deux ou trois clusters partagés réduit directement ce surcoût. La charge opérationnelle baisse aussi : un seul cluster à patcher, un seul endroit où surveiller la santé d'etcd, un seul jeu de politiques à garder cohérent, au lieu du même travail répété sur chaque cluster que vous exploitez.

La vélocité des développeurs compte tout autant, même si on la remarque moins. Une équipe qui attend qu'une équipe plateforme provisionne un nouveau cluster attend des jours. Une équipe qui demande un namespace sur un cluster multi-tenant existant peut l'obtenir en quelques minutes, en self-service, avec quotas et network policy déjà en place. Les équipes plateforme appellent cela le namespace-as-a-service, et c'est souvent la raison première pour laquelle elles mettent en place la multi-tenancy.

Les trois modèles de multi-tenancy

Tous les tenants n'ont pas besoin du même niveau d'isolation. Le modèle que vous choisissez arbitre entre rayon d'impact, coût et complexité opérationnelle que vous acceptez d'assumer.

La plupart des organisations ne choisissent pas un seul modèle une fois pour toutes. Elles utilisent la multi-tenancy soft pour les équipes internes de confiance, et réservent l'isolation hard ou physique à la poignée de tenants (un client externe, une équipe ML gourmande en GPU, un workload réglementé) qui en ont besoin. Traiter la multi-tenancy comme un simple interrupteur conduit à sur-dimensionner ou sous-dimensionner nombre de ces projets dès le départ.

Les couches d'isolation qui font tenir la multi-tenancy soft

La plupart des équipes commencent par la multi-tenancy soft, par défaut. Quatre couches la constituent, et il faut configurer chacune d'elles ; aucune n'est activée d'origine.

Les namespaces fournissent la frontière à laquelle tout le reste s'attache : un périmètre pour le RBAC, les quotas et les network policies. À eux seuls, ils isolent des noms, pas des comportements. Un pod du namespace A peut toujours communiquer avec un pod du namespace B, et un workload sans limites de ressources peut toujours saturer un nœud que les pods du namespace B utilisent aussi.

Le RBAC décide qui peut agir sur quoi. Partez d'un refus par défaut, accordez le strict minimum de rôles dont chaque équipe a réellement besoin, et liez les permissions à des groupes plutôt qu'à des utilisateurs individuels pour que les accès ne se dégradent pas au fil des arrivées et des départs. La prolifération du RBAC par tenant (des dizaines de Roles et RoleBindings quasi identiques qui se désynchronisent) figure parmi les principales raisons pour lesquelles les clusters multi-tenants deviennent de plus en plus difficiles à auditer.

Les NetworkPolicies empêchent les tenants de communiquer entre eux sur le réseau, ce que ni le RBAC ni les namespaces ne font seuls :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

La plupart des équipes commencent par une politique default-deny par namespace, puis ajoutent des règles d'autorisation explicites pour ce qui a réellement besoin de communiquer entre namespaces. Sans cela, n'importe quel pod du cluster peut atteindre n'importe quel autre pod par défaut. Les namespaces n'imposent aucune frontière réseau par eux-mêmes.

Les ResourceQuotas et LimitRanges empêchent un tenant d'affamer le reste du cluster en CPU, en mémoire ou en nombre d'objets. Un ResourceQuota plafonne ce qu'un namespace peut consommer au total ; un LimitRange fixe des valeurs par défaut et des maximums raisonnables par conteneur à l'intérieur. C'est exactement là que la multi-tenancy croise le problème du noisy neighbor : un quota ne protège le cluster que si les requests et limits qui le sous-tendent sont correctement définis, au plus près de l'usage réel. Des quotas trop laxistes n'arrêtent pas les noisy neighbors ; des quotas trop serrés poussent simplement les équipes à gonfler leurs demandes et gaspillent les économies de consolidation que la multi-tenancy promettait.

Les Pod Security Standards complètent le dispositif au niveau des workloads, en restreignant par namespace les conteneurs privilégiés, le host networking et l'accès root, afin qu'un attaquant qui compromet un pod chez un tenant ne puisse pas étendre l'attaque au nœud ou au reste du cluster.