Base de référence AKS pour les clusters multirégions

Cette architecture décrit comment exécuter plusieurs instances d’un cluster Azure Kubernetes Service (AKS) à travers plusieurs régions dans une configuration active/active et hautement disponible.

Cette architecture repose sur l’architecture de référence AKS, point de départ recommandé par Microsoft pour une infrastructure AKS. La référence AKS détaille des fonctionnalités infrastructurelles telles que Microsoft Entra Workload ID, les restrictions d’entrée et de sortie, les limites de ressources et d’autres configurations d’infrastructure AKS sécurisée. Le présent document ne traite pas de ces détails infrastructurels. Nous vous recommandons de vous familiariser avec la base de référence d’AKS avant de passer au contenu relatif aux régions multiples.

Architecture

Téléchargez un fichier Visio de cette architecture.

Composants

De nombreux composants et services Azure sont utilisés dans cette architecture AKS multi-région. Seuls les composants uniques par rapport à cette architecture multicluster sont listés ici. Pour le reste, veuillez consulter l’architecture de référence d’AKS.

• Clusters AKS régionaux : plusieurs clusters AKS sont déployés, chacun dans une région Azure distincte. En période de fonctionnement normal, le trafic réseau est routé entre toutes les régions. Si une région cesse d’être disponible, le trafic est routé vers la région la plus proche de l’utilisateur qui a émis la requête.
• Réseaux hub-and-spoke régionaux : une paire de réseaux hub-and-spoke régionaux est déployée pour chaque instance régionale d’AKS. Les stratégies Azure Firewall Manager permettent de gérer les stratégies de pare-feu dans toutes les régions.
• Coffre de clés régional : Azure Key Vault est fourni dans chaque région. Les coffres de clés sont utilisés pour stocker les valeurs sensibles et les clés spécifiques au cluster AKS, ainsi que pour prendre en charge les services qui se trouvent dans cette région.
• Plusieurs espaces de travail pour les journaux : les espaces de travail régionaux de l'analytique des journaux d'activité sont utilisées pour stocker les métriques réseau et les journaux de diagnostic au niveau de la région. De plus, une instance partagée de Log Analytics permet de stocker les métriques et les journaux de diagnostic de toutes les instances d’AKS.
• Profil global Azure Front Door : Azure Front Door est utilisé pour équilibrer la charge et router le trafic vers une instance régionale d’Azure Application Gateway, qui se trouve devant chaque cluster AKS. Azure Front Door permet un routage global de couche 7, tous deux étant requis pour cette architecture.
• Registre de conteneurs global : les images conteneur de la charge de travail sont stockées dans un registre de conteneurs managé. Dans cette architecture, un seul registre de conteneurs Azure est utilisé pour toutes les instances de Kubernetes au sein du cluster. L’activation de la géoréplication pour Azure Container Registry permet de répliquer des images vers les régions Azure sélectionnées et de fournir un accès continu à ces images, même en cas de panne dans l’une d’entre elles.

Modèles de conception

Cette architecture utilise deux modèles de conception cloud :

• Des géodes (nœuds géographiques), où n’importe quelle région peut traiter n’importe quelle requête.
• Des empreintes de déploiement, où plusieurs copies indépendantes d’une application ou d’un composant d’application sont déployées à partir d’une seule source, comme un modèle de déploiement.

Considérations sur le modèle Géode

Au moment de sélectionner les régions dans lesquelles chaque cluster AKS sera déployé, envisagez celles qui sont proches du consommateur de la charge de travail ou de vos clients. De même, envisagez d’utiliser la réplication interrégion. Elle réplique de façon asynchrone ces applications et données dans d’autres régions Azure pour la protection de la récupération d’urgence. Même si votre cluster se développe jusqu’à s’étendre à plus de deux régions, continuez de planifier la réplication interrégion pour chaque paire de clusters AKS.

Dans chaque région, les nœuds des pools de nœuds AKS sont répartis sur plusieurs zones de disponibilité pour éviter les problèmes dus à des défaillances zonales. Les zones de disponibilité sont prises en charge dans un ensemble limité de régions, ce qui influence le placement des clusters régionaux. Pour plus d’informations sur AKS et les zones de disponibilité, notamment la liste des régions prises en charge, consultez Zones de disponibilité AKS.

Considérations relatives aux empreintes de déploiement

Lorsque vous gérez une solution AKS multirégion, vous déployez plusieurs clusters AKS sur plusieurs régions. Chacun de ces clusters est considéré comme une empreinte. S'il se produit une défaillance régionale, ou si vous avez besoin d'un renforcement de la capacité et/ou de la présence régionale pour vos clusters, il vous faudra peut-être créer une instance d’empreinte. Quand vous sélectionnez un processus de création et de gestion des empreintes de déploiement, tenez compte des points suivants :

• Sélectionnez une technologie compatible avec les définitions d’empreinte qui autorise une configuration généralisée. Par exemple, vous pourriez utiliser Bicep pour définir l’infrastructure en tant que code.
• Fournissez des valeurs spécifiques à l’instance à l’aide d’un mécanisme d’entrée pour le déploiement, par exemple des variables ou des fichiers de paramètres.
• Sélectionnez les outils qui permettent un déploiement flexible, renouvelable et idempotent.
• Dans une configuration d’empreinte de type actif/actif, tenez compte de la façon dont le trafic est équilibré entre chaque empreinte. Cette architecture utilise Azure Front Door pour l’équilibrage de charge global.
• Au fur et à mesure que des empreintes sont ajoutées et supprimées de la collection, tenez compte des problèmes de capacité et de coût.
• Déterminez comment gagner en visibilité et supervisez la collection d’empreintes sous forme d’une seule unité.

Chacun de ces éléments est détaillé avec des conseils spécifiques dans les sections suivantes.

La gestion de flotte

Cette solution représente une topologie multi-cluster et multirégion, sans l’inclusion d’un orchestrateur avancé pour traiter tous les clusters dans le cadre d’une flotte unifiée. Lorsque le nombre de clusters augmente, envisagez d’inscrire les membres dans Azure Kubernetes Fleet Manager pour une meilleure gestion à grande échelle des clusters participants. L’architecture d’infrastructure présentée ici ne change pas fondamentalement avec l’inscription dans Fleet Manager, mais les opérations de jour 2 et les activités similaires bénéficient d’un plan de contrôle qui peut cibler plusieurs clusters simultanément.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Déploiement et démarrage de clusters

Quand vous déployez plusieurs clusters Kubernetes dans des configurations hautement disponibles et distribuées géographiquement, considérez la somme de chaque cluster Kubernetes comme une unité couplée. Vous pouvez développer des stratégies basées sur du code pour automatiser les opérations de déploiement et de configuration et ainsi garantir que les instances Kubernetes sont toutes aussi homogènes que possible. Prenez en compte les stratégies de scale-out et de scale-in, notamment en ajoutant ou en supprimant d’autres clusters Kubernetes. Votre conception et votre plan de déploiement et de configuration doivent prendre en considération les pannes de zone de disponibilité et les défaillances régionales, entre autres scénarios courants.

Définition d’un cluster

Vous disposez de nombreuses options pour déployer un cluster Azure Kubernetes Service. Le portail Azure, l’interface Azure CLI et le module Azure PowerShell sont tous des choix convenables pour déployer des clusters AKS individuels ou non couplés. Cependant, ces méthodes peuvent poser des problèmes si vous travaillez avec un grand nombre de clusters AKS étroitement couplés. Par exemple, l’utilisation du portail Azure peut entraîner des erreurs de configuration si certaines étapes sont manquantes ou si des options de configuration ne sont pas disponibles. Le déploiement et la configuration de nombreux clusters à l’aide du portail sont des processus qui demandent du temps. Ils doivent être effectués au moment opportun et mobilisent toute l’attention d’un ou de plusieurs ingénieurs. Si vous utilisez Azure CLI ou Azure PowerShell, vous pouvez construire un processus reproductible et automatisé à l’aide des outils en ligne de commande. Cependant, la responsabilité de l’idempotence, du contrôle des échecs de déploiement et de la reprise après défaillance repose sur vous et sur les scripts que vous développez.

Quand vous utilisez plusieurs instances AKS, nous vous recommandons de prendre en compte les solutions IaC (infrastructure as code), comme Bicep, les modèles Azure Resource Manager ou Terraform. Les solutions IaC fournissent un déploiement automatisé, scalable et idempotent. Par exemple, vous pourriez utiliser un fichier Bicep pour les services partagés de la solution et un autre pour les clusters AKS et autres services régionaux. À l’aide de solutions IaC, vous pouvez définir une empreinte de déploiement avec des configurations généralisées, notamment pour le réseau, les autorisations et les diagnostics. Vous pouvez fournir un fichier de paramètres de déploiement avec des valeurs propres à une région. Avec une telle configuration, un seul modèle permet de déployer une empreinte quasiment identique dans n’importe quelle région.

Le coût de développement et de maintenance des ressources d’IaC (infrastructure as code) peut être élevé. Dans certains cas, par exemple lorsque le nombre d'instances AKS est très faible (à savoir, 2 ou 3) et constant, la définition de l’IaC peut présenter plus d’inconvénients que d’avantages. Dans les situations de ce genre, l’utilisation d’une approche plus impérative (par exemple avec des outils en ligne de commande) ou même d'une approche manuelle avec le portail Azure est acceptable.

Déploiement de cluster

Une fois que l’empreinte de cluster est définie, vous disposez de nombreuses options pour déployer des instances d’empreintes individuelles ou multiples. Nous vous recommandons d’utiliser une technologie d’intégration continue moderne telle que GitHub Actions ou Azure Pipelines. Les solutions de déploiement basées sur l’intégration continue présentent les avantages suivants :

• Déploiements basés sur du code, qui permettent d’ajouter et de supprimer des empreintes en utilisant du code
• Fonctionnalités de test intégrées
• Environnement intégré et fonctionnalités de préproduction
• Solutions intégrées de gestion des secrets
• Intégration avec le contrôle de code source, pour le code d’application et les scripts de déploiement et les modèles
• Journalisation et historique de déploiement
• Fonctionnalités de contrôle d’accès et d’audit, qui permettent de contrôler qui peut apporter des modifications, et dans quelles conditions

À mesure que de nouvelles empreintes sont ajoutées ou supprimées dans le cluster global, le pipeline de déploiement doit être mis à jour pour rester cohérent. Une approche consiste à déployer les ressources de chaque région comme une étape individuelle au sein d’un workflow GitHub Actions. Cette configuration est simple, chaque instance de cluster étant clairement définie dans le pipeline de déploiement. Cette configuration présente quelques contraintes administratives liées à l’ajout et à la suppression de clusters dans le déploiement.

Une autre option consiste à créer une logique métier pour créer des clusters à partir d’une liste de lieux souhaités ou d’autres points de données indicateurs. Par exemple, le pipeline de déploiement peut contenir une liste de régions souhaitées. L’une des étapes du pipeline peut ensuite consister à parcourir cette liste en boucle, en déployant un cluster dans chaque région de la liste. L’inconvénient de cette configuration réside dans la complexité de la généralisation du déploiement et dans le fait que chaque empreinte de cluster n’est pas explicitement détaillée dans le pipeline de déploiement. L’avantage est que tout ajout ou toute suppression d’empreintes de cluster dans le pipeline se transforme en une simple mise à jour de la liste des régions souhaitées.

De plus, la suppression d’une empreinte de cluster dans le pipeline de déploiement ne désactive pas toujours ses ressources. Selon votre solution de déploiement et sa configuration, vous aurez peut-être besoin de passer par une étape supplémentaire pour désactiver les instances AKS et autres ressources Azure. Envisagez d’utiliser des piles de déploiement pour activer la gestion de cycle de vie complète des ressources Azure, notamment le nettoyage lorsque vous n’en avez plus besoin.

Démarrage de cluster

Après le déploiement de chaque empreinte ou instance de Kubernetes, les composants de cluster tels que les contrôleurs d’entrée, les solutions d’identité et les composants de charge de travail doivent être déployés et configurés. Vous avez également besoin d'appliquer des stratégies de sécurité, d’accès et de gouvernance à l’ensemble du cluster.

À l’image du déploiement, ces configurations peuvent devenir difficiles à gérer manuellement sur plusieurs instances de Kubernetes. À la place, tenez compte des options suivantes pour la configuration et la stratégie à grande échelle.

GitOps

Au lieu de configurer manuellement les composants Kubernetes, il est recommandé d’utiliser des méthodes automatisées pour appliquer des configurations à un cluster Kubernetes, car ces configurations sont enregistrées dans un référentiel source. Ce processus est souvent appelé GitOps. Les solutions GitOps populaires pour Kubernetes incluent Flux et Argo CD. Par exemple, l’extension Flux pour AKS permet de démarrer automatiquement les clusters immédiatement après leur déploiement.

GitOps fait l’objet d’une présentation détaillée dans l’architecture de référence d’AKS. Par l’utilisation d’une approche GitOps pour la configuration, vous garantissez que chaque instance de Kubernetes est configurée de manière similaire, sans effort particulier. L'emploi d'un processus de configuration simplifié devient d'autant plus important que la taille de votre flotte augmente.

Azure Policy

Au fur et à mesure que plusieurs instances de Kubernetes sont ajoutées, les avantages de la gouvernance, de la conformité et de la configuration basées sur des stratégies augmentent. Les stratégies, et plus particulièrement celles d’Azure Policy, offrent une méthode centralisée et scalable de contrôle de cluster. Les avantages des stratégies AKS sont détaillés dans l’architecture de référence d’AKS.

Azure Policy doit être activé lors de la création des clusters AKS. Les initiatives doivent être assignées en mode Audit pour obtenir une visibilité sur la non-conformité. Vous pouvez également définir plus de politiques qui ne font pas partie des initiatives intégrées. Ces stratégies sont définies en mode Refus. Par exemple, une stratégie a été mise en place pour garantir que seules les images conteneur approuvées sont exécutées dans le cluster. Envisagez de créer vos propres initiatives personnalisées. Regroupez les stratégies applicables à votre charge de travail dans une seule affectation.

L’étendue de la stratégie fait référence à la cible de chaque stratégie et initiative de stratégie. Vous pourriez utiliser Bicep pour assigner des politiques au groupe de ressources dans lequel chaque cluster AKS est déployé. L’augmentation de l’empreinte du cluster global entraîne la création de nombreuses stratégies dupliquées. Vous pouvez également étendre les stratégies à un abonnement Azure ou à un groupe d’administration Azure. Cette méthode vous donne la possibilité d’appliquer un ensemble unique de stratégies à tous les clusters AKS dans l’étendue d’un abonnement ou à tous les abonnements trouvés sous un groupe d’administration.

Quand vous concevez une stratégie pour plusieurs clusters AKS, tenez compte des éléments suivants :

• Appliquez des stratégies qui doivent globalement concerner toutes les instances AKS à un groupe d’administration ou un abonnement.
• Placez chaque cluster régional dans son propre groupe de ressources, ce qui permet aux stratégies spécifiques à la région de s'appliquer à ce groupe de ressources.

Pour obtenir des informations utiles pour établir une stratégie de gestion des stratégies, consultez Organisation des ressources du Cloud Adoption Framework.

Déploiement de charge de travail

En plus de la configuration de l’instance d’AKS, tenez compte de la charge de travail déployée sur chaque instance ou empreinte régionale. Les pipelines ou solutions de déploiement ont besoin d'être configurés pour prendre en charge chaque empreinte régionale. Au fur et à mesure que des empreintes sont ajoutées au cluster global, le processus de déploiement doit être suffisamment étendu ou flexible pour prendre en charge les nouvelles instances régionales.

Tenez compte des éléments suivants au moment de la planification du déploiement d’une charge de travail.

• Généralisez le déploiement, par exemple avec un chart Helm, pour garantir l’utilisation d’une seule configuration de déploiement sur plusieurs empreintes de cluster.
• Utilisez un seul pipeline de déploiement continu configuré pour déployer la charge de travail sur toutes les empreintes de cluster.
• Fournissez les détails d’instance spécifiques à l’empreinte en tant que paramètres de déploiement.
• Tenez compte de la façon dont la journalisation des diagnostics d’application et le suivi distribué sont configurés pour une observabilité à l’échelle de l’application.

Disponibilité et basculement

La disponibilité du service est un argument important pour le choix d’une architecture Kubernetes multirégion. En d’autres termes, si un service ou un composant de service n’est plus disponible dans une région, le trafic doit être routé vers une région où une autre instance de ce service reste disponible. Une architecture multirégion comprend de nombreux points de défaillance différents. Dans cette section, chacun de ces points de défaillance potentiels est présenté.

Échecs de pods d’application

Un objet de déploiement Kubernetes permet de créer un ReplicaSet, qui gère plusieurs réplicas d’un pod. Si un pod n’est pas disponible, le trafic est routé parmi les autres. Le ReplicaSet Kubernetes tente de maintenir opérationnels le nombre spécifié de réplicas. Si une instance tombe en panne, une autre instance doit être automatiquement recréée. Des probes liveness peuvent être utilisées pour vérifier l’état de l’application ou du processus en cours d’exécution dans le pod. Si le service ne répond pas, la probe liveness supprime le pod, forçant ainsi le ReplicaSet à créer une autre instance.

Pour plus d’informations, consultez ReplicaSet Kubernetes.

Défaillances matérielles du centre de données

Une défaillance localisée peut parfois se produire. Par exemple, un seul rack de serveurs Azure peut être privé d'alimentation. Pour empêcher vos nœuds AKS de devenir un point de défaillance unique, utilisez les zones de disponibilité Azure. Par l’utilisation de zones de disponibilité, vous garantissez que les nœuds AKS d’une zone de disponibilité donnée sont physiquement séparés de ceux définis dans une autre zone de disponibilité.

Pour plus d’informations, consultez AKS et zones de disponibilité Azure.

Défaillances d'une région Azure

Quand une région entière cesse d’être disponible, les pods du cluster ne sont plus disponibles pour traiter les requêtes. Dans ce cas, Azure Front Door route l’ensemble du trafic vers les régions saines restantes. Les clusters et pods Kubernetes des régions saines continuent à traiter les requêtes.

Dans cette situation, veillez à compenser l’augmentation des requêtes et du trafic vers le cluster restant. Considérations importantes :

• Vérifiez que les ressources réseau et de calcul sont correctement dimensionnées pour absorber les augmentations soudaines de trafic dues au basculement d’une région. Par exemple, quand vous utilisez Azure CNI, vérifiez que vous disposez d’un sous-réseau suffisamment grand pour prendre en charge toutes les adresses IP de pods lorsqu'il se produit un pic de trafic.
• Utilisez l’Autoscaler de pods horizontaux pour augmenter le nombre de réplicas de pod afin de répondre à l’augmentation de la demande régionale.
• Utilisez l’Autoscaler de clusters AKS pour augmenter le nombre de nœuds d’instance Kubernetes afin de répondre à l’augmentation de la demande régionale.

Pour plus d’informations, consultez Mise à l’échelle automatique horizontale de pods et Mise à l’échelle automatique de clusters AKS.

Topologie du réseau

À l’image de l’architecture de référence d’AKS, cette architecture utilise une topologie réseau hub-and-spoke. En plus des considérations spécifiées dans l’architecture de référence d’AKS, tenez compte des meilleures pratiques suivantes :

• Implémentez un ensemble de réseaux virtuels hub-spoke pour chaque instance AKS régionale. Dans chaque région, appairez chaque spoke au réseau virtuel hub.
• Routez tout le trafic sortant via une instance du Pare-feu Azure située dans chaque réseau hub régional. Utilisez des stratégies Azure Firewall Manager pour gérer les stratégies de pare-feu dans toutes les régions.
• Suivez le dimensionnement IP décrit dans l'architecture de référence d'AKS, et autorisez des adresses IP supplémentaires pour les opérations de mise à l’échelle de nœuds et de pods en cas de défaillance régionale dans une autre région et d'augmentation considérable du trafic vers les régions restantes.

Gestion du trafic

Avec l’architecture de référence d’AKS, le trafic de la charge de travail est routé directement vers une instance d’Azure Application Gateway, avant d’être transféré vers l’équilibreur de charge du backend et les ressources d’entrée AKS. Quand vous utilisez plusieurs clusters, les demandes des clients sont acheminées vers l’instance d’Azure Application Gateway par le biais d’une instance d’Azure Front Door.

Télécharger un fichier Visio de ce diagramme.

1. L’utilisateur envoie une requête à un nom de domaine (comme https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), qui est résolu avec le profil Azure Front Door. Cette requête est chiffrée à l’aide d’un certificat générique (*.azurefd.net) émis pour tous les sous-domaines d’Azure Front Door. Azure Front Door valide la requête par rapport aux stratégies Web Application Firewall, sélectionne l'origine la plus rapide (en fonction de l’intégrité et de la latence), et utilise le DNS public pour résoudre l’adresse IP d'origine (instance d’Azure Application Gateway).

2. Azure Front Door transfère la requête à l’instance d’Application Gateway appropriée sélectionnée, qui sert de point d’entrée pour l’empreinte régionale. Le trafic circule sur Internet. Azure Front Door garantit le chiffrement du trafic vers l’origine.

   Employez une méthode qui permet de garantir que l’instance d’Application Gateway accepte uniquement le trafic provenant de l’instance de Front Door. Il existe une approche qui consiste à utiliser un groupe de sécurité réseau sur le sous-réseau qui contient Application Gateway. Les règles peuvent filtrer le trafic entrant (ou sortant) en fonction de propriétés telles que Source, Port et Destination. La propriété Source vous permet de définir une étiquette de service intégrée, qui indique les adresses IP d’une ressource Azure. Cette abstraction facilite la configuration et la maintenance de la règle ainsi que le suivi des adresses IP. En outre, envisagez d’utiliser l’en-tête X-Azure-FDID, qu’Azure Front Door ajoute à la requête avant de l’envoyer à l’origine, pour vérifier que l'instance d'Application Gateway accepte uniquement le trafic provenant de l’instance Front Door. Pour plus d’informations sur les en-têtes Front Door, consultez Prise en charge des protocoles d’en-têtes HTTP dans Azure Front Door.

Considérations relatives aux ressources partagées

Bien que le focus de ce scénario soit d’avoir plusieurs instances de Kubernetes réparties sur plusieurs régions Azure, il est logique de partager certaines ressources entre toutes les régions. Une des approches consiste à utiliser un seul fichier Bicep pour déployer toutes les ressources partagées, puis un autre pour déployer chaque « stamp » régional. Cette section décrit en détail chacune de ces ressources partagées ainsi que les considérations relatives à leur utilisation dans plusieurs instances d’AKS.

Container Registry

Azure Container Registry est utilisé dans cette architecture pour fournir des services d’images de conteneurs. Le cluster extrait des images conteneur du registre. Tenez compte des éléments suivants quand vous utilisez Azure Container Registry dans un déploiement de cluster multirégion.

Disponibilité géographique

Positionnez un registre de conteneurs dans chaque région où un cluster AKS est déployé. Cette approche permet les opérations de réseau à faible latence, facilitant des transferts de calque d’image rapides et fiables. Elle signifie également que vous maintenez plusieurs points de terminaison de service d’image pour assurer la disponibilité lorsque les services régionaux ne sont pas disponibles. L’utilisation de la fonctionnalité de géoréplication d’Azure Container Registry vous permet de gérer un registre de conteneurs qui est automatiquement répliqué vers plusieurs régions.

Envisagez de créer un registre unique, avec des répliques dans chaque région Azure contenant des clusters. Pour plus d’informations sur la réplication d’Azure Container Registry, consultez la section Géoréplication dans Azure Container Registry.

Image montrant plusieurs réplicas Azure Container Registry à partir du portail Azure.

Accès au cluster

Chaque cluster AKS nécessite un accès au registre de conteneurs pour pouvoir extraire des couches d’images conteneur. Il existe plusieurs façons d’établir l’accès à Azure Container Registry. Dans cette architecture, une identité managée est créée pour chaque cluster, à qui est ensuite accordé le rôle AcrPull sur le registre de conteneurs. Pour plus d’informations et de recommandations sur l’utilisation des identités managées afin d’accéder à Azure Container Registry, consultez l'architecture de référence d’AKS.

Cette configuration est définie dans le fichier Bicep d’empreinte de cluster pour qu’à chaque déploiement d’une nouvelle empreinte, un accès soit octroyé à la nouvelle instance d’AKS. Étant donné que le registre de conteneurs est une ressource partagée, assurez-vous que vos déploiements incluent l’ID de ressource du registre de conteneurs en tant que paramètre.

Azure Monitor

La fonctionnalité Azure Monitor Container Insights est l’outil recommandé pour superviser et comprendre le niveau de performance et l’intégrité de vos charges de travail de cluster et de conteneur. Container Insights utilise à la fois un espace de travail Log Analytics pour le stockage des données de journal et Azure Monitor Metrics pour le stockage des données de séries chronologiques numériques. Les métriques Prometheus peuvent également être collectées par Container Insights, et les données peuvent être envoyées au service géré Azure Monitor pour Prometheus ou aux Journaux Azure Monitor. Pour plus d’informations, consultez l’architecture de référence d’AKS.

Vous pouvez aussi configurer les paramètres de diagnostic de votre cluster AKS en vue de collecter et d'analyser les journaux des ressources à partir des composants du plan de contrôle AKS et les transférer vers un espace de travail de l'analytique des journaux d'activité.

Lorsque vous concevez une solution de monitoring pour une architecture multirégion, il est important de prendre en compte le couplage entre chaque empreinte. Vous pourriez déployer un seul espace de travail Log Analytics, partagé par chaque cluster Kubernetes. Comme pour les autres ressources partagées, définissez votre empreinte régionale de façon à consommer les informations relatives au seul espace de travail de l'analytique des journaux d'activité globalement partagé, puis connectez chaque cluster régional à ce seul espace de travail partagé. Lorsque chaque cluster régional émet les journaux de diagnostic vers ce seul espace de travail de l'analytique des journaux d'activité, vous pouvez utiliser les données ainsi que les métriques de ressources pour créer plus facilement des rapports et des tableaux de bord qui vous aident à comprendre comment s'exécute l'ensemble de votre solution multirégion.

Azure Front Door

Azure Front Door est utilisé pour équilibrer la charge et router le trafic vers chaque cluster AKS. Azure Front Door permet également le routage global de couche 7. Ces fonctionnalités sont requises pour ce scénario.

Configuration des clusters

À mesure que chaque instance d’AKS régionale est ajoutée, la passerelle Application Gateway déployée avec le cluster Kubernetes doit être inscrite en tant qu'origine dans Azure Front Door, ce qui la rend disponible au routage. Cette opération nécessite une mise à jour de votre infrastructure sous forme de ressources de code. Cette opération peut également être découplée de la configuration de déploiement, et managée en employant des outils tels qu’Azure CLI.

Certificats

Azure Front Door ne prend pas en charge les origines utilisant des certificats auto-signés, même dans des environnements de développement ou de test. Pour activer le trafic HTTPS, vous devez créer un certificat TLS/SSL signé par une autorité de certification. Pour plus d’informations sur les autres autorités de certification que prend en charge Front Door, consultez l’article traitant des autorités de certification autorisées pour l’activation de connexions HTTPS personnalisées sur Azure Front Door.

Pour les tests, ou pour les clusters non destinés à la production, vous pourriez envisager d’utiliser Certbot pour créer un certificat Let’s Encrypt Authority X3 pour chacun des passerelles applicatives.

Durant la planification d’un cluster de production, utilisez la méthode privilégiée par votre organisation pour obtenir des certificats TLS.

Accès au cluster et identité

Comme indiqué dans l’architecture de référence AKS, nous vous recommandons d’utiliser Microsoft Entra ID comme fournisseur d’identité pour vos clusters. Les groupes Microsoft Entra peuvent ensuite être utilisés pour contrôler l’accès aux ressources du cluster.

Quand vous gérez plusieurs clusters, vous devez choisir un schéma d’accès. Options disponibles :

• Créez un groupe d’accès global à l’échelle du cluster dont les membres peuvent accéder à tous les objets dans chaque instance de Kubernetes au sein du cluster. Cette option répond à des besoins d’administration minimaux. Toutefois, elle octroie des privilèges importants à n’importe quel membre du groupe.
• Créez pour chaque instance de Kubernetes un groupe d’accès individuel permettant d’octroyer l’accès aux objets d’une instance de cluster individuelle. Avec cette option, la surcharge d’administration augmente. Toutefois, elle fournit également un accès au cluster plus précis.
• Définissez des contrôles d’accès précis pour les types d’objet et les espaces de noms Kubernetes, puis mettez en corrélation les résultats avec une structure de groupe Microsoft Entra. Avec cette option, la surcharge d’administration augmente considérablement. Toutefois, elle fournit un accès précis à chaque cluster ainsi qu’aux espaces de noms et aux API Kubernetes présentes dans chaque cluster.

Pour l’accès administratif, envisagez de créer un groupe Microsoft Entra pour chaque région. Accordez à chaque groupe un accès complet au « stamp » de cluster correspondant dans cette région. Les membres de chaque groupe ont ensuite un accès administratif aux clusters correspondants.

Pour plus d’informations sur la gestion de l’accès au cluster AKS avec Microsoft Entra ID, consultez Intégration Microsoft Entra AKS.

Données, état et cache

Quand vous utilisez un ensemble de clusters AKS ayant une distribution globale, tenez compte de l’architecture de l’application, des processus ou des charges de travail susceptibles de s’exécuter sur le cluster. Dans la mesure où les charges de travail basées sur l’état sont réparties entre les clusters, doivent-elles accéder à un magasin d’états ? Si un processus est recréé ailleurs dans le cluster à la suite d’une défaillance, la charge de travail ou le processus continue-t-il à avoir accès à un magasin d’états dépendant ou à une solution de mise en cache ? L’état peut être stocké de plusieurs façons. Toutefois, cela peut être difficile à gérer, même dans un seul cluster Kubernetes. La complexité augmente quand vous ajoutez plusieurs clusters de Kubernetes. En raison des problèmes de complexité et d’accès régionaux, envisagez de concevoir vos applications de sorte qu’elles utilisent un service de magasin d’états distribué à l’échelle mondiale.

La conception de cette architecture n’inclut pas de configuration pour les préoccupations liées à l’état. Si vous exécutez une même application logique sur plusieurs clusters AKS, concevez l’architecture de votre charge de travail de façon à utiliser un service de données distribué à l’échelle mondiale, par exemple Azure Cosmos DB. Azure Cosmos DB est un système de base de données mondialement distribué qui vous permet de lire et d’écrire des données à partir des réplicas locaux de votre base de données, le service Cosmos DB gérant la géoréplication pour vous. Pour plus d’informations, consultez Azure Cosmos DB.

Si votre charge de travail utilise une solution de mise en cache, assurez-vous que l'architecture de vos services caching permettent à ceux-ci de rester opérationnels, même pendant des événements de basculement. Assurez-vous que la charge de travail proprement dite est résiliente par rapport au basculement lié au cache, et que les solutions de mise en cache sont présentes sur toutes les instances régionales d’AKS.

Optimisation des coûts

Utilisez la calculatrice de prix Azure pour estimer les coûts des services utilisés dans l’architecture. D’autres bonnes pratiques sont évoquées dans la section Optimisation des coûts de Microsoft Azure Well-Architected Framework, et l’article Optimiser les coûts décrit des options de configuration d’optimisation des coûts spécifiques.

Envisagez d’activer l’analyse des coûts AKS pour l’allocation granulaire des coûts de l’infrastructure de cluster par des constructions spécifiques à Kubernetes.

Étapes suivantes

• Zones de disponibilité AKS
• Azure Kubernetes Fleet Manager
• Géoréplication dans Azure Container Registry
• Régions Azure appairées

Ressources associées

• Révision d’Azure Well-Architected Framework pour Azure Kubernetes Service (AKS)
• Architecture de référence pour un cluster Azure Kubernetes Service (AKS)
• Pipeline CI/CD pour les charges de travail basées sur des conteneurs
• Intégration Microsoft Entra AKS
• Documentation Azure Front Door
• Documentation Azure Cosmos DB