Concepts : architecture mutualisée dans Azure Kubernetes Service (AKS)

Lorsqu’ils répondent à la question « Comment configurer Kubernetes pour des environnements multilocataires ? », les architectes doivent d’abord comprendre les frontières conceptuelles et les modèles d’isolation disponibles. Le multi-tenant dans AKS consiste à exécuter plusieurs charges de travail isolées, relevant de différentes équipes, applications ou clients, sur un cluster Kubernetes partagé. Cet article détaille les concepts fondamentaux et les modèles architecturaux pour l’architecture multilocataire sur Azure Kubernetes Service (AKS).

Tip

Quels sont les trois modèles d’architecture mutualisée dans AKS ? L’architecture mutualisée dans AKS repose sur un spectre d’isolation comprenant trois modèles courants : l’isolation des espaces de noms, l’isolation des pools de nœuds et un cluster par locataire. L’isolation des espaces de noms convient le mieux aux équipes internes de confiance et à une efficacité des coûts maximale, l’isolation des pools de nœuds ajoute une séparation plus stricte des charges de travail avec une surcharge modérée, et un cluster par locataire offre l’isolation la plus forte pour les scénarios non fiables ou hautement réglementés.

Pour obtenir des instructions d’implémentation pas à pas et des manifestes YAML, consultez le guide complémentaire : Meilleures pratiques pour l’architecture mutualisée dans AKS.

Pourquoi une architecture mutualisée sur AKS ?

La mutualisation permet à plusieurs équipes, applications ou clients de partager un même cluster Kubernetes. La raison principale pour l’architecture mutualisée sur AKS est l’efficacité des coûts et l’échelle opérationnelle.

L’exécution d’un cluster dédié pour chaque application ou équipe entraîne une fragmentation significative des ressources, une capacité de calcul inactive et une surcharge de plan de contrôle multipliée. En regroupant des charges de travail dans des clusters multilocataires, les organisations optimisent l’utilisation des ressources et réduisent les dépenses cloud. Opérationnellement, l’architecture mutualisée réduit la taille de la flotte, ce qui signifie que les équipes de plateforme ont moins de clusters pour corriger, mettre à niveau, surveiller et sécuriser, ce qui simplifie la gestion du cycle de vie.

Quelle est la différence entre l’architecture mutualisée logicielle et l’architecture mutualisée physique ?

Kubernetes n’est pas par nature un système multilocataire. Pour mettre en œuvre la multi-location, vous devez concevoir un modèle d’isolation « soft » ou « hard » selon le niveau de confiance entre les différents locataires.

La différence entre la soft multi-tenancy et la hard multi-tenancy dans Kubernetes réside principalement dans le modèle de confiance et les exigences d’isolation qui en découlent. L’architecture mutualisée souple suppose des locataires internes de confiance et vise à prévenir les interférences involontaires au moyen de contrôles logiques tels que les espaces de noms, le contrôle d’accès basé sur les rôles (RBAC) et les quotas. La multitenance stricte suppose un niveau de confiance faible, voire nul, entre les locataires et nécessite des mécanismes d’isolation plus robustes afin de réduire le risque d’accès malveillant, de déplacement latéral et d’exposition de données.

Model	Niveau de confiance	Objectif	Cas d’utilisation	Exemples de scénarios
Architecture mutualisée logicielle	Confiance élevée entre les locataires internes	Empêcher les interférences accidentelles, la faim des ressources et les collisions de configuration	Environnements de plateforme interne où les équipes partagent l’infrastructure	Plusieurs équipes de produits d’une organisation partageant un cluster AKS pour les services de développement/test et internes
Architecture mutualisée physique	Confiance faible ou nulle entre les locataires	Empêcher les attaques malveillantes, le mouvement latéral et l’exfiltration des données	Hébergement de clients externes et charges de travail réglementées	Fournisseur SaaS hébergeant des charges de travail spécifiques au client où l’isolation du locataire est une exigence de sécurité et de conformité

Spectre d’isolation

L’architecture mutualisée sur AKS n’est pas un choix binaire ; elle existe sur un spectre. À mesure que vous progressez le long du spectre, l’isolation augmente, mais la complexité opérationnelle et le coût augmentent également. Ce continuum constitue l’ossature de la conception des clusters multilocataires :

• Isolation de l’espace de noms (logique) : les locataires partagent les mêmes pools de nœuds et le même plan de contrôle, mais sont séparés logiquement par les espaces de noms Kubernetes. C’est la base de l’architecture mutualisée logicielle.
• Isolation du pool de nœuds (informatique physique) : les clients partagent le plan de contrôle, mais se voient attribuer des nœuds de travail dédiés. Cela améliore la séparation des charges de travail et l’atténuation du phénomène de « voisin bruyant », mais cela ne constitue pas une isolation complète des locataires, car les composants du plan de contrôle et du cluster sont toujours partagés.
• Un cluster par locataire (entièrement physique) : les locataires sont complètement isolés, avec leur propre plan de contrôle AKS et leur propre plan de données. Il s’agit de la forme ultime d’architecture mutualisée physique, qui contourne effectivement le partage au niveau de Kubernetes au profit de l’isolation au niveau d’Azure.

Primitives AKS pour l’architecture mutualisée

AKS fournit un ensemble de primitives natives et intégrées à Azure pour mettre en œuvre les différents niveaux d’isolation.

• Microsoft Entra ID : fournit une gestion centralisée des identités et des accès pour authentifier les utilisateurs et les systèmes automatisés à l’API Kubernetes.
• Azure RBAC: associe les identités Microsoft Entra ID aux autorisations dans Kubernetes, garantissant que les locataires peuvent uniquement accéder aux ressources qui leur sont autorisées.
• Espaces de noms gérés : fournissent des limites logiques au sein du cluster pour regrouper les ressources des locataires, appliquer des quotas et définir la portée de l’accès.
• Azure Policy /Gatekeeper : applique des règles de conformité et de gouvernance centralisées sur le cluster pour empêcher les locataires de déployer des configurations non sécurisées ou non autorisées.
• Azure CNI : fournit une intégration de réseau virtuel native pour la mise en réseau AKS et prend en charge la segmentation du trafic client avec des contrôles de stratégie réseau. Le comportement d’adresse IP du pod dépend du mode CNI sélectionné (par exemple, superposition ou sous-réseau de pod).
• Azure Container Networking Services (ACNS) Cilium L7 : offre des stratégies réseau basées sur eBPF hautes performances et un filtrage du trafic de couche 7 pour isoler strictement le trafic réseau du locataire.
• Identité de la charge de travail : permet aux pods individuels de s’authentifier en toute sécurité auprès des services de Azure externes à l’aide de l’identité fédérée, ce qui élimine les secrets partagés entre les locataires.

Mappage des couches d’isolation entre les plans

Pour créer une architecture mutualisée sécurisée, vous devez appliquer les primitives AKS sur trois plans distincts de l’environnement de cluster.

Avion	Description	Primitives AKS appliquées
Plan de contrôle	Sécurisation de l’accès au serveur d’API Kubernetes et aux limites logiques.	Microsoft Entra ID, Azure RBAC, espaces de noms managés
Plan de données	Sécurisation du trafic réseau, de l’exécution du calcul et des limites au niveau du nœud.	Azure CNI, ACNS Cilium L7, Pools de nœuds
Plan de ressources	Gouvernance de la consommation de calcul, de l’accès externe et de la conformité de la configuration.	Azure Policy, identité de charge de travail

Quel modèle d’isolation devez-vous choisir ?

Utilisez la matrice suivante pour déterminer quel point sur le spectre d’isolation convient le mieux à vos besoins organisationnels.

Modèle d’isolation	Niveau de sécurité	Rentabilité	Complexité opérationnelle	Idéal pour
Espace de noms par locataire	Faible à moyen (logique)	Élevé (partage maximal)	Faible (cluster unique à gérer)	Équipes internes, environnements de développement/test, architecture multilocataire souple.
Pool de nœuds par locataire	Élevé (calcul isolé)	Moyen (plan de contrôle partagé)	Moyen (Gestion des taints/tolerations)	Charges de travail internes et externes nécessitant une isolation plus forte des ressources de calcul tout en partageant un plan de contrôle ; non adapté à un environnement mutualisé de confiance zéro hostile.
Cluster par locataire	Le plus élevé (physique)	Faible (forte surcharge)	Élevé (gestion de la flotte requise)	Environnement multitenant hostile, clients d’entreprise externes, zéro confiance.

Quand utiliser chaque modèle

• Utilisez un espace de noms par locataire lorsque les locataires sont internes ou de confiance, que l’efficacité des coûts est une priorité et que les contrôles d’isolation logique sont suffisants.
• Utilisez node-pool-per-tenant lorsque vous avez besoin d’une séparation de calcul plus forte et d’un impact de voisin bruyant réduit, tout en partageant un plan de contrôle AKS.
• Utilisez un cluster dédié par locataire lorsque les locataires ne sont pas fiables, que les contraintes réglementaires sont strictes ou que votre modèle de risque exige un minimum d’infrastructure partagée.

Étapes suivantes

Maintenant que vous comprenez les modèles conceptuels et les primitives pour l’architecture mutualisée, passez au guide d’implémentation pour appliquer ces concepts à votre cluster.

• Meilleures pratiques pour l’architecture mutualisée dans AKS

En somme

• Le mode multilocataire dans Azure Kubernetes Service (AKS) consiste à exécuter plusieurs charges de travail de différents locataires, isolées les unes des autres, sur une infrastructure Kubernetes partagée afin de réduire les coûts et de simplifier les opérations.
• L’espace de noms par locataire est le modèle le plus économique pour les charges de travail internes approuvées, car il optimise le partage d’infrastructure tout en appliquant des limites logiques.
• Pool de nœuds par locataire améliore la séparation de la capacité de calcul et le contrôle des voisins bruyants, mais il partage toujours le plan de contrôle AKS et d’autres composants au niveau du cluster.
• Le cluster par locataire offre l’isolation de locataire la plus forte pour les scénarios de confiance zéro et hautement réglementés, mais elle nécessite un coût plus élevé et une surcharge opérationnelle plus élevée.