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

Cette architecture de référence explique en détail comment exécuter plusieurs instances d’un cluster AKS (Azure Kubernetes Service) dans plusieurs régions au sein d’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. Il est recommandé de se 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.

Une implémentation de référence de cette architecture est disponible sur GitHub.

Composants

De nombreux composants et services Azure sont utilisés dans l’architecture de référence d’AKS pour les régions multiples. Seuls les composants uniques par rapport à cette architecture multicluster sont listés ci-dessous. Pour le reste, consultez l’architecture de référence d’AKS.

• Clusters multiples/Régions multiples 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éseau hub-and-spoke pour chaque région 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.
• Magasin de clés régional Azure Key Vault est provisionné dans chaque région pour stocker les valeurs sensibles et les clés spécifiques à l’instance d’AKS ainsi que pour prendre en charge les services présents dans la région correspondante.
• 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 sept, ce qui est nécessaire pour cette architecture de référence.
• Log Analytics Les instances régionales de Log Analytics 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.
• Registre de conteneurs 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 de référence utilise deux modèles de conception cloud. Les nœuds géographiques (géodes), où n’importe quelle région peut traiter une requête, et les 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 (modèle de déploiement).

Considérations relatives au modèle de nœud géographique

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

Durant la gestion d’un cluster AKS multirégion, plusieurs instances d’AKS sont déployées sur plusieurs régions. Chacune de ces instances est considérée comme une empreinte. En cas de défaillance régionale ou si un renforcement de la capacité et/ou de la présence régionale s’avère nécessaire pour votre cluster, vous devrez 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, telle que l’IaC (Infrastructure as 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
• 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
• Réfléchissez à une façon de gagner en visibilité et/ou de superviser la collection d’empreintes en tant qu’unité.

Chacun de ces éléments est détaillé avec des conseils d’aide spécifiques tout au long des sections suivantes de cette architecture de référence.

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. Vous devez envisager des stratégies de scale-out et de scale-in quand il s’agira d’ajouter ou de supprimer des instances Kubernetes. Votre conception et votre plan de déploiement et de configuration devront prendre en considération les défaillances régionales ou d’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 disposez d’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. De plus, le déploiement et la configuration de nombreux clusters à l’aide du portail est un processus qui doit être effectué au moment opportun et qui mobilise toute l’attention d’un ou de plusieurs ingénieurs. 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 de nombreuses instances d’AKS, nous vous recommandons de prendre en compte les solutions IaC (infrastructure as code), par exemple les modèles Azure Resource Manager, les modèles Bicep ou les configurations Terraform. Les solutions IaC fournissent un déploiement automatisé, scalable et idempotent. Cette architecture de référence comprend un modèle ARM pour les services partagés des solutions, et un autre pour les clusters AKS et les 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 spécifiques à 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, notamment quand un nombre statique/fixe d’instances AKS est déployé, 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 une approche manuelle est acceptable.

Déploiement de cluster

Une fois l’empreinte de cluster 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 au code/contrôle de code source de déploiement
• Journalisation et historique de déploiement

À 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. Dans l’implémentation de référence, chaque région est déployée dans une étape distincte d’un workflow GitHub Actions (exemple). Cette configuration est simple dans la mesure où chaque instance de cluster est 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 à utiliser la logique 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 garantit pas nécessairement qu’elle est également désactivée. Selon votre solution de déploiement et sa configuration, vous aurez peut-être besoin de passer par une étape supplémentaire pour vérifier que les instances AKS ont été correctement désactivées.

Démarrage de cluster

Une fois que chaque empreinte ou instance de Kubernetes a été déployée, 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 devez également 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, envisagez d’utiliser des méthodes automatisées pour appliquer les configurations à un cluster Kubernetes, car ces configurations sont archivées dans un dépôt source. Ce processus est souvent appelé GitOps. Les solutions GitOps populaires pour Kubernetes incluent Flux et Argo CD. Cette implémentation utilise l’extension Flux pour AKS pour permettre le démarrage automatique des clusters de suite 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. Le point important à noter ici est que l’utilisation d’une approche GitOps de la configuration est l’assurance que chaque instance Kubernetes est configurée de manière similaire, sans aucune adaptation. Cela devient encore plus important lorsque 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, 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.

Dans cette implémentation de référence, le service Azure Policy est activé au moment de la création du cluster AKS. Il affecte l’initiative restrictive en mode Audit pour accéder aux informations de non-conformité. L’implémentation définit également des stratégies supplémentaires qui ne font partie d’aucune initiative intégrée. Ces stratégies sont définies en mode Refus. Par exemple, une stratégie est 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. L’implémentation de référence associée à cette architecture utilise un modèle ARM pour affecter des stratégies 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 permet 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 :

• Les stratégies qui doivent s’appliquer globalement à toutes les instances d’AKS peuvent être appliquées à un groupe d’administration ou un abonnement
• Le fait de placer chaque cluster régional dans son propre groupe de ressources permet d’appliquer des stratégies spécifiques à la région à ce groupe de ressources

Pour obtenir des informations qui vous aideront à é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 doivent ê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ù ce service est 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é.

Pods d’applications (régionaux)

Un objet de déploiement Kubernetes permet de créer plusieurs réplicas d’un pod (ReplicaSet). Si l’un d’eux 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 recréée. Enfin, les probes liveness permettent de 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, ce qui force le ReplicaSet à créer une autre instance.

Pour plus d’informations, consultez ReplicaSet Kubernetes.

Pods d’applications (globaux)

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, l’instance d’Azure Front Door route l’ensemble du trafic vers les régions saines restantes. Les clusters et pods Kubernetes de ces régions continuent à traiter les requêtes.

Dans cette situation, veillez à compenser l’augmentation du trafic/des requêtes vers le cluster restant. Quelques points à prendre en compte :

• 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 qui peut prendre en charge toutes les IP de pods faisant l’objet d’un pic de charge du trafic.
• Utilisez la mise à l’échelle automatique horizontale de pods pour augmenter le nombre de réplicas de pod afin de répondre à l’augmentation de la demande régionale.
• Utilisez la mise à l’échelle automatique de clusters AKS pour augmenter le nombre de nœuds d’instance de 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.

Pools de nœuds Kubernetes (régionaux)

Une défaillance localisée peut parfois se produire au niveau des ressources de calcul, par exemple en cas de coupure d’alimentation d’un seul rack de serveurs Azure. Pour empêcher vos nœuds AKS de devenir un point de défaillance régionale unique, utilisez les zones de disponibilité Azure. L’utilisation des zones de disponibilité permet de garantir 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.

Pools de nœuds Kubernetes (globaux)

En cas de défaillance régionale complète, Azure Front Door route le trafic vers les régions saines restantes. Là encore, dans cette situation, veillez à compenser l’augmentation du trafic/des requêtes vers le cluster restant.

Pour plus d’informations, consultez Azure Front Door.

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 une topologie hub-and-spoke pour chaque instance régionale d’AKS où les réseaux virtuels hub-and-spoke sont appairés.
• 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.

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 les ressources d’entrée AKS ou l’équilibreur de charge du backend. 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.azurefd.net), qui est résolu en instance d’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. L’instance d’Azure Front Door valide la requête par rapport aux stratégies WAF, sélectionne le back-end le plus rapide (en fonction de l’intégrité et de la latence), et utilise le DNS public pour résoudre l’adresse IP du back-end (instance d’Azure Application Gateway).

2. 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 et est chiffré par Azure Front Door. 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. De plus, utilisez l’en-tête X-Azure-FDID envoyé par Front Door au back-end pour vérifier que l’instance d’Application Gateway accepte uniquement le trafic provenant de l’instance de 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 cette architecture de référence se focalise sur la répartition de plusieurs instances de Kubernetes dans plusieurs régions Azure, il est logique d’avoir des ressources partagées par toutes les instances. L’implémentation de référence multirégion d’AKS utilise un seul modèle ARM pour déployer toutes les ressources partagées, puis un autre pour déployer chaque empreinte régionale. 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 de référence pour fournir des services d’images conteneur (extraction). Tenez compte des éléments suivants quand vous utilisez Azure Container Registry dans un déploiement de cluster multirégion.

Disponibilité géographique

Le positionnement d’un registre de conteneurs dans chaque région où un cluster AKS est déployé permet l’exécution d’opérations propices à une proximité réseau, notamment les transferts de couches d’images rapides et fiables. 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 une instance de Container Registry répliquée vers plusieurs régions.

L’implémentation de référence multirégion d’AKS a créé une seule instance de Container Registry ainsi que des réplicas de cette instance dans chaque région de cluster. 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 ACR à partir du portail Azure.

Accès au cluster

Chaque instance d’AKS nécessite un accès pour extraire les couches d’images à partir d’Azure Container Registry. Il existe plusieurs façons d’établir l’accès à Azure Container Registry. Cette architecture de référence utilise une identité managée Azure pour chaque cluster, qui se voit ensuite octroyer le rôle AcrPull dans l’instance de Container Registry. Pour plus d’informations et de recommandations sur l’utilisation des identités managées afin d’accéder à Container Registry, consultez l’architecture de référence d’AKS.

Cette configuration est définie dans le modèle ARM d’empreinte de cluster pour qu’à chaque déploiement d’une nouvelle empreinte, un accès soit octroyé à la nouvelle instance d’AKS. Dans la mesure où Container Registry est une ressource partagée, vérifiez que votre modèle d’empreinte de déploiement peut consommer et utiliser les informations nécessaires, dans ce cas précis, l’ID de ressource de Container Registry.

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 envoyées au service géré Azure Monitor pour Prometheus ou à Azure Monitor Logs.

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

Pour plus d’informations, consultez Architecture de référence d’AKS.

Si vous devez réfléchir au monitoring d’une implémentation interrégion conforme à cette architecture de référence, prenez en compte le couplage entre chaque empreinte. Dans ce cas, considérez chaque empreinte comme un composant d’une seule unité (cluster régional). L’implémentation de référence multirégion d’AKS utilise 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 Log Analytics, puis connectez-y chaque cluster.

Maintenant que chaque cluster régional émet les journaux de diagnostic vers un seul espace de travail Log Analytics, ces données peuvent être utilisées parallèlement aux métriques de ressources pour créer plus facilement des rapports et des tableaux de bord qui représentent l’intégralité du cluster global.

Azure Front Door

Azure Front Door est utilisé pour équilibrer la charge et router le trafic vers chaque cluster AKS. Azure Front Door permet un routage global de couche sept, ce qui est nécessaire pour cette architecture de référence.

Configuration de clusters

Dans la mesure où des instances d’AKS régionales sont ajoutées, la passerelle Application Gateway déployée avec le cluster Kubernetes doit être inscrite en tant que back-end Front Door pour permettre au routage de s’effectuer correctement. 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 avec des outils tels qu’Azure CLI. Le pipeline de déploiement des implémentations de référence incluses utilise une étape distincte d’Azure CLI pour cette opération.

Certificats

Front Door ne prend pas en charge les certificats autosignés, même dans les environnements Dev/Test. Pour activer le trafic HTTPS, vous devez créer un certificat TLS/SSL signé par une autorité de certification. L’implémentation de référence utilise Certbot pour créer un certificat Let’s Encrypt Authority X3. Durant la planification d’un cluster de production, utilisez la méthode privilégiée par votre organisation pour obtenir des certificats TLS.

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.

Accès au cluster et identité

Comme indiqué dans l’architecture de référence AKS, il est recommandé d’utiliser Microsoft Entra ID comme fournisseur d’identité d’accès des 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 Azure Active Directory. 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ésents dans chaque cluster.

Avec l’implémentation de référence incluse, deux groupes Microsoft Entra sont créés pour l’accès administrateur. Ces groupes sont spécifiés au moment du déploiement de l’empreinte de cluster à l’aide du fichier de paramètres de déploiement. Les membres de chaque groupe ont un accès total à l’empreinte de cluster correspondante.

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 cluster d’instances d’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ù la charge de travail basée sur l’état est répartie sur le cluster, doit-t-elle accéder à un magasin d’états ? Si un processus est recréé ailleurs dans le cluster en raison 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 est accessible de plusieurs façons. Toutefois, cela peut être complexe dans un seul cluster Kubernetes. La complexité augmente quand vous ajoutez plusieurs instances de Kubernetes en cluster. 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.

L’implémentation de référence multicluster n’inclut pas de démonstration ni de configuration relative aux problèmes d’état. Si vous exécutez des applications sur des instances d’AKS en cluster, concevez l’architecture de votre charge de travail pour 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. Pour plus d’informations, consultez Azure Cosmos DB.

Si votre charge de travail utilise une solution de mise en cache, vérifiez que son architecture permet de maintenir opérationnels les services de mise en cache. Pour ce faire, 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