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

Azure Kubernetes Service (AKS) simplifie le déploiement d'un cluster Kubernetes géré dans Azure en déchargeant la surcharge opérationnelle sur la plateforme de cloud Azure. En tant que service Kubernetes hébergé, Azure gère des tâches critiques telles que l’analyse de l’intégrité et la maintenance. La plateforme Azure gère le plan de contrôle AKS et vous ne payez que pour les nœuds AKS qui exécutent vos applications.

Les clusters AKS peuvent être partagés entre plusieurs locataires dans différents scénarios et de différentes façons. 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é, un pour chaque locataire. Tous ces types de partage sont fréquemment décrits à l’aide du terme multilocataire. Kubernetes n’a pas de concept de première classe pour les utilisateurs finaux ou les locataires. Toutefois, il fournit plusieurs fonctionnalités pour vous aider à gérer différentes exigences de location.

Dans cet article, nous décrivons certaines des caractéristiques d'AKS qui sont utiles lors de la construction de systèmes multilocataires. Pour obtenir des conseils généraux et des bonnes pratiques pour la multilocataire Kubernetes, consultez la documentation sur Multilocataire dans Kubernetes.

Types multilocataires

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

Plusieurs équipes

Une forme commune 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 sur d’autres plateformes d’hébergement.

De plus, 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 est hébergé dans le même cluster ou s’exécute en tant que services PaaS 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 pour leurs clients, qui sont considérés comme des locataires distincts. 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 souvent 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 s’assurer que les charges de travail sont fortement isolées les unes des autres.

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

Modèles d’isolation

Selon la documentation de Kubernetes, un cluster Kubernetes multilocataire est partagé par plusieurs utilisateurs et charges de travail, communément appelés locataires. Cette définition inclut des clusters Kubernetes partagés par différentes équipes ou divisions au sein d’une organisation. Il contient également des clusters qui sont partagés par des instances par client d'une application SaaS (Software-as-a-Service).

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

Lorsque plusieurs utilisateurs ou équipes partagent le même cluster avec un nombre fixe de nœuds, il est important qu’une équipe puisse utiliser plus que sa part de ressources équitable. Les quotas de ressources permettent aux administrateurs de résoudre ce problème.

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

• L’architecture mutualisée souple convient à 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é des charges 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 est utilisé pour décrire 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 Azure Kubernetes Service (AKS) multilocataire, vous devez tenir compte des couches d'isolation des ressources et de multi-location fournies par Kubernetes :

• Cluster
• Espace de noms
• Pool de nœuds ou nœud
• Pod
• Conteneur

En outre, vous devez tenir compte des implications en matière de sécurité du partage de différentes ressources entre plusieurs locataires. Par exemple, la planification de pods de différents locataires sur le même nœud peut réduire le nombre de machines nécessaires dans le cluster. D'autre part, vous pouvez avoir besoin d'empêcher la colocation de charges de travail spécifiques. Par exemple, vous pourriez ne pas autoriser l'exécution de code non fiable provenant de l'extérieur de votre organisation 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, il offre des fonctionnalités qui peuvent être suffisantes pour des cas d'utilisation spécifiques. Comme meilleure pratique, vous devriez séparer chaque locataire et ses ressources Kubernetes dans leurs espaces de noms. Vous pouvez ensuite utiliser le contrôle d'accès basé sur les rôles (RBAC) et les stratégies de réseau de Kubernetes pour appliquer l'isolation des locataires. Par exemple, l’illustration suivante montre le modèle de fournisseur SaaS classique qui héberge plusieurs instances de la même application sur le même cluster, une pour chaque locataire. Chaque application réside dans un espace de noms distinct.

Il existe plusieurs façons de concevoir et de créer des solutions mutualisées avec Azure Kubernetes Service (AKS). Chacune de ces méthodes est fournie avec son propre ensemble d’compromis, en termes de déploiement d’infrastructure, de topologie de réseau et de sécurité. Ces méthodes ont un impact sur 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 avoir d’impact sur les performances des applications d’autres locataires. Pour plus d’informations, consultez l’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 utilisée pour prendre en charge l’isolation des groupes de ressources au sein d’un seul cluster. Les espaces de noms peuvent être utilisés pour isoler les charges de travail client 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. Les é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 risque de chevauchement de noms.
• Les rôles RBAC et les liaisons de rôles sont des ressources délimitées à l’espace de noms que les équipes peuvent utiliser pour limiter les utilisateurs et les processus clients 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é.
• Les 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 partageant le même cluster sont fortement isolées d’une consommation de ressources système. Cette méthode peut s’assurer que chaque application cliente qui s’exécute dans un espace de noms distinct dispose des ressources dont elle a besoin pour s’exécuter et éviter les problèmes de voisin bruyant, ce qui peut affecter d’autres applications clientes qui partagent le même cluster.
• Les 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 de la mise en 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 par rapport au 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 d’accès
• 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 la section Isolation du plan de données dans la documentation Kubernetes.

Isolement réseau

Lorsque vous exécutez des applications modernes, basées sur des microservices dans Kubernetes, vous souhaitez la plupart du temps décider des 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 de réseau pour contrôler le flux de trafic. Une stratégie réseau est une spécification Kubernetes qui définit les stratégies d’accès concernant la communication entre les Pods. Vous pouvez utiliser des stratégies réseau pour séparer les communications entre les applications clientes qui partagent le même cluster.

Azure Kubernetes Service (AKS) fournit deux façons d’implémenter des stratégies réseau :

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

Ces deux implémentations appliquent les stratégies spécifiées à l’aide du logiciel Linux IPTables. Les stratégies de réseau sont traduites en ensembles de paires d'adresses IP autorisées et non autorisées. Ces paires sont ensuite programmées sous la forme de règles de filtre IPTable. Vous pouvez uniquement utiliser des stratégies réseau Azure avec des clusters AKS configurés avec le 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 la section Sécuriser le trafic entre les pods à l'aide de stratégies réseau dans Azure Kubernetes Service.

Pour plus d'informations, consultez la section Isolation du réseau dans la documentation Kubernetes.

Isolation du stockage

Azure fournit un ensemble complet de référentiels de données PaaS (Managed, Platform-as-a-Service), 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 s’exécutant 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 mutualisées.

Les charges de travail exécutées sur Azure Kubernetes Service (AKS) peuvent également utiliser des volumes persistants pour stocker des données. Sur Azure, vous pouvez créer des volumes persistants en tant que ressources Kubernetes sauvegardées par Stockage Azure. Vous pouvez créer manuellement des volumes de données et les affecter directement à des pods, ou vous pouvez les créer automatiquement à l’aide de revendications de volume persistant. AKS fournit des classes de stockage intégrées pour créer des volumes persistants soutenus par des disques Azure, des Azure Files et des Azure NetApp Files. Pour plus d'informations, consultez Options de stockage pour les applications dans Azure Kubernetes Service (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.

Lorsque les classes de stockage intégrées AKS ne conviennent pas à un ou plusieurs locataires, vous pouvez créer des classes de stockage personnalisées pour répondre aux différentes exigences des 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 étiquettes à n’importe quel volume persistant créé dans leur espace de noms pour facturer leurs coûts. Pour plus d'informations sur ce scénario, voir Utiliser les balises Azure dans le service Azure Kubernetes (AKS).

Pour plus d'informations, voir Isolation du stockage dans la documentation de Kubernetes.

Isolation des nœuds

Vous pouvez configurer les charges de travail des locataires pour qu'elles s'exécutent sur des nœuds d'agent distincts afin d'éviter le problème de voisins bruyants et de réduire le risque de divulgation d'informations. Dans AKS, vous pouvez créer un cluster séparé, ou simplement un pool de nœuds dédiés, pour les locataires qui ont des exigences strictes en matière d'isolation, de sécurité, de conformité réglementaire et de performance.

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

En général, AKS fournit l’isolation des charges de travail à différents niveaux :

• 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 le sandboxing pod basé sur des 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 du matériel, en exécutant des charges de travail de locataire sur des hôtes dédiés Azure qui garantissent que les machines virtuelles de nœud d’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 d’isolation supplémentaire pour les charges de travail des locataires.

Vous pouvez combiner ces techniques. Par exemple, vous pouvez exécuter des clusters et des pools de nœuds par locataire dans un groupe Azure Dedicated Host pour obtenir une séparation de charge de travail et une isolation physique au niveau matériel. Vous pouvez également créer des pools de nœuds partagés ou par locataire qui prennent en charge le chiffrement FIPS (Federal Information Process Standard),Machines Virtuelles confidentielles (CVM) ou le chiffrement basé sur l’hôte.

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

Pour plus d'informations, voir Isolation du nœud dans la documentation de Kubernetes.

Modèles de location

Azure Kubernetes Service (AKS) fournit davantage de types d’isolation de nœud et de modèles de location.

Déploiements automatisés à locataire unique

Dans un modèle de déploiement automatisé pour un seul locataire, vous déployez un ensemble de ressources dédiées 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 mutualisées créées à l’aide de ce modèle utilisent largement l’infrastructure en tant que code (IaC). Par exemple, Bicep, Azure Resource Manager, Terraform ou les API REST d’Azure Resource Manager permettent de lancer et de coordonner le déploiement à la demande de ressources dédiées au locataire. Vous pouvez utiliser cette approche lorsque vous devez fournir une infrastructure entièrement distincte pour chacun de vos clients. Lorsque vous planifiez votre déploiement, pensez à 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 qui appartiennent à 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 risquent pas d'affecter les performances de leurs systèmes respectifs, ce qui vous permet d'éviter le Problème des voisins bruyants. 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 du trafic non réglementé et à volume élevé sur le serveur d’API, peuvent entraîner une instabilité du cluster. Cette instabilité entraîne des échecs de demande, des délais d’expiration et des tempêtes de nouvelles tentatives d’API. La fonctionnalité sla de temps d’activité (contrat de niveau de service) vous permet d’effectuer un scale-out du plan de contrôle d’un cluster AKS pour répondre à la demande du trafic. Toutefois, l’approvisionnement d’un cluster dédié peut être une meilleure solution pour les clients ayant des exigences fortes en termes d’isolation des charges de travail.
• Les mises à jour et les modifications peuvent être déployées progressivement chez les locataires, ce qui réduit la probabilité d'une panne générale 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 en cours est susceptible d’être fastidieuse, car elle doit être répliquée sur plusieurs clusters AKS, un pour chaque locataire. Envisagez d'automatiser vos processus opérationnels et d'appliquer les changements progressivement dans vos environnements. Il serait utile que vous envisagiez également d'autres opérations de déploiement croisé, comme la création de rapports et l'analyse de l'ensemble de votre patrimoine. De même, assurez-vous de prévoir comment interroger et manipuler les données sur plusieurs déploiements.

Déploiements mutualisés complets

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’un seul ensemble d’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 moindre coût 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 tout référentiel de données partagé afin de maintenir le trafic généré par les ressources de tous les locataires, telles que les référentiels de données.

Risques :

• Dans ce contexte, une application unique 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 avoir un impact sur tous les locataires.
• Si le profil de trafic est hautement variable, vous devez configurer le programme de mise à l’échelle automatique du 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 explorer le nombre de requêtes en attente ou les métriques d’un système de messagerie externe qui utilise la mise à l’échelle automatique pilotée par les é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 les coûts Azure à des locataires individuels, en fonction de leur utilisation réelle. Les solutions tierces, 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 est souvent plus risqué, car les modifications apportées aux composants de l’infrastructure ou de l’application peuvent affecter l’ensemble de la clientèle.
• Vous devez également prendre en compte les limitations de mise à l’échelle. Vous risquez davantage d'atteindre les limites d'échelle des ressources Azure lorsque vous disposez d'un ensemble de ressources partagées. Pour éviter d’atteindre une limite de quota de ressources, vous pouvez envisager de 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 consiste à partager certains composants de solution sur tous les locataires et à déployer des ressources dédiées pour des locataires individuels. Par exemple, vous pouvez construire une seule application Kubernetes multilocataire, puis créer des bases de données individuelles, une pour chaque locataire, comme le montre cette illustration :

Avantages :

• Les déploiements partitionnés horizontalement peuvent vous aider à atténuer le problème de voisin bruyant. Considérez cette approche si vous avez identifié 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 des requêtes est élevée. Si un seul locataire envoie un grand nombre de requêtes à votre solution, les performances d’une base de données peuvent être affectées, mais les bases de données des autres locataires (et les composants partagés comme la couche application) ne sont pas affectées.

Risques :

• Avec un déploiement partitionné horizontalement, vous devez toujours envisager 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 se permettre de partager des ressources avec d’autres locataires, pour des raisons de conformité ou de stratégies internes.

Déploiements partitionnés verticalement

Vous pouvez tirer parti des avantages des modèles monolocataires et entièrement mutualisés à 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 par rapport aux 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 qui partagent un cluster et une base de données AKS sur une infrastructure mutualisée. Toutefois, vous pouvez également déployer des infrastructures monolocataires 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 dans 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 mutualisée avec différents niveaux de fonctionnalité à un coût différent. Votre modèle de tarification peut fournir plusieurs références SKU, chacune fournissant 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. Considérez les 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 partagées par tous les locataires de niveau De base.
• Niveau Standard : les demandes de locataires 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, 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 du locataire s'exécute dans un pool de nœuds dédié ou un cluster AKS afin de garantir un accord de niveau de service 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 d’agent utilisés pour héberger l’application cliente. Vous pouvez utiliser pod sandboxing comme solution alternative à l’utilisation de clusters dédiés ou de pools de nœuds pour isoler des charges de travail client 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.

De même, 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 différents accords de niveau de service pour les 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 %. Le contrat de niveau de service supérieur peut être mis en œuvre avec des services et des fonctionnalités qui déclenchent des objectifs de disponibilitéplus élevés.

Avantages :

• Puisque vous partagez toujours l'infrastructure, vous pouvez encore bénéficier de certains des avantages en termes de coûts des déploiements multilocataires 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 chère pour les nœuds d’agent. Cette approche garantit une meilleure densité et des économies. Pour les clients de niveau Premium, vous pouvez déployer des clusters AKS et des pools de nœuds avec une taille de machine virtuelle plus élevée et un nombre maximal de réplicas de pod et de nœuds à un prix plus élevé.
• Vous pouvez exécuter des services système, tels que CoreDNS, Konnectivity ou Azure Application Gateway Contrôleur d’entrée, dans un pool de nœuds en mode système dédié. Vous pouvez utiliser des teintes, des tolérances, des étiquettes de nœud, des sélecteurs de nœuds et une affinité de nœud pour exécuter une application cliente sur un ou plusieurs pools de nœuds en mode utilisateur.
• Vous pouvez utiliser des teintes, des tolérances, des étiquettes de nœud, des sélecteurs de nœuds et une 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é, avec 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 prévoyez d’autoriser la migration entre les infrastructures, vous devez réfléchir à la façon dont vous migrez les clients d’un déploiement mutualisé vers leur propre déploiement à locataire unique.
• Vous avez besoin d’une stratégie cohérente et d’un seul volet de verre (un point de vue) pour surveiller et gérer d’autres clusters AKS.

Mise à l’échelle automatique

Pour suivre la demande de trafic générée par les applications clientes, vous pouvez activer la mise à l’échelle automatique du cluster pour mettre à l’échelle les nœuds d’agent de votre Azure Kubernetes Service (AKS). La mise à l’échelle automatique permet aux systèmes de 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 de l’agent deviennent indisponibles en raison de pannes zonales.

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 éviter que les pods passent dans un état en attente, en raison d’une pénurie de ressources en termes de processeur et de mémoire.

De même, 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 automatiquement à l’échelle les pods en fonction des demandes de ressources. HpA (Horizontal Pod Autoscaler) met automatiquement à l’échelle le nombre de réplicas de pods, en fonction de l’utilisation du processeur/de la mémoire ou des métriques personnalisées. Avec la mise à l’échelle automatique pilotée par les événements Kubernetes (KEDA), vous pouvez piloter la mise à l’échelle de n’importe quel conteneur dans Kubernetes, en fonction du nombre d’événements de systèmes externes, tels que Azure Event Hubs ou Azure Service Bus, qui sont utilisés par les applications clientes.

Maintenance

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

Sécurité

Accès au cluster

Lorsque vous partagez un cluster AKS entre plusieurs équipes au sein d’une organisation, vous devez implémenter le principe du moindre privilège pour isoler différents locataires les 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, Flux, Argo CD ou d’autres types d’outils.

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

• Options d’accès et d’identité pour Azure Kubernetes Service (AKS)
• Intégration Microsoft Entra gérée par AKS
• Contrôler l’accès aux ressources de cluster à l’aide du contrôle d’accès en fonction du rôle Kubernetes et des identités Microsoft Entra dans Azure Kubernetes Service

Identité de charge de travail

Si vous hébergez plusieurs applications clientes sur un seul cluster AKS et que chacun se trouve dans un espace de noms distinct, chaque charge de travail doit utiliser un compte de service Kubernetes et des informations d’identification différents pour accéder aux services Azure en aval. Les comptes de service sont un des principaux types d’utilisateur 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, ce qui leur permet d'être utilisées par les pods autorisés pour communiquer avec le serveur API. La plupart des requêtes d’API fournissent un jeton d’authentification pour un compte de service ou un compte d’utilisateur normal.

Les charges de travail des locataires déployées sur les clusters AKS peuvent utiliser les informations d'identification des applications Microsoft Entra pour accéder aux ressources protégées par Microsoft Entra ID, comme Azure Key Vault et Microsoft Graph. Microsoft Entra Workload ID pour Kubernetes s’intègre aux fonctionnalités Kubernetes natives pour la fédération avec tous les fournisseurs d’identité externes.

Pod Sandboxing

AKS inclut un mécanisme appelé Pod Sandboxing qui fournit une limite d’isolation entre l’application conteneur et les ressources de noyau et de calcul partagées de l’hôte du conteneur, comme le processeur, la mémoire et la mise en réseau. Le Pod Sandboxing 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 gouvernance, comme 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).

Le déploiement d’applications sur des clusters ou des pools de nœuds distincts vous permet d’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 machines virtuelles partagés est plus efficace, par exemple, lorsque vous exécutez des pods non approuvés et approuvés sur le même nœud ou que vous co-localisez 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 clientes 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 pod sandboxing dans AKS peut exécuter n’importe quel conteneur non modifié à l’intérieur d’une limite de machine virtuelle de sécurité renforcée.

Pod Sandboxing sur AKS est basé sur des conteneurs Kata qui s’exécutent sur l’hôte de conteneur Linux Azure pour la pile AKS afin de fournir une isolation matérielle appliquée. Les conteneurs Kata sur AKS sont basés sur un hyperviseur Azure renforcé. L’isolation par pod est obtenue via une machine virtuelle Kata légère imbriquée qui utilise les ressources 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. Ce modèle vous permet de placer de nombreux conteneurs Kata dans une seule machine virtuelle invitée tout en continuant à exécuter des conteneurs dans la machine virtuelle parente. Le modèle fournit une limite d’isolation forte dans un cluster AKS partagé.

Pour plus d'informations, consultez les pages suivantes :

• Pod Sandboxing avec Azure Kubernetes Service (AKS)
• Prise en charge des conteneurs isolés de machine virtuelle Kata sur AKS pour Pod Sandboxing

Azure Dedicated Host

Azure Dedicated Host est un service qui fournit des serveurs physiques dédiés à un seul abonnement Azure et qui fournissent une isolation matérielle au niveau du serveur physique. Ces hôtes dédiés peuvent être provisionnés dans une région, une zone de disponibilité et un domaine d’erreur, et vous pouvez placer des machines virtuelles directement dans les hôtes provisionnés.

Vous pouvez obtenir plusieurs avantages en utilisant Azure Dedicated Host avec AKS, notamment les suivants :

• 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 d’isolation supplémentaire pour les charges de travail des locataires. Les hôtes dédiés sont déployés dans les mêmes centres de données et partagent les mêmes réseau et infrastructure de stockage sous-jacente que les autres hôtes non isolés.

• Azure Dedicated Host fournit un contrôle sur les é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 des locataires.

Azure Dedicated Host peut aider les fournisseurs SaaS à s’assurer que les applications clientes répondent aux exigences de conformité réglementaires, sectorielles et de gouvernance pour la sécurisation des informations sensibles. Pour plus d’informations, consultez Ajouter Azure Dedicated Host à un cluster Azure Kubernetes Service (AKS).

Machines virtuelles confidentielles

Vous pouvez utiliser des Machines Virtuelles confidentielles (CVM) pour ajouter un ou plusieurs pools de nœuds à votre cluster AKS afin de répondre aux exigences strictes en matière d’isolation, de confidentialité et de sécurité des locataires. Les CVM utilisent un environnement d'exécution de confiance (TEE) basé sur le matériel. AMD Secure Encrypted Virtualization : les machines virtuelles confidentielles SEV-SNP (Secure Nested Paging) refusent à l’hyperviseur et à d’autres codes de gestion de l’hôte l’accès à la mémoire et à l’état de la machine virtuelle, ajoutant une couche de protection approfondie contre l’accès des opérateurs. Pour plus d’informations, consultez Utiliser des machines virtuelles dans un cluster AKS.

FIPS (Federal Information Processing Standards)

FIPS 140-3 est une norme gouvernementale américaine qui définit les exigences de sécurité minimales pour les modules cryptographiques dans les produits et systèmes des technologies de l’information. En activant la 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. La 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 réglementaires et de conformité du secteur en utilisant des algorithmes et des mécanismes de chiffrement robustes. Azure fournit une documentation sur l’activation de 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.

ByOK (Bring Your Own Keys) 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 managé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 des disques de système d’exploitation et des disques de données pour vos clusters AKS. Pour plus d'informations, consultez les pages suivantes :

• BYOK avec des disques Azure dans AKS
• Chiffrement côté serveur de stockage sur disque Azure

Chiffrement basé sur l’hôte

Le chiffrement basé sur l’hôte sur AKS renforce davantage l’isolation, la confidentialité et la sécurité des charges de travail des locataires. Lorsque vous activez le chiffrement basé sur l’hôte, AKS chiffre les données au repos sur les ordinateurs hôtes sous-jacents, ce qui permet de s’assurer que les informations sensibles du locataire sont protégées contre tout accès non autorisé. Les disques temporaires et 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, le système d’exploitation et les disques 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 également chiffrés au repos avec des clés gérées par la plateforme. Vous pouvez spécifier votre propre clé de chiffrement à clé (KEK) pour chiffrer la clé de protection des données (DEK) à l’aide du chiffrement d’enveloppe, également appelé enveloppement. 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 les caches du système d'exploitation et du disque de données sont cryptées au repos avec des clés gérées par le client ou par la plateforme, en fonction du type de cryptage de disque sélectionné. Pour plus d'informations, consultez les pages suivantes :

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

Mise en réseau

Restreindre l'accès réseau au serveur API

Dans Kubernetes, le serveur API reçoit des demandes pour effectuer des actions dans le cluster, comme la création de ressources ou la mise à l'échelle du nombre de nœuds. Lors du partage d’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é

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 au sein de votre réseau virtuel. Dans un cluster AKS privé, le plan de contrôle ou le serveur API possède une adresse IP interne uniquement accessible via un point de terminaison privé Azure, situé dans le même réseau virtuel que le 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 Azure Kubernetes Service privé.

IPs autorisés

La deuxième option pour améliorer la sécurité du cluster et minimiser les attaques est l'utilisation d'IPs autorisées. Cette approche limite l’accès au plan de contrôle d’un cluster AKS public à une liste connue d’adresses IP (Internet Protocol) et au routage de Inter-Domain sans classe (CIDR). Lorsque vous utilisez des adresses IP autorisées, elles sont toujours exposées publiquement, mais l’accès est limité à un ensemble de plages d’adresses IP. Pour plus d’informations, consultez Sécuriser l’accès au serveur d’API à l’aide de plages d’adresses IP autorisées dans Azure Kubernetes Service (AKS).

Intégration de liaisons privées

Azure Private Link Service (PLS) est un composant d’infrastructure qui permet aux applications de se connecter en privé à un service via un point de terminaison privé Azure (PE) défini dans un réseau virtuel et connecté à la configuration IP frontale d’une instance Azure Load Balancer (ALB). Avec Azure 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 de données.

Vous pouvez utiliser Azure Private Link Service Integration 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 de point de terminaison public sur l’Internet public.

Pour obtenir des conseils généraux sur la façon de configurer Private Link pour une solution multilocataire hébergée par Azure, consultez Multilocataire et Azure Private Link.

Proxies inverses

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 :

• Nginx Ingress Controller 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.
• Le fournisseur d’entrée De Traefik Kubernetes 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.
• HaProxy Kubernetes Ingress Controller est encore un autre proxy inverse pour Kubernetes, qui prend en charge des fonctionnalités standard telles que l’arrêt TLS, le routage basé sur le chemin d’URL, etc.
• Azure Application Gateway Contrôleur d’entrée (AGIC) est une application Kubernetes, qui permet aux clients Azure Kubernetes Service (AKS) de tirer parti des Application Gateway natives d’Azure Équilibreur de charge L7, 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 une 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 se développer instantanément et se contracter 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 le contrôleur d’entrée Azure Application Gateway (AGIC), envisagez d’implémenter les meilleures pratiques suivantes :

• Configurez le Application Gateway utilisé par le contrôleur d’entrée pour la mise à l’échelle automatique. Avec la mise à l'échelle automatique activée, les SKUs Application Gateway et WAF v2 s'adaptent ou se réajustent, en fonction des exigences du trafic applicatif. Ce mode offre une meilleure élasticité à votre application et vous évite de devoir estimer la taille d'Application Gateway ou le nombre d'instances. Ce mode vous permet également de réaliser des économies, en n'exigeant pas que la passerelle fonctionne à la capacité maximale prévue pour la charge de trafic maximale attendue. Vous devez spécifier un nombre minimum (et éventuellement maximum) d'instances.
• Envisagez de déployer plusieurs instances du contrôleur d’entrée (AGIC) Application Gateway, 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 la prise en charge de plusieurs espaces de noms pour répartir les applications de locataire sur plusieurs instances du contrôleur d’entrée (AGIC) Application Gateway.

Intégration avec Azure Front Door

Azure Front Door est un équilibreur de charge mondial de niveau 7 et le réseau de diffusion de contenu en nuage (CDN) moderne 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 des 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 exploiter lors de l’exposition d’applications multilocataires hébergées par AKS à l’Internet public.

Par exemple, vous pouvez utiliser une application mutualisée 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 arrêter les connexions SSL sur la périphérie et acheminer tout le trafic vers l’application mutualisée 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 la demande pour qu’il corresponde au nom de domaine de l’application back-end. L'en-tête original Host envoyé par le client est propagé à travers l'en-tête X-Forwarded-Host, et le code de l'application multilocataire peut utiliser cette information pour faire correspondre la demande entrante au bon locataire.

Azure Web Application Firewall (WAF), sur Azure Front Door, fournit une protection centralisée pour les applications web. Vous pouvez utiliser Azure WAF pour 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 Azure Private Link Service. Pour plus d'informations, consultez la section Connecter Azure Front Door Premium à un 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'épuiser les ports SNAT. Les ports SNAT génèrent des identificateurs uniques utilisés pour gérer des flux distincts initiés par des applications qui s’exécutent sur le même ensemble de ressources de calcul. En exécutant plusieurs applications clientes sur un cluster Azure Kubernetes Service (AKS) partagé, vous pouvez effectuer un nombre élevé 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 :

• Load Balancer public Azure : par défaut, AKS provisionne une référence SKU Standard Load Balancer à 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 IP publiques ne sont pas autorisées ou si des sauts supplémentaires sont nécessaires pour la sortie. Par défaut, le Load Balancer public est créé avec une adresse IP publique par défaut utilisée par les règles de trafic sortant. Les règles sortantes vous permettent de définir explicitement la traduction de l'adresse réseau source (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 de serveur principal. Si nécessaire, pour éviter l’épuisement des ports SNAT, vous pouvez configurer les règles de trafic sortant de l’équilibreur de charge public pour utiliser des adresses IP publiques supplémentaires. Pour plus d'informations, voir Utiliser l'adresse IP frontale d'un équilibreur de charge pour la sortie via les règles de sortie.
• 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. NAT Gateway autorise jusqu'à 64 512 flux de trafic sortant UDP et TCP par adresse IP publique, avec un maximum de 16 adresses IP. Pour éviter l’épuisement des ports SNAT lors de l’utilisation d’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 l’architecture mutualisée.
• Route définie par l'utilisateur (UDR) : Vous pouvez personnaliser la route de sortie d'un cluster AKS pour prendre en charge des scénarios de réseau personnalisés, tels que ceux qui interdisent les IP publiques et exigent que le cluster se trouve derrière une appliance virtuelle réseau (NVA). Lorsque vous configurez un cluster pour le routage défini par l’utilisateur, AKS ne configure pas automatiquement les chemins de sortie. Vous devez configurer la sortie vous-même. Par exemple, vous routez le trafic sortant via un Pare-feu Azure. Le cluster AKS doit être déployé dans un réseau virtuel existant, avec un sous-réseau qui a été préalablement configuré. Lorsque vous n'utilisez pas une architecture standard d'équilibreur de charge (SLB), vous devez établir une sortie explicite. Par conséquent, cette architecture nécessite l’envoi explicite du 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 de locataire qui s’exécutent sur un cluster AKS partagé et pour calculer les répartitions des coûts sur des espaces de noms individuels. Azure Monitor vous permet de surveiller la santé et les performances d'Azure Kubernetes Service (AKS). Elle comprend la collecte de journaux et de métriques, l'analyse de la télémétrie et la visualisation des données collectées, afin d'identifier les tendances et de configurer les alertes pour vous avertir de manière proactive des problèmes critiques. Vous pouvez activer Container insight pour développer cette surveillance.

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

Coûts

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, les organisations peuvent contrôler et optimiser les coûts de plusieurs façons. Il s'agit notamment d'outils Kubernetes natifs pour gérer et gouverner l'utilisation et la consommation des ressources, ainsi que pour surveiller et optimiser de manière proactive l'infrastructure sous-jacente. Lors du calcul des 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 facturer les frais aux locataires dépend du modèle de location adopté par votre solution. Des détails supplémentaires sont expliqués avec les modèles de location suivants :

• Multilocataire complet : lorsqu’une application multilocataire unique sert toutes les demandes de locataire, il vous incombe de suivre la consommation des ressources et le numéro de requêtes généré par chaque locataire. Vous facturez 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 dus au trafic réseau, aux adresses IP publiques, aux équilibreurs de charge, aux services de stockage, tels que les disques managés ou les fichiers Azure utilisés par la solution de locataire, etc. 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, voir 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 appliquées à un pool de nœuds sont appliquées à chaque nœud du pool et sont conservées lors des mises à niveau. Des balises sont également appliquées aux nouveaux nœuds qui sont ajoutés à un pool lors des opérations de scale-out. L'ajout d'une balise peut être utile pour les tâches telles que le suivi des stratégies ou l'estimation des coûts. Pour plus d’informations, consultez Ajout d’étiquettes à des 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 la sorte vont conserver les valeurs Kubernetes, même si vous les mettez à jour par la suite en utilisant une autre méthode. Lorsque des adresses IP publiques, des fichiers ou des disques sont supprimés par le biais de Kubernetes, toutes les balises définies par Kubernetes sont supprimées. Les balises définies sur ces ressources qui ne sont pas suivies par Kubernetes ne sont pas affecté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 un coût de cluster AKS. L’allocation de coûts peut être étendue à un déploiement, un service, une étiquette, un pod et un espace de noms, ce qui vous offre une flexibilité dans la façon dont vous facturez ou affichez des 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 mutualisée. 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 d’optimisation des coûts

Contributeurs

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

Auteur principal :

• Paul Salvatori | Ingénieur client principal, FastTrack for Azure

Autres contributeurs :

• John Downs | Ingénieur logiciel principal
• Ed Price | Responsable de programme senior
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
• Bohdan Cherchyk | Ingénieur client senior, FastTrack for Azure

Étapes suivantes

Consultez Ressources pour architectes et développeurs de solutions multilocataires.