Considérations relatives à Azure Kubernetes Service (AKS) pour l’architecture mutualisée

Azure Kubernetes Service (AKS) simplifie le déploiement d’un cluster Kubernetes managé dans Azure en déchargeant la surcharge opérationnelle sur la plateforme cloud Azure. Étant donné qu’AKS est un service Kubernetes hébergé, Azure gère des tâches critiques telles que la surveillance et la maintenance de l’intégrité et le plan de contrôle.

Les clusters AKS peuvent être partagés entre plusieurs locataires dans différents scénarios et méthodes. Dans certains cas, diverses applications peuvent s’exécuter dans le même cluster. Dans d’autres cas, plusieurs instances de la même application peuvent s’exécuter dans le même cluster partagé, une pour chaque locataire. Le terme multilocataire décrit fréquemment tous ces types de partage. Kubernetes n’a pas de concept de premier niveau pour les utilisateurs finaux ou les locataires. Néanmoins, il fournit plusieurs fonctionnalités pour vous aider à gérer différentes exigences de location.

Cet article décrit certaines des fonctionnalités d’AKS que vous pouvez utiliser lorsque vous créez des systèmes multilocataire. Pour obtenir des conseils généraux et des bonnes pratiques pour l’architecture mutualisée Kubernetes, consultez multilocataire dans la documentation Kubernetes.

Types multilocataires

La première étape pour déterminer comment partager un cluster AKS sur plusieurs locataires consiste à évaluer les modèles et outils disponibles à utiliser. En général, l’architecture multilocataire dans les clusters Kubernetes se trouve dans deux catégories principales, mais de nombreuses variantes sont toujours possibles. La documentation de Kubernetes décrit deux cas d’usage courants pour l’architecture mutualisée : plusieurs équipes et plusieurs clients.

Plusieurs équipes

Une forme courante de multilocataire consiste à partager un cluster entre plusieurs équipes au sein d’une organisation. Chaque équipe peut déployer, surveiller et exploiter une ou plusieurs solutions. Ces charges de travail doivent souvent communiquer entre elles et avec d’autres applications internes ou externes situées sur le même cluster ou d’autres plateformes d’hébergement.

En outre, ces charges de travail doivent communiquer avec des services, tels qu’une base de données relationnelle, un référentiel NoSQL ou un système de messagerie, qui sont hébergés dans le même cluster ou qui s’exécutent en tant que services PaaS (Platform as a Service) sur Azure.

Dans ce scénario, les membres des équipes ont souvent un accès direct aux ressources Kubernetes via des outils, tels que kubectl. Ou bien, les membres ont un accès indirect via des contrôleurs GitOps, tels que Flux et Argo CD, ou via d’autres types d’outils d’automatisation des mises en production.

Pour plus d’informations sur ce scénario, consultez plusieurs équipes dans la documentation Kubernetes.

Plusieurs clients

Une autre forme courante de multilocataire implique fréquemment un fournisseur saaS (software as a service). Ou, un fournisseur de services exécute plusieurs instances d’une charge de travail, qui sont considérées comme des locataires distincts, pour leurs clients. Dans ce scénario, les clients n’ont pas d’accès direct au cluster AKS, mais ils n’ont accès qu’à leur application. De plus, ils ne savent même pas que leur application s’exécute sur Kubernetes. L’optimisation des coûts est fréquemment un problème critique. Les fournisseurs de services utilisent des stratégies Kubernetes, telles que des quotas de ressources et des stratégies réseau , pour vous assurer que les charges de travail sont fortement isolées les unes des autres.

Pour plus d’informations sur ce scénario, consultez Plusieurs clients dans la documentation Kubernetes.

Modèles d’isolation

Selon la documentation Kubernetes, un cluster Kubernetes mutualisé est partagé par plusieurs utilisateurs et charges de travail communément appelés locataires . Cette définition inclut des clusters Kubernetes qui partagent différentes équipes ou divisions au sein d’une organisation. Il contient également des clusters qui sont des instances par client d’un partage d’applications SaaS.

L’architecture multilocataire de cluster est une alternative à la gestion de nombreux clusters dédiés à locataire unique. Les opérateurs d’un cluster Kubernetes mutualisé doivent isoler les locataires les uns des autres. Cette isolation réduit les dommages qu’un locataire compromis ou malveillant peut faire au cluster et à d’autres locataires.

Lorsque plusieurs utilisateurs ou équipes partagent le même cluster avec un nombre fixe de nœuds, une équipe peut utiliser plus que son partage équitable de ressources. Les administrateurs peuvent utiliser quotas de ressources pour résoudre ce problème.

En fonction du niveau de sécurité fourni par l’isolation, vous pouvez faire la distinction entre l’architecture multilocataire souple et dure.

• L’architecture mutualisée réversible est adaptée à une seule entreprise où les locataires sont des équipes ou des services différents qui se font confiance. Dans ce scénario, l’isolation vise à garantir l’intégrité de la charge de travail, à orchestrer les ressources de cluster entre différents groupes d’utilisateurs internes et à se défendre contre les attaques de sécurité possibles.
• Le multilocataire difficile décrit les scénarios où les locataires hétérogènes ne font pas confiance les uns aux autres, souvent du point de vue de la sécurité et du partage des ressources.

Lorsque vous envisagez de créer un cluster AKS multilocataire, vous devez prendre en compte les couches d’isolation des ressources et de mutualisation qui Kubernetes fournit, notamment :

• Grappe
• Namespace
• Pool de nœuds ou nœud
• Cosse
• Conteneur

En outre, vous devez prendre en compte les implications en matière de sécurité du partage de différentes ressources entre plusieurs locataires. Par exemple, vous pouvez réduire le nombre d’ordinateurs nécessaires dans le cluster en planifiant des pods provenant de différents locataires sur le même nœud. En revanche, vous devrez peut-être empêcher la colocalisation de charges de travail spécifiques. Par exemple, vous n’autorisez peut-être pas le code non approuvé de l’extérieur de votre organisation à s’exécuter sur le même nœud que les conteneurs qui traitent des informations sensibles.

Bien que Kubernetes ne puisse pas garantir une isolation parfaitement sécurisée entre les locataires, elle offre des fonctionnalités qui peuvent être suffisantes pour des cas d’usage spécifiques. En guise de meilleure pratique, vous devez séparer chaque locataire et ses ressources Kubernetes dans leurs espaces de noms. Vous pouvez ensuite utiliser contrôle d’accès en fonction du rôle Kubernetes (RBAC) et stratégies réseau pour appliquer l’isolation du locataire. Par exemple, le diagramme suivant montre le modèle de fournisseur SaaS classique qui héberge plusieurs instances de la même application sur le même cluster, un pour chaque locataire. Chaque application se trouve dans un espace de noms distinct.

Il existe plusieurs façons de concevoir et de créer des solutions mutualisées avec AKS. Chacune de ces méthodes est fournie avec son propre ensemble de compromis, en termes de déploiement d’infrastructure, de topologie de réseau et de sécurité. Ces méthodes affectent le niveau d’isolation, l’effort d’implémentation, la complexité opérationnelle et le coût. Vous pouvez appliquer l’isolation du locataire dans les plans de contrôle et de données, en fonction de vos besoins.

Isolation du plan de contrôle

Si vous avez une isolation au niveau du plan de contrôle, vous garantissez que différents locataires ne peuvent pas accéder ou affecter les ressources des autres, telles que les pods et les services. En outre, ils ne peuvent pas affecter les performances des applications d’autres locataires. Pour plus d’informations, consultez isolation du plan de contrôle dans la documentation Kubernetes. La meilleure façon d’implémenter l’isolation au niveau du plan de contrôle consiste à séparer la charge de travail de chaque locataire et ses ressources Kubernetes dans un espace de noms distinct.

Selon la documentation Kubernetes, un espace de noms est une abstraction que vous utilisez pour prendre en charge l’isolation des groupes de ressources au sein d’un seul cluster. Vous pouvez utiliser des espaces de noms pour isoler les charges de travail de locataire qui partagent un cluster Kubernetes.

• Les espaces de noms permettent aux charges de travail de locataire distinctes d’exister dans leur propre espace de travail virtuel, sans risque d’affecter le travail de l’autre. Des équipes distinctes au sein d’une organisation peuvent utiliser des espaces de noms pour isoler leurs projets les uns des autres, car elles peuvent utiliser les mêmes noms de ressources dans différents espaces de noms sans que les noms se chevauchent.
• rôles RBAC et les liaisons de rôle sont des ressources délimitées à l’espace de noms que les équipes peuvent utiliser pour limiter les utilisateurs clients et les processus pour accéder aux ressources et aux services uniquement dans leurs espaces de noms. Différentes équipes peuvent définir des rôles pour regrouper des listes d’autorisations ou de capacités sous un nom unique. Ils attribuent ensuite ces rôles aux comptes d’utilisateur et aux comptes de service pour s’assurer que seules les identités autorisées ont accès aux ressources d’un espace de noms donné.
• quotas de ressources pour le processeur et la mémoire sont des objets d’espace de noms. Teams peut les utiliser pour s’assurer que les charges de travail qui partagent le même cluster sont fortement isolées de la consommation des ressources système. Cette méthode peut s’assurer que chaque application locataire qui s’exécute dans un espace de noms distinct a les ressources dont elle a besoin pour s’exécuter et éviter problèmes de voisin bruyant, ce qui peut affecter d’autres applications client qui partagent le même cluster.
• stratégies réseau sont des objets d’espace de noms que les équipes peuvent adopter pour appliquer le trafic réseau autorisé pour une application cliente donnée. Vous pouvez utiliser des stratégies réseau pour séparer les charges de travail distinctes qui partagent le même cluster du point de vue réseau.
• Les applications d’équipe qui s’exécutent dans des espaces de noms distincts peuvent utiliser différents comptes de service pour accéder aux ressources au sein du même cluster, des applications externes ou des services managés.
• Utilisez des espaces de noms pour améliorer les performances au niveau du plan de contrôle. Si les charges de travail d’un cluster partagé sont organisées en plusieurs espaces de noms, l’API Kubernetes comporte moins d’éléments à rechercher lors de l’exécution des opérations. Cette organisation peut réduire la latence des appels sur le serveur d’API et augmenter le débit du plan de contrôle.

Pour plus d’informations sur l’isolation au niveau de l’espace de noms, consultez les ressources suivantes dans la documentation Kubernetes :

• espaces de noms
• contrôles Access
• quotas

Isolation du plan de données

L’isolation du plan de données garantit que les pods et les charges de travail de locataires distincts sont suffisamment isolés les uns des autres. Pour plus d’informations, consultez d’isolation du plan de données dans la documentation Kubernetes.

Isolation du réseau

Lorsque vous exécutez des applications modernes basées sur des microservices dans Kubernetes, vous souhaitez souvent contrôler les composants qui peuvent communiquer entre eux. Par défaut, tous les pods d’un cluster AKS peuvent envoyer et recevoir du trafic sans restrictions, y compris d’autres applications qui partagent le même cluster. Pour améliorer la sécurité, vous pouvez définir des règles réseau pour contrôler le flux de trafic. La stratégie réseau est une spécification Kubernetes qui définit les stratégies d’accès pour la communication entre les pods. Vous pouvez utiliser stratégies réseau pour séparer les communications entre les applications clientes qui partagent le même cluster.

AKS fournit deux façons d’implémenter des stratégies réseau :

• Azure a sa mise en œuvre pour les stratégies réseau, appelées stratégies réseau Azure.
• stratégies réseau Calico est une solution de sécurité réseau et de réseau open source fondée par Tigera.

Les deux implémentations utilisent des iptables Linux pour appliquer les stratégies spécifiées. Les stratégies réseau sont traduites en ensembles de paires IP autorisées et non autorisées. Ces paires sont ensuite programmées en tant que règles de filtre iptables. Vous pouvez uniquement utiliser des stratégies réseau Azure avec des clusters AKS configurés avec la plug-in réseau Azure CNI. Toutefois, les stratégies réseau Calico prennent en charge Azure CNI et kubenet. Pour plus d’informations, consultez Sécuriser le trafic entre les pods à l’aide de stratégies réseau dans Azure Kubernetes Service.

Pour plus d’informations, consultez d’isolation réseau dans la documentation Kubernetes.

Isolation du stockage

Azure fournit un ensemble complet de référentiels de données PaaS managés, tels que Azure SQL Database et Azure Cosmos DB et d’autres services de stockage que vous pouvez utiliser comme volumes persistants pour vos charges de travail. Les applications clientes qui s’exécutent sur un cluster AKS partagé peuvent partager une base de données ou un magasin de fichiers, ou utiliser un référentiel de données dédié et une ressource de stockage. Pour plus d’informations sur les différentes stratégies et approches de gestion des données dans un scénario multilocataire, consultez approches architecturales pour le stockage et les données dans des solutions multilocataires.

Les charges de travail qui s’exécutent sur AKS peuvent également utiliser des volumes persistants pour stocker des données. Sur Azure, vous pouvez créer volumes persistants en tant que ressources Kubernetes prise en charge par Stockage Azure. Vous pouvez créer manuellement des volumes de données et les affecter directement aux pods, ou vous pouvez les créer automatiquement à l’aide de revendications de volume persistantes. AKS fournit des classes de stockage intégrées pour créer des volumes persistants qui des disques Azure, azure Fileset prise en charge d’Azure NetApp Files. Pour plus d’informations, consultez options de stockage pour les applications dans AKS. Pour des raisons de sécurité et de résilience, vous devez éviter d’utiliser le stockage local sur les nœuds de l’agent via emptyDir et hostPath.

Quand AKS classes de stockage intégrées ne conviennent pas à un ou plusieurs locataires, vous pouvez créer des classes de stockage personnalisées pour répondre aux exigences des différents locataires. Ces exigences incluent la taille du volume, la référence SKU de stockage, un contrat de niveau de service (SLA), des stratégies de sauvegarde et le niveau tarifaire.

Par exemple, vous pouvez configurer une classe de stockage personnalisée pour chaque locataire. Vous pouvez ensuite l’utiliser pour appliquer des balises à n’importe quel volume persistant créé dans leur espace de noms pour facturer leurs coûts. Pour plus d’informations, consultez Utiliser des balises Azure dans AKS.

Pour plus d’informations, consultez d’isolation du stockage dans la documentation Kubernetes.

Isolation des nœuds

Vous pouvez configurer des charges de travail de locataire pour qu’elles s’exécutent sur des nœuds d’agent distincts afin d’éviter problèmes de voisin bruyant et de réduire le risque de divulgation d’informations. Dans AKS, vous pouvez créer un cluster distinct, ou simplement un pool de nœuds dédié, pour les locataires qui ont des exigences strictes pour l’isolation, la sécurité, la conformité réglementaire et les performances.

Vous pouvez utiliser teintes, tolérances, étiquettes de nœud, sélecteurs de nœuds et affinité de nœud pour limiter l’exécution des pods des locataires uniquement sur un ensemble particulier de nœuds ou de pools de nœuds.

En général, AKS fournit une isolation de charge de travail à différents niveaux, notamment :

• Au niveau du noyau, en exécutant des charges de travail de locataire dans des machines virtuelles légères sur des nœuds d’agent partagé et en utilisant pod sandboxing basé sur conteneurs Kata.
• Au niveau physique, en hébergeant des applications clientes sur des clusters dédiés ou des pools de nœuds.
• Au niveau matériel, en exécutant des charges de travail de locataire sur hôtes dédiés Azure qui garantissent que les machines virtuelles du nœud agent exécutent des machines physiques dédiées. L’isolation matérielle garantit qu’aucune autre machine virtuelle n’est placée sur les hôtes dédiés, ce qui fournit une couche supplémentaire d’isolation pour les charges de travail client.

Vous pouvez combiner ces techniques. Par exemple, vous pouvez exécuter des clusters et des pools de nœuds par locataire dans un groupe hôte dédié Azure pour obtenir la séparation des charges de travail et l’isolation physique au niveau du matériel. Vous pouvez également créer des pools de nœuds partagés ou par locataire qui prennent en chargeFederal Information Process Standard (FIPS), machines virtuelles confidentiellesou chiffrement basé sur l’hôte.

Utilisez l’isolation des nœuds pour associer et facturer facilement le coût d’un ensemble de nœuds ou de pool de nœuds à un seul locataire. Il est strictement lié au modèle de location adopté par votre solution.

Pour plus d’informations, consultez d’isolation de nœud dans la documentation Kubernetes.

Modèles de location

AKS fournit davantage de types d’isolation de nœud et de modèles de location.

Déploiements à locataire unique automatisés

Dans un modèle de déploiement à locataire unique automatisé, vous déployez un ensemble dédié de ressources pour chaque locataire, comme illustré dans cet exemple :

Chaque charge de travail de locataire s’exécute dans un cluster AKS dédié et accède à un ensemble distinct de ressources Azure. En règle générale, les solutions multilocataires que vous créez à l’aide de ce modèle utilisent largement infrastructure en tant que code (IaC). Par exemple, Bicep, Azure Resource Manager, Terraformou les API REST Azure Resource Manager permettent d’initier et de coordonner le déploiement à la demande de ressources dédiées au locataire. Vous pouvez utiliser cette approche lorsque vous devez provisionner une infrastructure entièrement distincte pour chacun de vos clients. Lors de la planification de votre déploiement, envisagez d’utiliser le modèle d’empreintes de déploiement .

avantages :

• L’un des principaux avantages de cette approche est que le serveur d’API de chaque cluster AKS client est distinct. Cette approche garantit une isolation complète entre les locataires d’un niveau de sécurité, de mise en réseau et de consommation des ressources. Un attaquant qui gère le contrôle d’un conteneur n’a accès qu’aux conteneurs et aux volumes montés appartenant à un seul locataire. Un modèle de location d’isolation complète est essentiel pour certains clients avec une surcharge de conformité réglementaire élevée.
• Les locataires ne sont pas susceptibles d’affecter les performances du système les uns des autres, de sorte que vous évitez problèmes de voisin bruyant. Cette considération inclut le trafic sur le serveur d’API. Le serveur d’API est un composant partagé et critique dans n’importe quel cluster Kubernetes. Les contrôleurs personnalisés, qui génèrent un trafic non réglementé et à volume élevé sur le serveur d’API, peuvent entraîner l’instabilité du cluster. Cette instabilité entraîne des échecs de requête, des délais d’attente et des tempêtes de nouvelles tentatives d’API. Utilisez la fonctionnalité contrat SLA de temps d’activité pour effectuer un scale-out du plan de contrôle d’un cluster AKS pour répondre à la demande de trafic. Toutefois, l’approvisionnement d’un cluster dédié peut être une meilleure solution pour ces clients ayant des exigences fortes en termes d’isolation des charges de travail.
• Vous pouvez déployer des mises à jour et des modifications progressivement entre les locataires, ce qui réduit la probabilité d’une panne à l’échelle du système. Les coûts Azure peuvent être facilement facturés aux locataires, car chaque ressource est utilisée par un seul locataire.

risques :

• L’efficacité des coûts est faible, car chaque locataire utilise un ensemble dédié de ressources.
• La maintenance continue est susceptible d’être longue, car vous devez répéter les activités de maintenance sur plusieurs clusters AKS, une pour chaque locataire. Envisagez d’automatiser vos processus opérationnels et d’appliquer progressivement des modifications dans vos environnements. D’autres opérations inter-déploiement, telles que la création de rapports et l’analytique dans l’ensemble de votre patrimoine, peuvent également être utiles. Veillez à planifier la façon d’interroger et de manipuler des données sur plusieurs déploiements.

Déploiements entièrement multilocataire

Dans un déploiement entièrement mutualisé, une application unique répond aux demandes de tous les locataires, et toutes les ressources Azure sont partagées, y compris le cluster AKS. Dans ce contexte, vous n’avez qu’une seule infrastructure à déployer, surveiller et gérer. Tous les locataires utilisent la ressource, comme illustré dans le diagramme suivant :

Avantages:

• Ce modèle est attrayant en raison du coût inférieur d’exploitation d’une solution avec des composants partagés. Lorsque vous utilisez ce modèle de location, vous devrez peut-être déployer un cluster AKS plus volumineux et adopter une référence SKU plus élevée pour n’importe quel référentiel de données partagé. Ces modifications aident à maintenir le trafic généré par toutes les ressources de tous les locataires, telles que les référentiels de données.

Risques:

• Dans ce contexte, une seule application gère toutes les demandes des locataires. Vous devez concevoir et implémenter des mesures de sécurité pour empêcher les locataires d’inonder l’application avec des appels. Ces appels peuvent ralentir l’ensemble du système et affecter tous les locataires.
• Si le profil de trafic est hautement variable, vous devez configurer l’autoscaler de cluster AKS pour varier le nombre de pods et de nœuds d’agent. Basez votre configuration sur l’utilisation des ressources système, comme le processeur et la mémoire. Vous pouvez également effectuer un scale-out et un scale-out dans le nombre de pods et de nœuds de cluster en fonction des métriques personnalisées. Par exemple, vous pouvez utiliser le nombre de requêtes en attente ou les métriques d’un système de messagerie externe qui utilise mise à l’échelle automatique basée sur des événements Kubernetes (KEDA).
• Veillez à séparer les données de chaque locataire et à implémenter des protections pour éviter les fuites de données entre différents locataires.
• Veillez à suivre et associer des coûts Azure à des locataires individuels, en fonction de leur utilisation réelle. Les solutions non-Microsoft, telles que kubecost, peuvent vous aider à calculer et à décomposer les coûts entre différentes équipes et locataires.
• La maintenance peut être plus simple avec un seul déploiement, car vous n’avez à mettre à jour qu’un seul ensemble de ressources Azure et à gérer une seule application. Toutefois, il peut également être plus risqué, car les modifications apportées aux composants d’infrastructure ou d’application peuvent affecter l’ensemble de la base de clients.
• Vous devez également prendre en compte les limitations de mise à l’échelle. Vous êtes plus susceptible d’atteindre les limites de mise à l’échelle des ressources Azure lorsque vous disposez d’un ensemble partagé de ressources. Pour éviter d’atteindre une limite de quota de ressources, vous pouvez distribuer vos locataires sur plusieurs abonnements Azure.

Déploiements partitionnés horizontalement

Vous pouvez également envisager de partitionner horizontalement votre application Kubernetes multilocataire. Cette approche partage certains composants de solution sur tous les locataires et déploie des ressources dédiées pour des locataires individuels. Par exemple, vous pouvez créer une application Kubernetes multilocataire unique, puis créer des bases de données individuelles, une pour chaque locataire, comme illustré dans cette illustration :

avantages :

• Les déploiements partitionnés horizontalement peuvent vous aider à atténuer les problèmes de voisins bruyants . Envisagez cette approche si vous identifiez que la majeure partie de la charge de trafic sur votre application Kubernetes est due à des composants spécifiques que vous pouvez déployer séparément, pour chaque locataire. Par exemple, vos bases de données peuvent absorber la majeure partie de la charge de votre système, car la charge de requête est élevée. Si un locataire unique envoie un grand nombre de requêtes à votre solution, les performances d’une base de données peuvent être affectées négativement, mais les bases de données et les composants partagés d’autres locataires, comme la couche Application, restent inchangées.

risques :

• Avec un déploiement partitionné horizontalement, vous devez toujours prendre en compte le déploiement et la gestion automatisés de vos composants, en particulier les composants utilisés par un seul locataire.
• Ce modèle peut ne pas fournir le niveau d’isolation requis pour les clients qui ne peuvent pas partager des ressources avec d’autres locataires pour des raisons de stratégie interne ou de conformité.

Déploiements partitionnés verticalement

Vous pouvez tirer parti des avantages des modèles monolocataires et entièrement multilocataires à l’aide d’un modèle hybride qui partitionne verticalement les locataires sur plusieurs clusters AKS ou pools de nœuds. Cette approche offre les avantages suivants sur les deux modèles de location précédents :

• Vous pouvez utiliser une combinaison de déploiements à locataire unique et multilocataires. Par exemple, vous pouvez avoir la plupart de vos clients partager un cluster et une base de données AKS sur une infrastructure mutualisée. Vous pouvez également déployer des infrastructures à locataire unique pour les clients qui nécessitent des performances et une isolation plus élevées.
• Vous pouvez déployer des locataires sur plusieurs clusters AKS régionaux, potentiellement avec différentes configurations. Cette technique est la plus efficace lorsque vous avez des locataires répartis entre différentes zones géographiques.

Vous pouvez implémenter différentes variantes de ce modèle de location. Par exemple, vous pouvez choisir d’offrir votre solution multilocataire avec différents niveaux de fonctionnalités à un coût différent. Votre modèle de tarification peut fournir plusieurs références SKU qui fournissent chacun un niveau incrémentiel de performances et d’isolation en termes de partage de ressources, de performances, de réseau et de séparation des données. Tenez compte des niveaux suivants :

• Niveau de base : les demandes de locataire sont traitées par une application Kubernetes multilocataire unique partagée avec d’autres locataires. Les données sont stockées dans une ou plusieurs bases de données que partagent tous les locataires de niveau De base.
• Niveau standard : les demandes de locataire sont traitées par une application Kubernetes dédiée qui s’exécute dans un espace de noms distinct, qui fournit des limites d’isolation en termes de sécurité, de mise en réseau et de consommation de ressources. Toutes les applications des locataires, une pour chaque locataire, partagent le même cluster AKS et le même pool de nœuds avec d’autres clients de niveau standard.
• Niveau Premium : l’application cliente s’exécute dans un pool de nœuds dédié ou un cluster AKS pour garantir un contrat SLA plus élevé, de meilleures performances et un degré d’isolation plus élevé. Ce niveau peut fournir un modèle de coût flexible en fonction du nombre et de la référence SKU des nœuds de l’agent qui hébergent l’application cliente. Vous pouvez utiliser sandboxing pod comme solution alternative aux clusters dédiés ou aux pools de nœuds pour isoler les charges de travail de locataire distinctes.

Le diagramme suivant montre un scénario dans lequel les locataires A et B s’exécutent sur un cluster AKS partagé, tandis que le locataire C s’exécute sur un cluster AKS distinct.

Le diagramme suivant montre un scénario dans lequel les locataires A et B s’exécutent sur le même pool de nœuds, tandis que le locataire C s’exécute sur un pool de nœuds dédié.

Ce modèle peut également proposer des contrats SLA différents pour différents niveaux. Par exemple, le niveau de base peut offrir une durée de fonctionnement de 99,9%, le niveau standard peut offrir une durée de fonctionnement de 99,95%, et le niveau Premium peut offrir 99,99% temps d’activité. Vous pouvez implémenter le contrat SLA supérieur à l’aide de services et de fonctionnalités qui permettent des cibles de disponibilité plus élevées.

avantages :

• Étant donné que vous partagez toujours l’infrastructure, vous pouvez toujours bénéficier de certains des avantages liés à l’utilisation de déploiements multilocataire partagés. Vous pouvez déployer des clusters et des pools de nœuds partagés entre plusieurs applications clientes de niveau de base et standard, qui utilisent une taille de machine virtuelle moins coûteuse pour les nœuds d’agent. Cette approche garantit une meilleure densité et des économies de coûts. Pour les clients de niveau Premium, vous pouvez déployer des clusters et des pools de nœuds AKS avec une taille de machine virtuelle supérieure et un nombre maximal de réplicas et de nœuds de pod à un prix plus élevé.
• Vous pouvez exécuter des services système, tels que CoreDNS, Konnectivityou contrôleur d’entrée Azure Application Gateway, dans un pool de nœuds en mode système dédié. Vous pouvez utiliser teintes, tolérances, étiquettes de nœud, sélecteurs de nœuds et affinité de nœud pour exécuter une application cliente sur un ou plusieurs pools de nœuds en mode utilisateur.
• Vous pouvez utiliser teintes, tolérances, étiquettes de nœud, sélecteurs de nœuds et affinité de nœud pour exécuter des ressources partagées. Par exemple, vous pouvez avoir un contrôleur d’entrée ou un système de messagerie sur un pool de nœuds dédié qui a une taille de machine virtuelle spécifique, des paramètres de mise à l’échelle automatique et une prise en charge des zones de disponibilité.

risques :

• Vous devez concevoir votre application Kubernetes pour prendre en charge les déploiements multilocataires et monolocataires.
• Si vous envisagez d’autoriser la migration entre les infrastructures, vous devez prendre en compte la façon dont vous migrez les clients d’un déploiement mutualisé vers leur propre déploiement monolocataire.
• Vous avez besoin d’une stratégie cohérente et d’un seul volet de verre, ou d’un point de vue, pour surveiller et gérer davantage de clusters AKS.

Mise à l’échelle automatique

Pour suivre la demande de trafic générée par les applications clientes, vous pouvez activer le mise à l’échelle automatique du cluster pour mettre à l’échelle les nœuds d’agent d’AKS. La mise à l’échelle automatique aide les systèmes à rester réactifs dans les circonstances suivantes :

• La charge du trafic augmente pendant des heures de travail ou des périodes spécifiques de l’année.
• Les charges lourdes partagées ou de locataire sont déployées sur un cluster.
• Les nœuds d’agent deviennent indisponibles en raison de pannes d’une zone de disponibilité.

Lorsque vous activez la mise à l’échelle automatique pour un pool de nœuds, vous spécifiez un nombre minimal et maximal de nœuds en fonction des tailles de charge de travail attendues. En configurant un nombre maximal de nœuds, vous pouvez garantir suffisamment d’espace pour tous les pods clients du cluster, quel que soit l’espace de noms dans lequel ils s’exécutent.

Lorsque le trafic augmente, la mise à l’échelle automatique du cluster ajoute de nouveaux nœuds d’agent pour empêcher les pods d’entrer dans un état en attente en raison de pénuries de ressources telles que le processeur et la mémoire.

Lorsque la charge diminue, la mise à l’échelle automatique du cluster diminue le nombre de nœuds d’agent dans un pool de nœuds en fonction des limites spécifiées, ce qui permet de réduire vos coûts opérationnels.

Vous pouvez utiliser la mise à l’échelle automatique des pods pour mettre à l’échelle automatiquement les pods en fonction des demandes de ressources. HorizontalPodAutoscaler met automatiquement à l’échelle le nombre de réplicas de pod en fonction de l’utilisation du processeur ou de la mémoire ou des métriques personnalisées. En utilisant KEDA, vous pouvez piloter la mise à l’échelle de n’importe quel conteneur dans Kubernetes en fonction du nombre d’événements provenant de systèmes externes, tels que Azure Event Hubs ou Azure Service Bus, que les applications clientes utilisent.

autoscaler de pod vertical (VPA) permet une gestion efficace des ressources pour les pods. En ajustant l’UC et la mémoire allouées aux pods, VPA vous aide à réduire le nombre de nœuds requis pour exécuter des applications clientes. Avoir moins de nœuds réduit le coût total de possession et vous aide à éviter problèmes de voisin bruyant.

Affectez groupes de réservations de capacité aux pools de nœuds afin de fournir une meilleure allocation et une isolation des ressources pour différents locataires.

Entretien

Pour réduire le risque de temps d’arrêt susceptibles d’affecter les applications clientes pendant les mises à niveau du cluster ou du pool de nœuds, planifiez akS maintenance planifiée pendant les heures creuses. Planifiez les fenêtres de maintenance hebdomadaire pour mettre à jour le plan de contrôle des clusters AKS qui exécutent des applications clientes et des pools de nœuds pour réduire l’impact de la charge de travail. Vous pouvez planifier une ou plusieurs fenêtres de maintenance hebdomadaires sur votre cluster en spécifiant un jour ou une plage horaire sur une journée spécifique. Toutes les opérations de maintenance se produisent pendant les fenêtres planifiées.

Sécurité

Les sections suivantes décrivent les meilleures pratiques de sécurité pour les solutions mutualisées avec AKS.

Accès au cluster

Lorsque vous partagez un cluster AKS entre plusieurs équipes au sein d’une organisation, vous devez implémenter le principe de de privilège minimum pour isoler différents locataires des uns des autres. En particulier, vous devez vous assurer que les utilisateurs n’ont accès qu’à leurs espaces de noms et ressources Kubernetes lors de l’utilisation d’outils tels que kubectl, Helm, Fluxou Argo CD.

Pour plus d’informations sur l’authentification et l’autorisation avec AKS, consultez les articles suivants :

• options d’accès et d’identité pour AKS
• d’intégration Microsoft Entra gérée par AKS
• contrôle d’accès en fonction du rôle Kubernetes avec l’ID Microsoft Entra dans AKS

Identité de la charge de travail

Si vous hébergez plusieurs applications clientes sur un seul cluster AKS et que chaque application se trouve dans un espace de noms distinct, chaque charge de travail doit utiliser un compte de service Kubernetes différent et des informations d’identification pour accéder aux services Azure en aval. Les comptes de service sont l’un des principaux types d’utilisateurs dans Kubernetes. L’API Kubernetes contient et gère les comptes de service. Les informations d’identification du compte de service sont stockées en tant que secrets Kubernetes, afin que les pods autorisés puissent les utiliser pour communiquer avec le serveur d’API. La plupart des demandes d’API fournissent un jeton d’authentification pour un compte de service ou un compte d’utilisateur normal.

Les charges de travail de locataire que vous déployez sur des clusters AKS peuvent utiliser les informations d’identification de l’application Microsoft Entra pour accéder aux ressources protégées par l’ID Microsoft Entra, telles qu’Azure Key Vault et Microsoft Graph. ID de charge de travail Microsoft Entra pour Kubernetes s’intègre aux fonctionnalités natives Kubernetes pour fédérer avec tous les fournisseurs d’identité externes.

Bac à sable de pod

AKS inclut un mécanisme appelé sandboxing pod qui fournit une limite d’isolation entre l’application conteneur et le noyau partagé et les ressources de calcul de l’hôte de conteneur, comme le processeur, la mémoire et la mise en réseau. Le sandboxing pod complète d’autres mesures de sécurité ou contrôles de protection des données pour aider les charges de travail des locataires à sécuriser les informations sensibles et à répondre aux exigences réglementaires, sectorielles ou de conformité de la gouvernance, telles que la norme PCI DSS (Payment Card Industry Data Security Standard), l’Organisation internationale de normalisation (ISO) 27001 et la loi HIPAA (Health Insurance Portability and Accountability Act).

En déployant des applications sur des clusters ou des pools de nœuds distincts, vous pouvez isoler fortement les charges de travail client de différentes équipes ou clients. L’utilisation de plusieurs clusters et pools de nœuds peut convenir aux exigences d’isolation de nombreuses organisations et solutions SaaS, mais il existe des scénarios dans lesquels un seul cluster avec des pools de nœuds de machine virtuelle partagée est plus efficace. Par exemple, vous pouvez utiliser un cluster unique lorsque vous exécutez des pods non approuvés et approuvés sur le même nœud ou colocalisez des DaemonSets et des conteneurs privilégiés sur le même nœud pour accélérer la communication locale et le regroupement fonctionnel. pod sandboxing peut vous aider à isoler fortement les applications client sur les mêmes nœuds de cluster sans avoir à exécuter ces charges de travail dans des clusters ou des pools de nœuds distincts. D’autres méthodes nécessitent de recompiler votre code ou de provoquer d’autres problèmes de compatibilité, mais le bac à sable pod dans AKS peut exécuter n’importe quel conteneur non modifié à l’intérieur d’une limite de machine virtuelle de sécurité améliorée.

Le bac à sable de pod sur AKS est basé sur conteneurs Kata qui s’exécutent sur l’hôte de conteneur Linux Azure pour AKS pile pour fournir une isolation matérielle appliquée. Les conteneurs Kata sur AKS reposent sur un hyperviseur Azure renforcé par la sécurité. Elle permet d’isoler chaque pod via une machine virtuelle Kata imbriquée et légère qui utilise des ressources à partir d’un nœud de machine virtuelle parente. Dans ce modèle, chaque pod Kata obtient son propre noyau dans une machine virtuelle invitée Kata imbriquée. Utilisez ce modèle pour placer de nombreux conteneurs Kata dans une seule machine virtuelle invitée tout en continuant à exécuter des conteneurs dans la machine virtuelle parente. Ce modèle fournit une limite d’isolation forte dans un cluster AKS partagé.

Pour plus d’informations, consultez :

• sandboxing pod avec AKS
• prise en charge des conteneurs isolés de machines virtuelles Kata sur AKS pour le bac à sable pod

Hôte dédié Azure

'hôte dédié Azure est un service qui fournit des serveurs physiques dédiés à un abonnement Azure unique et qui fournissent une isolation matérielle au niveau du serveur physique. Vous pouvez provisionner ces hôtes dédiés au sein d’une région, d’une zone de disponibilité et d’un domaine d’erreur, et placer des machines virtuelles directement dans les hôtes approvisionnés.

Il existe plusieurs avantages à l’utilisation d’Azure Dedicated Host avec AKS, notamment :

• L’isolation matérielle garantit qu’aucune autre machine virtuelle n’est placée sur les hôtes dédiés, ce qui fournit une couche supplémentaire d’isolation pour les charges de travail client. Les hôtes dédiés sont déployés dans les mêmes centres de données et partagent la même infrastructure de stockage réseau et sous-jacente que d’autres hôtes non isolés.

• L’hôte dédié Azure assure le contrôle des événements de maintenance lancés par la plateforme Azure. Vous pouvez choisir une fenêtre de maintenance pour réduire l’impact sur les services et garantir la disponibilité et la confidentialité des charges de travail de locataire.

L’hôte dédié Azure peut aider les fournisseurs SaaS à garantir que les applications clientes répondent aux exigences réglementaires, sectorielles et de conformité de gouvernance pour sécuriser les informations sensibles. Pour plus d’informations, consultez Ajouter un hôte dédié Azure à un cluster AKS.

Karpenter

Karpenter est un projet de gestion du cycle de vie des nœuds open source conçu pour Kubernetes. L’ajout de Karpenter à un cluster Kubernetes peut améliorer l’efficacité et le coût de l’exécution des charges de travail sur ce cluster. Karpenter surveille les pods que le planificateur Kubernetes marque comme non planifié. Il provisionne et gère dynamiquement les nœuds qui peuvent répondre aux exigences du pod.

Karpenter fournit un contrôle précis sur l’approvisionnement de nœuds et le placement des charges de travail dans un cluster managé. Ce contrôle améliore l’architecture multilocataire en optimisant l’allocation des ressources, en garantissant l’isolation entre les applications de chaque locataire et en réduisant les coûts opérationnels. Lorsque vous créez une solution mutualisée sur AKS, Karpenter fournit des fonctionnalités utiles pour vous aider à gérer diverses exigences d’application pour prendre en charge différents locataires. Par exemple, vous devrez peut-être exécuter des applications de locataires sur des pools de nœuds optimisés par GPU et d’autres pour s’exécuter sur des pools de nœuds à mémoire optimisée. Si votre application nécessite une faible latence pour le stockage, vous pouvez utiliser Karpenter pour indiquer qu’un pod nécessite un nœud qui s’exécute dans une zone de disponibilité spécifique afin de pouvoir colocaliser votre niveau de stockage et d’application.

AKS active le provisionnement automatique des nœuds sur les clusters AKS via Karpenter. La plupart des utilisateurs doivent utiliser le mode de provisionnement automatique de nœud pour activer Karpenter en tant que module complémentaire managé. Pour plus d’informations, consultez de provisionnement automatique de nœud . Si vous avez besoin d’une personnalisation plus avancée, vous pouvez choisir d’héberger karpenter auto-hôte. Pour plus d’informations, consultez le fournisseur AKS Karpenter.

Machines virtuelles confidentielles

Vous pouvez utiliser machines virtuelles confidentielles pour ajouter un ou plusieurs pools de nœuds à votre cluster AKS pour répondre aux exigences strictes d’isolation, de confidentialité et de sécurité des locataires. machines virtuelles confidentielles utiliser un environnement d’exécution approuvé basé sur le matériel. virtualisation AMD Secure Encrypted - Paging imbriquée sécurisée (SEV-SNP) machines virtuelles confidentielles refuse l’hyperviseur et d’autres accès au code de gestion de l’hôte à la mémoire et à l’état de la machine virtuelle, ce qui ajoute une couche de défense et de protection approfondie contre l’accès des opérateurs. Pour plus d’informations, consultez Utiliser des machines virtuelles confidentielles dans un cluster AKS.

Normes de processus d’information fédérales (FIPS)

FIPS 140-3 est une norme gouvernementale américaine qui définit les exigences de sécurité minimales pour les modules de chiffrement dans les produits et systèmes informatiques. En activant conformité FIPS pour les pools de nœuds AKS, vous pouvez améliorer l’isolation, la confidentialité et la sécurité de vos charges de travail de locataire. conformité fiPS garantit l’utilisation de modules de chiffrement validés pour le chiffrement, le hachage et d’autres opérations liées à la sécurité. Avec les pools de nœuds AKS compatibles FIPS, vous pouvez répondre aux exigences de conformité réglementaires et sectorielles en utilisant des algorithmes et mécanismes de chiffrement robustes. Azure fournit une documentation sur la façon d’activer FIPS pour les pools de nœuds AKS, ce qui vous permet de renforcer la posture de sécurité de vos environnements AKS multilocataires. Pour plus d’informations, consultez Activer FIPS pour les pools de nœuds AKS.

Apportez vos propres clés (BYOK) avec des disques Azure

Stockage Azure chiffre toutes les données d’un compte de stockage au repos, y compris le système d’exploitation et les disques de données d’un cluster AKS. Par défaut, les données sont chiffrées avec des clés gérées par Microsoft. Pour plus de contrôle sur les clés de chiffrement, vous pouvez fournir des clés gérées par le client à utiliser pour le chiffrement au repos du système d’exploitation et des disques de données de vos clusters AKS. Pour plus d’informations, consultez :

• BYOK avec des disques Azure dans AKS.
• chiffrement côté serveur du stockage disque Azure.

Chiffrement basé sur l’hôte

chiffrement basé sur l’hôte sur AKS renforce davantage l’isolation, la confidentialité et la sécurité des charges de travail client. Lorsque vous activez le chiffrement basé sur l’hôte, AKS chiffre les données au repos sur les machines hôtes sous-jacentes, ce qui permet de s’assurer que les informations de locataire sensibles sont protégées contre un accès non autorisé. Les disques temporaires et les disques de système d’exploitation éphémères sont chiffrés au repos avec des clés gérées par la plateforme lorsque vous activez le chiffrement de bout en bout.

Dans AKS, les disques de système d’exploitation et de données utilisent le chiffrement côté serveur avec des clés gérées par la plateforme par défaut. Les caches de ces disques sont chiffrés au repos avec des clés gérées par la plateforme. Vous pouvez spécifier votre propre clé de chiffrement de clé pour chiffrer la clé de protection des données à l’aide du chiffrement d’enveloppe, également appelé de création de package de restrictions. Le cache du système d’exploitation et des disques de données est également chiffré via le BYOK que vous spécifiez.

Le chiffrement basé sur l’hôte ajoute une couche de sécurité pour les environnements multilocataires. Les données de chaque locataire dans le système d’exploitation et les caches de disque de données sont chiffrées au repos avec des clés gérées par le client ou gérées par la plateforme, en fonction du type de chiffrement de disque sélectionné. Pour plus d’informations, consultez :

• chiffrement basé sur l’hôte sur akS
• BYOK avec des disques Azure dans AKS
• chiffrement côté serveur du stockage disque Azure

Réseautage

Les sections suivantes décrivent les meilleures pratiques de mise en réseau pour les solutions mutualisées avec AKS.

Restreindre l’accès réseau au serveur d’API

Dans Kubernetes, le serveur d’API reçoit des demandes d’exécution d’actions dans le cluster, telles que la création de ressources ou la mise à l’échelle du nombre de nœuds. Lorsque vous partagez un cluster AKS entre plusieurs équipes au sein d’une organisation, protégez l’accès au plan de contrôle à l’aide de l’une des solutions suivantes.

Clusters AKS privés

En utilisant un cluster AKS privé, vous pouvez vous assurer que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste dans votre réseau virtuel. Dans un cluster AKS privé, le plan de contrôle ou le serveur d’API a une adresse IP interne accessible uniquement via un point de terminaison privé Azure , qui se trouve dans le même réseau virtuel du cluster AKS. De même, toute machine virtuelle du même réseau virtuel peut communiquer en privé avec le plan de contrôle via le point de terminaison privé. Pour plus d’informations, consultez Créer un cluster AKS privé.

Plages d’adresses IP autorisées

La deuxième option pour améliorer la sécurité du cluster et réduire les attaques consiste à utiliser plages d’adresses IP autorisées. Cette approche limite l’accès au plan de contrôle d’un cluster AKS public à une liste bien connue d’adresses IP et de plages ciDR (Classless Inter-Domain Routing). Lorsque vous utilisez des adresses IP autorisées, elles sont toujours exposées publiquement, mais l’accès est limité à un ensemble de plages. Pour plus d’informations, consultez Sécuriser l’accès au serveur d’API à l’aide de plages d’adresses IP autorisées dans AKS.

Intégration de Private Link

service Azure Private Link est un composant d’infrastructure qui permet aux applications de se connecter en privé à un service via un point de terminaison privé Azure défini dans un réseau virtuel et connecté à la configuration IP frontale d’une instance Azure Load Balancer. Avec private Link, les fournisseurs de services peuvent fournir en toute sécurité leurs services à leurs locataires qui peuvent se connecter à partir d’Azure ou localement, sans risque d’exfiltration des données.

Vous pouvez utiliser 'intégration de service Private Link pour fournir aux locataires une connectivité privée à leurs charges de travail hébergées par AKS de manière sécurisée, sans avoir à exposer un point de terminaison public sur l’Internet public.

Pour plus d’informations sur la configuration de Private Link pour une solution mutualisée hébergée par Azure, consultez multilocataire et Private Link.

Proxys inversés

Un proxy inverse est un équilibreur de charge et une passerelle d’API généralement utilisée devant les applications clientes pour sécuriser, filtrer et distribuer des requêtes entrantes. Les proxys inverses populaires prennent en charge des fonctionnalités telles que l’équilibrage de charge, l’arrêt SSL et le routage de couche 7. Les proxys inverses sont généralement implémentés pour améliorer la sécurité, les performances et la fiabilité. Les proxys inverses populaires pour Kubernetes incluent les implémentations suivantes :

• contrôleur d’entrée NGINX est un serveur proxy inverse populaire qui prend en charge les fonctionnalités avancées, telles que l’équilibrage de charge, l’arrêt SSL et le routage de couche 7.
• fournisseur d’entrée Kubernetes Traefik est un contrôleur d’entrée Kubernetes qui peut être utilisé pour gérer l’accès aux services de cluster en prenant en charge la spécification d’entrée.
• contrôleur d’entrée Kubernetes HAProxy est encore un autre proxy inverse pour Kubernetes, qui prend en charge les fonctionnalités standard telles que l’arrêt TLS, le routage basé sur le chemin d’URL, etc.
• contrôleur d’entrée Azure Application Gateway (AGIC) est une application Kubernetes , ce qui permet aux clients AKS d’utiliser un équilibreur de charge Application Gateway L7 natif Azure pour exposer des applications clientes à l’Internet public ou en interne à d’autres systèmes qui s’exécutent dans un réseau virtuel.

Lorsque vous utilisez un proxy inverse hébergé par AKS pour sécuriser et gérer les requêtes entrantes vers plusieurs applications clientes, tenez compte des recommandations suivantes :

• Hébergez le proxy inverse sur un pool de nœuds dédié configuré pour utiliser une taille de machine virtuelle avec une bande passante réseau élevée et mise en réseau accélérée activée.
• Configurez le pool de nœuds qui héberge votre proxy inverse pour la mise à l’échelle automatique.
• Pour éviter une latence et des délais d’expiration accrus pour les applications clientes, définissez une stratégie de mise à l’échelle automatique afin que le nombre de pods de contrôleur d’entrée puisse développer et contracter instantanément pour correspondre aux fluctuations du trafic.
• Envisagez de partitionner le trafic entrant vers les applications clientes, sur plusieurs instances de votre contrôleur d’entrée, pour augmenter la scalabilité et le niveau de séparation.

Lorsque vous utilisez leazure Application Gateway Ingress Controller (AGIC) , envisagez d’implémenter les meilleures pratiques suivantes :

• Configurez le de passerelle d’application que le contrôleur d’entrée utilise pour mise à l’échelle automatique. Une fois la mise à l’échelle automatique activée, les références SKU v2 (WAF) v2 et passerelle d’application web sont mises à l’échelle en fonction des besoins en matière de trafic d’application. Ce mode offre une meilleure élasticité à votre application et élimine la nécessité de deviner la taille de la passerelle d’application ou le nombre d’instances. Ce mode vous permet également d’économiser sur les coûts en ne nécessitant pas que la passerelle s’exécute au niveau de la capacité de pointe provisionnée pour la charge maximale attendue du trafic. Vous devez spécifier un nombre d’instances minimal (et éventuellement maximum).
• Envisagez de déployer plusieurs instances de l'AGIC , chacune associée à une application gateway distincte, lorsque le nombre d’applications clientes dépasse la quantité maximale de sites . En supposant que chaque application cliente s’exécute dans un espace de noms dédié, utilisez plusieurs espaces de noms prennent en charge pour répartir les applications clientes sur plusieurs instances de l'AGIC.

Intégration à Azure Front Door

Azure Front Door est un équilibreur de charge global de couche 7 et un réseau de distribution de contenu cloud moderne (CDN) de Microsoft qui fournit un accès rapide, fiable et sécurisé entre les utilisateurs et les applications web dans le monde entier. Azure Front Door prend en charge les fonctionnalités telles que l’accélération des requêtes, l’arrêt SSL, la mise en cache des réponses, le waf à la périphérie, le routage basé sur l’URL, la réécriture et les redirections que vous pouvez utiliser lorsque vous exposez des applications multilocataires hébergées par AKS à l’Internet public.

Par exemple, vous pouvez utiliser une application multilocataire hébergée par AKS pour traiter toutes les demandes des clients. Dans ce contexte, vous pouvez utiliser Azure Front Door pour gérer plusieurs domaines personnalisés, un pour chaque locataire. Vous pouvez mettre fin aux connexions SSL sur la périphérie et acheminer tout le trafic vers l’application multilocataire hébergée par AKS configurée avec un nom d’hôte unique.

Vous pouvez configurer Azure Front Door pour modifier l’en-tête de l’hôte d’origine de requête pour qu’il corresponde au nom de domaine de l’application principale. L’en-tête de Host d’origine envoyé par le client est propagé via l’en-tête X-Forwarded-Host, et le code de l’application multilocataire peut utiliser ces informations pour mapper la requête entrante au client approprié.

de pare-feu d’applications web Azure, sur Azure Front Door, fournit une protection centralisée pour les applications web. Le Pare-feu d’applications web Azure peut vous aider à défendre les applications de locataire hébergées par AKS qui exposent un point de terminaison public sur Internet contre les attaques malveillantes.

Vous pouvez configurer Azure Front Door Premium pour vous connecter en privé à une ou plusieurs applications clientes qui s’exécutent sur un cluster AKS, via une origine d’équilibreur de charge interne, à l’aide de private Link. Pour plus d’informations, consultez Connecter Azure Front Door Premium à une origine d’équilibreur de charge interne avec Private Link.

Connexions sortantes

Lorsque les applications hébergées par AKS se connectent à un grand nombre de bases de données ou de services externes, le cluster risque d’épuisement des ports de traduction d’adresses réseau sources (SNAT). ports SNAT générer des identificateurs uniques utilisés pour gérer des flux distincts que les applications qui s’exécutent sur le même ensemble de ressources de calcul lancent. En exécutant plusieurs applications de locataire sur un cluster AKS partagé, vous pouvez effectuer un grand nombre d’appels sortants, ce qui peut entraîner un épuisement des ports SNAT. Un cluster AKS peut gérer les connexions sortantes de trois façons différentes :

• Azure Load Balancer: par défaut, AKS provisionne un équilibreur de charge SKU standard à configurer et à utiliser pour les connexions de sortie. Toutefois, la configuration par défaut peut ne pas répondre aux exigences de tous les scénarios si les adresses IP publiques ne sont pas autorisées ou si des tronçons supplémentaires sont requis pour la sortie. Par défaut, l’équilibreur de charge public est créé avec une adresse IP publique par défaut que les règles de trafic sortant utiliser. Les règles de trafic sortant vous permettent de définir explicitement SNAT pour un équilibreur de charge standard public. Cette configuration vous permet d’utiliser les adresses IP publiques de votre équilibreur de charge pour fournir une connectivité Internet sortante pour vos instances back-end. Si nécessaire, pour éviter épuisement des ports SNAT, vous pouvez configurer les règles de trafic sortant de l’équilibreur de charge public pour utiliser plus d’adresses IP publiques. Pour plus d’informations, consultez Utiliser l’adresse IP frontale d’un équilibreur de charge pour le trafic sortant via des règles de trafic sortant.
• passerelle NAT Azure: vous pouvez configurer un cluster AKS pour utiliser la passerelle NAT Azure pour acheminer le trafic de sortie à partir d’applications clientes. La passerelle NAT permet jusqu’à 64 512 flux de trafic UDP sortant et TCP par adresse IP publique, avec un maximum de 16 adresses IP. Pour éviter le risque d’épuisement des ports SNAT lorsque vous utilisez une passerelle NAT pour gérer les connexions sortantes à partir d’un cluster AKS, vous pouvez associer davantage d’adresses IP publiques ou un préfixe d’adresse IP publique à la passerelle. Pour plus d’informations, consultez considérations relatives à la passerelle NAT Azure pour lesmultilocataires.
• route définie par l’utilisateur (UDR): vous pouvez personnaliser l’itinéraire de sortie d’un cluster AKS pour prendre en charge les scénarios de réseau personnalisés, tels que ceux qui interdisent les adresses IP publiques et nécessitent que le cluster se trouve derrière une appliance virtuelle réseau (NVA). Lorsque vous configurez un cluster pour de routage défini par l’utilisateur, AKS ne configure pas automatiquement les chemins d’accès de sortie. Vous devez terminer la configuration de sortie. Par exemple, vous routez le trafic de sortie via un pare-feu Azure . Vous devez déployer le cluster AKS dans un réseau virtuel existant avec un sous-réseau que vous avez précédemment configuré. Lorsque vous n’utilisez pas d’architecture d’équilibreur de charge standard, vous devez établir une sortie explicite. Par conséquent, cette architecture nécessite d’envoyer explicitement le trafic de sortie à une appliance, comme un pare-feu, une passerelle ou un proxy. Ou bien, l’architecture permet à la traduction d’adresses réseau (NAT) d’être effectuée par une adresse IP publique affectée à l’équilibreur de charge ou à l’appliance standard.

Surveillance

Vous pouvez utiliser Azure Monitor et container Insights pour surveiller les applications clientes qui s’exécutent sur un cluster AKS partagé et calculer les répartitions des coûts sur des espaces de noms individuels. Utilisez Azure Monitor pour surveiller l’intégrité et les performances d’AKS. Il inclut la collecte de journaux et de métriques, l’analyse de télémétrie et les visualisations des données collectées pour identifier les tendances et configurer des alertes qui vous avertit de manière proactive des problèmes critiques. Vous pouvez activer container Insights pour développer cette surveillance.

Vous pouvez également adopter des outils open source, tels que Prometheus et Grafana, qui sont largement utilisés pour la supervision Kubernetes. Vous pouvez également adopter d’autres outils non-Microsoft pour la surveillance et l’observabilité.

Dépens

La gouvernance des coûts est le processus continu d’implémentation de stratégies pour contrôler les coûts. Dans le contexte Kubernetes, il existe plusieurs méthodes que les organisations peuvent utiliser pour contrôler et optimiser les coûts. Ces méthodes incluent l’utilisation d’outils Kubernetes natifs pour gérer et régir l’utilisation et la consommation des ressources et pour surveiller et optimiser de manière proactive l’infrastructure sous-jacente. Lorsque vous calculez les coûts par locataire, vous devez prendre en compte les coûts associés à toute ressource utilisée par une application cliente. L’approche que vous suivez pour rétrofacturer les frais aux locataires dépend du modèle de location que votre solution adopte. La liste suivante décrit plus en détail les modèles de location :

• Multilocataire complet : lorsqu’une application multilocataire unique répond à toutes les demandes de locataire, il est de votre responsabilité de suivre la consommation des ressources et le nombre de requêtes générées par chaque locataire. Vous chargez ensuite vos clients en conséquence.
• Cluster dédié : lorsqu’un cluster est dédié à un seul locataire, il est facile de facturer les coûts des ressources Azure au client. Le coût total de possession dépend de nombreux facteurs, notamment le nombre et la taille des machines virtuelles, les coûts réseau du trafic réseau, les adresses IP publiques, les équilibreurs de charge et les services de stockage, tels que les disques managés ou les fichiers Azure utilisés par la solution de locataire. Vous pouvez étiqueter un cluster AKS et ses ressources dans le groupe de ressources de nœud pour faciliter les opérations de facturation des coûts. Pour plus d’informations, consultez Ajouter des balises au cluster.
• Pool de nœuds dédié : vous pouvez appliquer une balise Azure à un pool de nœuds nouveau ou existant dédié à un seul locataire. Les balises sont appliquées à chaque nœud du pool de nœuds et sont conservées via des mises à niveau. Les balises sont également appliquées aux nouveaux nœuds ajoutés à un pool de nœuds pendant les opérations de scale-out. L’ajout d’une balise peut vous aider à effectuer des tâches telles que le suivi des stratégies ou la facturation des coûts. Pour plus d’informations, consultez Ajout de balises aux pools de nœuds.
• Autres ressources : vous pouvez utiliser des balises pour associer les coûts des ressources dédiées à un locataire donné. En particulier, vous pouvez baliser des adresses IP publiques, des fichiers et des disques à l’aide d’un manifeste Kubernetes. Les balises définies de cette façon conservent les valeurs Kubernetes, même si vous les mettez à jour ultérieurement à l’aide d’une autre méthode. Lorsque des adresses IP publiques, des fichiers ou des disques sont supprimés via Kubernetes, toutes les balises que Kubernetes définit sont supprimées. Les balises sur les ressources que Kubernetes ne suit pas restent inchangées. Pour plus d’informations, consultez Ajouter des balises à l’aide de Kubernetes.

Vous pouvez utiliser des outils open source, tels que KubeCost, pour surveiller et régir le coût d’un cluster AKS. Vous pouvez étendre l’allocation des coûts à un déploiement, un service, une étiquette, un pod et un espace de noms, ce qui vous offre une flexibilité quant à la façon dont vous rechargez ou affichez les utilisateurs du cluster. Pour plus d’informations, consultez Gouvernance des coûts avec Kubecost.

Pour plus d’informations sur la mesure, l’allocation et l’optimisation des coûts pour une application mutualisée, consultez approches architecturales pour la gestion des coûts et l’allocation dans une solution multilocataire. Pour obtenir des conseils généraux sur l’optimisation des coûts, consultez l’article Azure Well-Architected Framework, Vue d’ensemble du pilier Optimisation des coûts.

Gouvernance

Lorsque plusieurs locataires partagent la même infrastructure, la gestion de la confidentialité des données, la conformité et les exigences réglementaires peuvent devenir complexes. Vous devez implémenter des mesures de sécurité fortes et des stratégies de gouvernance des données. Les clusters AKS partagés présentent un risque plus élevé de violations de données, d’accès non autorisé et de non-conformité aux réglementations en matière de protection des données. Chaque locataire peut avoir des exigences uniques en matière de gouvernance des données et des stratégies de conformité, ce qui rend difficile la sécurité et la confidentialité des données.

Microsoft Defender pour conteneurs est une solution de sécurité de conteneur native dans le cloud qui fournit des fonctionnalités de détection et de protection des menaces pour les environnements Kubernetes. En utilisant Defender pour conteneurs, vous pouvez améliorer votre posture de gouvernance et de conformité des données lorsque vous hébergez plusieurs locataires dans un cluster Kubernetes. Utilisez Defender pour conteneurs pour protéger les données sensibles, détecter et répondre aux menaces en analysant le comportement des conteneurs et le trafic réseau et en répondant aux exigences réglementaires. Il fournit des fonctionnalités d’audit, la gestion des journaux et la génération de rapports pour démontrer la conformité aux organismes de réglementation et aux auditeurs.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Paolo Salvatori | Ingénieur client principal

Autres contributeurs :

• Bohdan Cherchyk | Ingénieur client senior
• John Downs | Ingénieur logiciel principal
• Chad Kittel | Ingénieur logiciel principal
• Arsenal Vladimirskiy | Ingénieur client principal

Ressource associée

• ressources pour les architectes et les développeurs de solutions multilocataires