Partager via


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

Azure Kubernetes Service (AKS)
Azure Front Door
Application Gateway Azure
Azure Container Registry
Pare-feu Azure

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

Diagramme d’architecture montrant le déploiement multirégion.

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 à cette architecture multi-cluster sont répertorié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 devient indisponible, le trafic est acheminé vers une région restante la plus proche de l’utilisateur qui a émis la demande.
  • Réseaux hub-spoke régionaux : Un réseau virtuel hub-spoke régional est déployé pour chaque instance AKS régionale. stratégies de Azure Firewall Manager sont utilisées pour gérer les stratégies de pare-feu dans toutes les régions.
  • coffre de clés régional : Azure Key Vault est approvisionné 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 de journal : les espaces de travail Log Analytics Régional sont utilisés pour stocker les métriques de mise en réseau régionales et les journaux de diagnostic. 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.
  • Flotte AKS :Azure Kubernetes Fleet Manager est déployé pour coordonner les mises à jour des versions de cluster Kubernetes et les mises à jour de version d’image de nœud sur chacun des clusters AKS régionaux.
  • Cluster Fleet Hub (géré par Microsoft) :si vous le souhaitez, un seul cluster Hub Azure Kubernetes Fleet Manager peut être déployé pour prendre en charge des fonctionnalités spécifiques des flottes, telles que la propagation de la charge de travail. Le cluster hub est une ressource Azure à étendue régionale qui permet de gérer la propagation de la charge de travail et l’équilibrage de charge sur plusieurs clusters membres. Il est préférable de déployer le cluster hub en tant que cluster de hub privé, qui doit être accessible à partir de clusters membres pour prendre en charge les signaux de pulsation et effectuer des processus de rapprochement de configuration.
  • profil Azure Front Door global :azure Front Door est utilisé pour équilibrer la charge et acheminer le trafic vers une instance Azure Application Gateway régionale, 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. La géoréplication pour Azure Container Registry permet de répliquer des images dans les régions Azure sélectionnées et de fournir un accès continu aux images même si une région rencontre une panne.

Alternatives

Cette solution utilise Azure Kubernetes Fleet Manager. Les flottes permettent de gérer plusieurs clusters, en mettant l’accent sur la rationalisation des opérations quotidiennes 2 en fournissant un plan de contrôle capable d’orchestrer des activités sur plusieurs clusters. Les avantages de Fleet Manager augmentent à mesure que le nombre de clusters de votre flotte augmente.

Dans cette solution, la flotte orchestre les mises à jour de version Kubernetes sur plusieurs clusters, ainsi que les mises à jour de version d’image de nœud. Ces fonctionnalités ne nécessitent pas de déploiement d’un cluster hub. Vous pouvez choisir d’effectuer des mises à jour d’images de nœud et de version Kubernetes indépendamment, ce qui ne nécessite pas de flotte. Toutefois, si vous le faites, les clusters sont susceptibles d’obtenir des mises à jour de version à différents moments et peuvent devenir difficiles à valider votre charge de travail et votre configuration avec plusieurs versions dans votre environnement de production simultanément.

Vous pouvez également utiliser une flotte pour la coordination du déploiement de charge de travail, ce qui nécessite l’ajout d’un cluster hub. Les déploiements de charges de travail sont abordés plus en détail plus loin dans cet article.

Modèles de conception

Cette architecture utilise deux modèles de conception cloud :

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.

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.

Après la création d’un cluster, il doit être inscrit dans la flotte en tant que cluster membre. Cette étape peut être effectuée en déployant une ressource Resource Manager de type Microsoft.ContainerService/fleets/members, qui fait référence à l’ID de ressource du cluster membre. Une fois le cluster membre inscrit dans la flotte, il peut être ajouté pour mettre à jour les exécutions et utiliser d’autres fonctionnalités de flotte que vous configurez.

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 devrez peut-être créer des espaces de noms Kubernetes, et vous devez également envisager d’appliquer des stratégies de sécurité, d’accès et de gouvernance au sein du cluster. Ces opérations sont appelées démarrage du cluster pour préparer les charges de travail qui seront déployées.

Comme pour le déploiement, les configurations de démarrage peuvent devenir difficiles à gérer manuellement sur plusieurs instances Kubernetes. Si vous utilisez un cluster hub avec Azure Kubernetes Fleet Manager, vous pouvez déployer une partie de la configuration de démarrage dans votre flotte, comme les espaces de noms. Toutefois, d’autres composants de démarrage nécessitent une approche de déploiement différente.

Vous devez envisager l’une des options suivantes pour appliquer la configuration et la stratégie de démarrage à grande échelle.

GitOps

Au lieu de configurer manuellement des composants Kubernetes sur chaque cluster, il est recommandé d’utiliser des méthodes automatisées pour appliquer des configurations à un cluster Kubernetes, car ces configurations sont vérifié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.

Vous pouvez utiliser une approche GitOps pour déployer la configuration du cluster de base. Vous pouvez inscrire le cluster dans la flotte pour participer à des activités à l’échelle de la flotte telles que les déploiements de mise à niveau automatisés.

Vous pouvez également utiliser GitOps pour déployer vos charges de travail. Pour en savoir plus, consultez la section déploiement de la charge de travail ci-dessous.

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.

Inscription de flotte

Une fois qu’un cluster est déployé et configuré, vous l’inscrivez dans la flotte en tant que cluster membre. Chaque cluster membre peut être affecté à un groupe de mises à jour, qui peut être utilisé dans le cadre d’une stratégie de mise à jour pour déterminer où, dans une exécution de mise à jour, le cluster est mis à jour. Pour en savoir plus sur l’inscription de cluster, les groupes et les stratégies de mise à jour, consultez Définir des stratégies de mise à jour réutilisables à l’aide d’Azure Kubernetes Fleet Manager.

Déploiement de charge de travail

Chaque cluster AKS de votre architecture exécute des applications qui prennent en charge votre charge de travail. Il est important de planifier la façon dont vous allez déployer et mettre à niveau vos composants de charge de travail de manière sécurisée et contrôlée, et de maintenir la cohérence des versions d’application entre chaque cluster. Par conséquent, en plus de la configuration de l’instance AKS, tenez compte des charges de travail déployées dans chaque instance régionale ou tampon. Vos solutions de déploiement ou pipelines nécessitent une configuration pour prendre en charge chaque tampon régional. 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.

Vous pouvez envisager plusieurs approches de déploiement, notamment :

  • Pipelines: Pour les scénarios avec un petit nombre de clusters et relativement peu de déploiements simples, il est souvent préférable d’utiliser des pipelines de livraison continue (CD) dédiés légers.

    Un seul pipeline déploie généralement une charge de travail sur un ou plusieurs clusters. Cette approche réduit la surcharge opérationnelle et reste gérable dans les environnements à faible échelle. Lorsque vous passez d’un cluster unique à un modèle de cluster à peu de cluster, vous pouvez faire évoluer les pipelines de déploiement que vous avez déjà en place.

  • Propagation de la charge de travail Azure Kubernetes Fleet Manager : La propagation des charges de travail de flotte simplifie la tâche d’orchestrer les définitions de charge de travail sur plusieurs clusters membres à partir d’un plan de contrôle centralisé. Les flottes prennent en charge une approche fiable et évolutive des déploiements de charges de travail, ce qui permet un grand nombre de charges de travail et de clusters membres.

    La propagation de la charge de travail nécessite l’utilisation d’un cluster hub, qui est un cluster AKS géré par Microsoft qui permet de suivre l’état attendu de vos clusters membres. Ce cluster hub est une ressource régionale. Si une panne régionale affecte le cluster hub, la propagation de la charge de travail peut rencontrer une interruption temporaire.

  • GitOps : À mesure que votre infrastructure mûrit davantage, l’adoption d’une stratégie basée sur GitOps devient de plus en plus bénéfique. GitOps permet des mécanismes de déploiement déclaratifs, auditables et pull, offrant une scalabilité, une gouvernance et une collaboration d’équipe. La transition vers ce modèle est particulièrement recommandée lors de la gestion d’une grande flotte dynamique de clusters dans plusieurs régions.

    Pour en savoir plus, consultez GitOps pour Azure Kubernetes Service.

Pour déterminer quelle approche est logique pour votre solution, tenez compte des questions suivantes :

  • Attendez-vous que le nombre de clusters reste fixe ou augmente au fil du temps ? Si vous envisagez d’étendre le nombre de clusters ou si vous envisagez d’ajuster le nombre de clusters dynamiquement, il peut rapidement devenir difficile de gérer la configuration de chaque cluster dans vos pipelines de déploiement.
  • Combien d’unités déployables devez-vous gérer ? Si vous avez un petit nombre d’applications monolithiques, vous n’avez qu’un petit nombre de déploiements individuels à coordonner. Toutefois, si vous avez une architecture distribuée basée sur des microservices, un grand nombre de charges de travail ou les deux. alors cela peut rapidement croître en centaines d’unités déployables. La création d’un pipeline pour chaque déploiement peut devenir impossible.
  • Quels types de stratégies de déploiement avez-vous besoin ? Les stratégies courantes incluent les mises à jour propagées, les déploiements bleu-vert et les déploiements canary. Certaines approches de déploiement doivent permettre de « passer du temps » entre les déploiements, avec une surveillance étroite pour vérifier les régressions introduites par le déploiement. Évaluez chaque approche de déploiement pour déterminer si elle prend en charge vos besoins spécifiques.
  • Quelles contraintes de sécurité réseau vos clusters fonctionnent-ils ? Azure Kubernetes Fleet Manager fonctionne sous une topologie de cluster hub-and-spoke, où les clusters membres conservent des connexions sortantes vers un cluster hub central pour la rapprochement des charges de travail et la surveillance des pulsations. Une stratégie basée sur GitOps nécessite que les clusters participants établissent un accès sortant à un référentiel Git. Lorsque vous utilisez des pipelines, l’agent de pipeline nécessite généralement une connectivité à chaque cluster pour effectuer des opérations de déploiement.

Quelle que soit la façon dont vous allez orchestrer vos déploiements, visez à généraliser chaque déploiement, par exemple avec un graphique Helm, pour vous assurer qu’une configuration de déploiement unique peut être utilisée sur plusieurs clusters (tampons). Réfléchissez également à la façon dont la journalisation des diagnostics d’application et le suivi distribué peuvent être configurés pour l’observabilité à l’échelle de l’application sur chacun de vos clusters.

Fiabilité

La fiabilité garantit que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

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.

Schéma d’une architecture montrant le trafic des charges de travail dans un déploiement multirégion.

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.

Registre de conteneurs

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.

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

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 - Service de passerelle réseau de Microsoft

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.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’abus de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

Contrôle d’accès au cluster

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.

Sécurité de vos ressources de flotte

Lorsque vous utilisez une flotte pour centraliser les aspects de la gestion de votre cluster, il est important de protéger les ressources de la flotte pour éviter toute utilisation abusive. Les ressources de flotte utilisent le contrôle d’accès en fonction du rôle Azure et vous pouvez accorder des autorisations de flotte à un ensemble restreint d’administrateurs. Suivez le principe du privilège minimum et accordez le moins d’accès possible à la ressource de flotte (le plan de contrôle de la flotte).

Si votre flotte utilise un cluster hub, tenez compte des recommandations supplémentaires suivantes :

  • Évaluez les attributions de rôles que vous créez dans votre cluster hub (attributions de rôles de plan de données ). Ces attributions de rôles accordent l’accès aux ressources Kubernetes créées par la flotte. Attributions de rôles d’étendue à un espace de noms Kubernetes individuel si possible.
  • Utilisez un cluster de hub privé pour restreindre la connectivité Internet. Toutefois, assurez-vous que votre architecture réseau permet aux clusters membres d’atteindre le cluster hub.

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.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Lorsque vous utilisez un environnement multi-cluster avec une ressource de flotte, la surveillance devient plus difficile. De même, tenez compte de la façon dont vous coordonnerez les mises à jour des composants du cluster AKS.

Surveiller les clusters et charges de travail

L’examen manuel des tableaux de bord et des journaux d’activité peut devenir difficile à mesure que le nombre de clusters augmente. Vous pouvez donc envisager la façon dont vous agrégerez systématiquement les journaux et les métriques.

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é.

Pour en savoir plus sur la configuration des espaces de travail Azure Monitor dans un environnement multi-cluster, consultez Azure Monitor.

Surveiller les opérations de la flotte

Lorsque Fleet Manager orchestre une exécution de mise à jour, vous pouvez surveiller la progression de l’exécution au fur et à mesure qu’elle progresse entre les clusters. Les données sont stockées dans Azure Resource Graph et peuvent être exportées vers Azure Monitor pour les alertes et le stockage.

Si vous choisissez d’utiliser Fleet Manager pour la propagation de la charge de travail, vous pouvez surveiller le déploiement à l’aide du portail Azure ou de kubectl.

Vous pouvez également collecter des journaux de ressources à partir de la ressource de flotte et les transférer vers un espace de travail Log Analytics.

Appliquer des mises à jour au sein de la flotte

Dans cette architecture de référence, Fleet Manager applique les mises à jour des versions kubernetes et les mises à jour d’images de nœud dans votre flotte. Vous pouvez spécifier des stratégies de mise à niveau qui configurent la façon dont les mises à niveau sont déployées sur vos clusters. En outre, Fleet Manager respecte les fenêtres de maintenance sur chaque cluster. Il est donc recommandé de définir les fenêtres de maintenance appropriées pour chaque cluster. Les fenêtres de maintenance de chaque cluster peuvent être différentes lorsque vous utilisez des clusters dans plusieurs zones géographiques et, par conséquent, dans différents fuseaux horaires.

Pour plus d’informations, consultez Mettre à jour Kubernetes et les images de nœud sur plusieurs clusters membres.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’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