Partager via

Vue d’ensemble de la haute disponibilité et de la récupération d’urgence dans AKS (Azure Kubernetes Service)

  • Article

Lors de la création et de la gestion d’applications dans le cloud, il y a toujours un risque de perturbation due à des pannes et à des catastrophes. Pour garantir la continuité d’activité (BC), vous devez planifier la haute disponibilité (HA) et la récupération d’urgence (DR).

La HA fait référence à la conception et à l’implémentation d’un système ou d’un service hautement fiable et qui subit un temps d’arrêt minimal. La HA est une combinaison d’outils, de technologies et de processus qui garantissent qu’un système ou un service est disponible pour effectuer sa fonction prévue. La HA est un composant essentiel de la planification de la DR. La DR est le processus de récupération après un sinistre et de rétablissement des activités de l’entreprise à un niveau normal. La récupération d’urgence est un sous-ensemble de la BC, qui est le processus de maintien ou de reprise rapide des fonctions commerciales en cas de perturbation majeure.

Cet article traite de certaines pratiques recommandées pour les applications déployées sur AKS, mais ce n’est pas une liste exhaustive des solutions possibles.

Vue d’ensemble des technologies

Un cluster Kubernetes comprend deux composants :

  • Le plan de contrôle, qui fournit les services Kubernetes de base et l’orchestration des charges de travail d’applications, et
  • Les nœuds, qui exécutent vos charges de travail d’applications.

Diagramme du plan de contrôle Kubernetes et des composants de nœud.

Lorsque vous créez un cluster AKS, la plateforme Azure crée et configure automatiquement un plan de contrôle. AKS offre deux niveaux tarifaires pour la gestion des clusters : le niveau Gratuit et le niveau Standard. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Niveaux tarifaires Gratuit et Standard pour la gestion des clusters AKS.

Le plan de contrôle et ses ressources se trouvent uniquement sur la région dans laquelle le cluster a été créé. AKS fournit un plan de contrôle monolocataire doté de dispositifs dédiés (serveur d’API, planificateur, etc.). Vous définissez le nombre et la taille des nœuds, puis la plateforme Azure configure la communication sécurisée entre les nœuds et le plan de contrôle. L’interaction avec le plan de contrôle se produit par le biais d’API Kubernetes, telles que kubectl ou le tableau de bord Kubernetes.

Pour exécuter vos applications et les services de prise en charge, vous avez besoin d’un nœud Kubernetes. Un cluster AKS comporte au moins un nœud, une machine virtuelle exécutant les composants des nœuds Kubernetes et le runtime de conteneur. La taille VM Azure pour vos nœuds détermine les processeurs, la mémoire, la taille et le type de stockage disponibles (par exemple, SSD hautes performances ou HDD classique). Planifiez la taille de la machine virtuelle et du stockage pour déterminer si vos applications peuvent nécessiter une grande quantité d’UC et de mémoire ou un stockage hautes performances. Dans AKS, l’image de machine virtuelle pour les nœuds de votre cluster est basée sur Ubuntu Linux, Azure Linux ou Windows Server 2022. Quand vous créez un cluster AKS ou augmentez le nombre de nœuds, la plateforme Azure crée et configure automatiquement le nombre demandé de machines virtuelles.

Pour plus d’informations sur les composants de cluster et de charge de travail dans AKS, consultez Concepts fondamentaux de Kubernetes pour AKS.

Remarques importantes

Ressources régionales et globales

Les ressources régionales sont approvisionnées dans le cadre d’un tampon de déploiement dans une seule région Azure. Ces ressources ne partagent rien avec les ressources d’autres régions, et elles peuvent être supprimées ou répliquées indépendamment dans d’autres régions. Pour plus d’informations, consultez Ressources régionales.

Les ressources globales partagent la durée de vie du système et peuvent être disponibles globalement dans le contexte d’un déploiement multirégion. Pour plus d’informations, consultez Ressources globales.

Objectifs de récupération

Un plan de récupération d’urgence complet doit spécifier les exigences commerciales pour chaque processus que l’application implémente :

  • L’objectif de point de récupération (RPO) est la durée maximale d’une perte de données acceptable. Le RPO est mesuré en unités de temps, telles que les minutes, les heures ou les jours.
  • L’objectif de délai de récupération (RTO) est la durée maximale d’un temps d’arrêt acceptable, le temps d’arrêt étant défini selon vos spécifications. Par exemple, si la durée de temps d’arrêt acceptable en cas de sinistre est de huit heures, alors le RTO est de huit heures.

Zones de disponibilité

Vous pouvez utiliser des zones de disponibilité pour répartir vos données entre plusieurs zones dans la même région. Dans une région, les zones de disponibilité sont suffisamment proches pour avoir des connexions à faible latence à d’autres zones de disponibilité, mais elles sont assez éloignées pour réduire la probabilité que plusieurs personnes soient affectées par des pannes locales ou des conditions météorologiques. Pour plus d’informations, consultez Recommandations relatives à l’utilisation des zones de disponibilité et des régions.

Résilience zonale

Les clusters AKS sont résilients aux défaillances zonales. Si une zone tombe en panne, le cluster continue à s’exécuter dans les zones restantes. Le plan de contrôle et les nœuds du cluster sont répartis entre les zones, et la plateforme Azure gère automatiquement la distribution des nœuds. Pour plus d’informations, consultez Résilience zonale d’AKS.

Équilibrage de charge

Équilibrage de charge global

Les services globaux d’équilibrage de charge répartissent le trafic sur les serveurs principaux, les clouds ou les services locaux hybrides. Ces services acheminent le trafic de l’utilisateur final vers le backend disponible le plus proche. De même, ils répondent aux changements qui impactent leur fiabilité et leur fonctionnement pour optimiser la disponibilité et les performances. Les services Azure suivants fournissent un équilibrage de charge global :

Équilibrage de charge régional

Les services d’équilibrage de charge régionaux distribuent le trafic au sein des réseaux virtuels sur des machines virtuelles ou des points de terminaison de service de zone et redondants dans une région. Les services Azure suivants fournissent un équilibrage de charge régional :

Observabilité

Vous devez collecter des données à partir des applications et de l’infrastructure pour permettre des opérations efficaces et une fiabilité maximale. Azure fournit des outils pour vous aider à surveiller et à gérer vos charges de travail AKS. Pour plus d’informations, consultez Ressources d’observabilité.

Définition de l’étendue

La durée de bon fonctionnement de l’application devient importante lorsque vous gérez des clusters AKS. Par défaut, AKS fournit une haute disponibilité à l’aide de plusieurs nœuds dans un groupe de machines virtuelles identiques, mais ces nœuds ne protègent pas votre système contre une panne régionale. Pour optimiser votre durée de bon fonctionnement, planifiez à l’avance la continuité de vos activités et préparez la récupération d’urgence à l’aide des meilleures pratiques suivantes :

  • Planifier des clusters AKS dans plusieurs régions.
  • Router le trafic sur plusieurs clusters avec Azure Traffic Manager.
  • Utiliser la géoréplication pour les registres d’images conteneur.
  • Planifier l’état de l’application sur plusieurs clusters.
  • Répliquer le stockage dans plusieurs régions.

Implémentations de modèle de déploiement

Modèle de déploiement Avantages Inconvénients
Actif/actif • Aucune perte de données ou incohérence pendant le basculement
• Résilience élevée
• Meilleure utilisation des ressources et performances plus élevées		 • Implémentation et gestion complexes
• Coût plus élevé
• Nécessite un équilibreur de charge et une forme de routage du trafic
Actif/passif • Implémentation et gestion plus simples
• Coûts réduits
• N’a pas besoin d’un équilibreur de charge ou d’un gestionnaire de trafic		 • Risque de perte de données ou d’incohérence pendant le basculement
• Temps de récupération et temps d’arrêt plus longs
• Sous-utilisation des ressources
Passif-froid • Coût le plus bas
• Ne nécessite pas de synchronisation, de réplication, d’équilibreur de charge ou de gestionnaire du trafic
• Adapté aux charges de travail de faible priorité et non critiques		 • Risque élevé de perte de données ou d’incohérence pendant le basculement
• Temps de récupération et temps d’arrêt les plus longs
• Nécessite une intervention manuelle pour activer le cluster et déclencher la sauvegarde

Modèle de déploiement à haute disponibilité actif-actif

Dans le modèle de déploiement à haute disponibilité (HA) actif-actif, vous disposez de deux clusters AKS indépendants déployés dans deux régions Azure différentes (généralement jumelées, telles que Canada Centre et Canada Est ou USA Est 2 et USA Centre) qui servent activement le trafic.

Dans cet exemple d’architecture :

  • Vous déployez deux clusters AKS dans des régions Azure distinctes.
  • Pendant les opérations normales, le trafic réseau est acheminé vers les deux régions. Si une région cesse d’être disponible, le trafic est acheminé automatiquement vers la région la plus proche de l’utilisateur qui a émis la requête.
  • Il existe une paire hub-spoke déployée pour chaque instance AKS régionale. Les stratégies Azure Firewall Manager gèrent les règles de pare-feu entre les régions.
  • Azure Key Vault est approvisionné dans chaque région pour stocker des secrets et des clés.
  • Azure Front Door équilibre la charge et route le trafic vers une instance Azure Application Gateway régionale, qui se trouve devant chaque cluster AKS.
  • Les instances Log Analytics régionales stockent les métriques réseau et les journaux de diagnostic régionaux.
  • Les images conteneur de la charge de travail sont stockées dans un registre de conteneurs managé. 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 vers les régions Azure sélectionnées. Elle fournit en outre un accès continu à ces images, même si une région subit une panne.

Pour créer un modèle de déploiement actif-actif dans AKS, procédez comme suit :

  1. Créez deux déploiements identiques dans deux régions Azure différentes.

  2. Créez deux instances de votre application web.

  3. Créez un profil Azure Front Door avec les ressources suivantes :

    • Point de terminaison.
    • Deux groupes d’origines, chacun avec une priorité de un.
    • Un itinéraire.

  4. Limitez le trafic réseau aux applications web uniquement à partir de l’instance Azure Front Door. 5. Configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.

  5. Déployez du code sur les applications web à l’aide d’un déploiement continu.

Pour plus d’informations, consultez Vue d’ensemble de la solution haute disponibilité actif-actif recommandée pour AKS.

Modèle de déploiement de récupération d’urgence actif-passif

Dans le modèle de déploiement de récupération d’urgence (DR) actif-passif, vous disposez de deux clusters AKS indépendants déployés dans deux régions Azure différentes (généralement jumelées, telles que Canada Centre et Canada Est ou USA Est 2 et USA Centre) qui servent activement le trafic. Un seul des clusters sert activement le trafic à un moment donné. L’autre cluster contient les mêmes données de configuration et d’application que le cluster actif, mais n’accepte pas le trafic, sauf s’il est dirigé par un gestionnaire de trafic.

Dans cet exemple d’architecture :

  • Vous déployez deux clusters AKS dans des régions Azure distinctes.
  • Pendant les opérations normales, le trafic est acheminé vers le cluster AKS principal, que vous avez défini dans la configuration d’Azure Front Door.
    • La priorité doit être définie entre 1 et 5, avec 1 étant la plus élevée et 5 étant la plus basse.
    • Vous pouvez définir plusieurs clusters au même niveau de priorité et spécifier le poids de chacun d’eux.
  • Si le cluster principal devient indisponible (sinistre), le trafic est automatiquement acheminé vers la région suivante sélectionnée dans Azure Front Door.
    • Tout le trafic doit passer par le gestionnaire de trafic Azure Front Door pour que ce système fonctionne.
  • Azure Front Door achemine le trafic vers Azure App Gateway dans la région primaire (le cluster doit être marqué avec la priorité 1). En cas de défaillance d’une région, le service redirige le trafic vers le cluster suivant dans la liste des priorités.
    • Les règles proviennent d’Azure Front Door.
  • Une paire hub-spoke est déployée pour chaque instance AKS régionale. Les stratégies Azure Firewall Manager gèrent les règles de pare-feu entre les régions.
  • Azure Key Vault est approvisionné dans chaque région pour stocker des secrets et des clés.
  • Les instances Log Analytics régionales stockent les métriques réseau et les journaux de diagnostic régionaux.
  • Les images conteneur de la charge de travail sont stockées dans un registre de conteneurs managé. 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 vers les régions Azure sélectionnées. Elle fournit en outre un accès continu à ces images, même si une région subit une panne.

Pour créer un modèle de déploiement actif-passif dans AKS, procédez comme suit :

  1. Créez deux déploiements identiques dans deux régions Azure différentes.

  2. Configurez des règles de mise à l’échelle automatique pour l’application secondaire afin qu’elle soit mis à l’échelle au même nombre d’instances que le plan principal quand la région primaire devient inactive. Bien qu’elle soit inactive, elle n’a pas besoin d’être mis à l’échelle. Cela permet de réduire les coûts.

  3. Créez deux instances de votre application web, avec une sur chaque cluster.

  4. Créez un profil Azure Front Door avec les ressources suivantes :

    • Point de terminaison.
    • Un groupe d’origines ayant une priorité de un pour la région primaire.
    • Un second groupe d’origines ayant une priorité de deux pour la région secondaire.
    • Un itinéraire.

  5. Limitez le trafic aux applications web à partir de l’instance Azure Front Door uniquement.

  6. Configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.

  7. Déployez du code sur les applications web à l’aide d’un déploiement continu.

Pour plus d’informations, consultez Vue d'ensemble de la solution de récupération d’urgence actif-passif recommandée pour AKS.

Modèle de déploiement de basculement passif-froid

Le modèle de déploiement de basculement passif-froid est configuré de la même façon que le modèle de déploiement de récupération d’urgence actif-passif, sauf que les clusters restent inactifs jusqu’à ce qu’un utilisateur les active en cas de sinistre. Nous considérons cette approche hors portée, car elle implique une configuration similaire à actif-passif, mais avec la complexité ajoutée de l’intervention manuelle pour activer le cluster et déclencher une sauvegarde.

Dans cet exemple d’architecture :

  • Vous créez deux clusters AKS, de préférence dans différentes régions ou zones pour une meilleure résilience.
  • Lorsque vous devez basculer, vous activez le déploiement pour prendre en charge le flux de trafic.
  • Si le cluster passif principal tombe en panne, vous devez activer manuellement le cluster froid pour prendre en charge le flux de trafic.
  • Cette condition doit être définie soit par une entrée manuelle à chaque fois, soit par un certain événement que vous aurez spécifié.
  • Azure Key Vault est approvisionné dans chaque région pour stocker des secrets et des clés.
  • Les instances Log Analytics régionales stockent les métriques réseau et les journaux de diagnostic régionaux pour chaque cluster.

Pour créer un modèle de déploiement de basculement passif-froid dans AKS, procédez comme suit :

  1. Créez deux déploiements identiques dans différentes zones/régions.
  2. Configurez des règles de mise à l’échelle automatique pour l’application secondaire afin qu’elle soit mis à l’échelle au même nombre d’instances que le plan principal quand la région primaire devient inactive. Bien qu’elle soit inactive, elle n’a pas besoin d’être mise à l’échelle, ce qui permet de réduire les coûts.
  3. Créez deux instances de votre application web, avec une sur chaque cluster.
  4. Configurez tous les autres services Azure principaux, tels que les bases de données, les comptes de stockage et les fournisseurs d’authentification.
  5. Définissez une condition lorsque le cluster froid doit être déclenché. Vous pouvez utiliser un équilibreur de charge si nécessaire.

Pour plus d’informations, consultez Vue d’ensemble de la solution de basculement passif-froid recommandée pour AKS.

Quotas et limites du service

AKS définit les limites et quotas par défaut pour les ressources et les fonctionnalités, y compris les restrictions d’utilisation pour certaines références SKU de machine virtuelle.

Ressource Limite
Clusters maximum par abonnement 5 000
Remarque : répartissez les clusters entre différentes régions pour prendre en compte les limitations des API Azure
Nombre maximal de nœuds par cluster avec Virtual Machine Scale Sets et la référence SKU Standard Load Balancer 5 000 dans tous les pools de nœuds
Remarque : Si vous ne parvenez pas à effectuer un scale-up jusqu’à 5 000 nœuds par cluster, consultez Meilleures pratiques pour les grands clusters.
Nombre maximal de nœuds par pool de nœuds (pools de nœuds de groupes de machines virtuelles identiques) 1 000
Nombre maximal de pools de nœuds par cluster 100
Nombre maximal de pods par nœud : avec le plug-in de réseau Kubenet1 Maximum : 250
Valeur Azure CLI par défaut : 110
Valeur par défaut du modèle Azure Resource Manager : 110
Valeur par défaut du déploiement sur le portail Azure : 30
Nombre maximal de pods par nœud : avec Azure Container Networking Interface (Azure CNI)1 Maximum : 250
Maximum recommandé pour les conteneurs Windows Server : 110
Valeur par défaut : 30
Module complémentaire AKS OSM (Open Service Mesh) Version du cluster Kubernetes : versions prises en charge par AKS
Contrôleurs OSM par cluster : 1
Nombre de pods par contrôleur OSM : 1 600
Comptes de service Kubernetes gérés par OSM : 160
Nombre maximal de services Kubernetes à charge équilibrée par cluster avec la référence SKU Standard Load Balancer 300
Nombre maximal de nœuds par cluster avec les groupes à haute disponibilité de machines virtuelles et la référence SKU Standard Load Balancer 100

1 Les conteneurs Windows Server doivent utiliser le plug-in de réseau Azure CNI. Kubenet n’est pas pris en charge pour les conteneurs Windows Server.

Niveau de service du plan de contrôle Kubernetes Limite
Niveau standard Met automatiquement à l’échelle le serveur d’API Kubernetes en fonction de la charge. Plus grandes limites des composants du plan de contrôle et des instances de serveur/etcd d’API.
Niveau gratuit Ressources limitées avec une limite des requêtes en vol fixée à 50 appels en mutation et 100 appels en lecture seule. Limite recommandée de 10 nœuds par cluster. Idéal pour l’expérimentation, l’apprentissage et les tests simples. Non recommandé pour des charges de travail de production/critiques.

Pour plus d’informations, consultez Quotas et limites du service AKS.

Sauvegarde

Sauvegarde Azure prend en charge la sauvegarde des ressources de cluster AKS et des volumes persistants attachés au cluster à l’aide d’une extension de sauvegarde. Le coffre de sauvegarde communique avec le cluster AKS via l’extension pour effectuer des opérations de sauvegarde et de restauration.

Pour plus d’informations, consultez les articles suivants :