Fiabilité dans Azure Application Gateway pour conteneurs

Azure Application Gateway pour conteneurs est un service géré de couche applicative (couche 7) d’équilibrage de charge et de gestion dynamique du trafic pour les charges de travail exécutées dans Kubernetes. Il achemine les requêtes entrantes vers des cibles back-end dans votre cluster.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment Azure Application Gateway pour conteneurs gère les erreurs temporaires, les défaillances de zone de disponibilité, les défaillances à l’échelle de la région et la maintenance du service. Il décrit également les options de sauvegarde et de restauration et les informations clés sur le contrat de niveau de service (SLA).

Recommandations de déploiement de production pour la fiabilité

L’Application Gateway for Containers est hautement disponible par défaut. Pour les charges de travail de production :

Pour obtenir un exemple d’architecture et d’aide sur la topologie, le flux de trafic, la fiabilité, la sécurité et les opérations, consultez Déployer Application Gateway pour conteneurs sur Azure Kubernetes Service.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Un déploiement d’Application Gateway pour conteneurs inclut des ressources dans Azure et dans votre cluster Kubernetes.

  • Azure ressources : le plan de contrôle orchestre la configuration du proxy de la passerelle en fonction de votre configuration. Le plan de données géré par Azure s’exécute en dehors de votre cluster et traite le trafic des applications.
  • Ressources Kubernetes : Vous définissez le routage et d’autres configurations à l’aide de ressources Kubernetes. Le ALB Controller s’exécute dans votre cluster, surveille ces ressources et propage votre configuration à Application Gateway pour conteneurs dans Azure.

Vous pouvez choisir entre deux stratégies de déploiement. Avec la stratégie bring your own (BYO), vous gérez le cycle de vie d’Application Gateway pour les conteneurs, de l’association et des ressources front-end via les outils Azure. Avec la stratégie gérée par le contrôleur ALB, le contrôleur ALB gère le cycle de vie de ces ressources Azure en fonction des ressources Kubernetes que vous définissez.

Pour obtenir une description complète des composants, consultez Composants d’Application Gateway for Containers.

Après avoir déployé et configuré Application Gateway pour conteneurs, il achemine les requêtes entrantes vers les cibles back-end, qui représentent votre application s’exécutant dans Kubernetes.

Si le contrôleur ALB ou le plan de contrôle ne sont pas disponibles, le plan de données continue de traiter le trafic à l’aide de la dernière configuration appliquée. Pendant la panne, les mises à jour de configuration ne sont pas propagées et le service ne peut pas appliquer la configuration requise pour les événements de scale-out.

Architecture physique

Azure gère et met automatiquement à l’échelle l’infrastructure du plan de données en fonction du trafic d’application. Application Gateway pour conteneurs est toujours déployé dans une configuration hautement disponible : dans les régions qui prennent en charge les zones de disponibilité, les passerelles sont redondantes entre zones ; dans les régions qui ne prennent pas en charge les zones de disponibilité, Azure utilise des groupes de disponibilité.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, voir Recommandations concernant le traitement des pannes transitoires.

Lorsque vous utilisez Application Gateway pour conteneurs, tenez compte des meilleures pratiques suivantes :

  • Implémentez la logique de nouvelle tentative. Configurez les clients pour réessayer les demandes après des échecs de connexion temporaires.

  • Configurez les sondes d’intégrité avec tolérance. Si vous configurez des sondes d’intégrité personnalisées, définissez le seuil d’état non sain pour tolérer les erreurs temporaires. Le seuil d’état non sain spécifie le nombre de sondes consécutives ayant échoué qui entraînent le marquage de la cible back-end comme malsaine. La sonde d’intégrité par défaut utilise un seuil de défaillance de trois sondes, ce qui permet d’empêcher une défaillance de sonde temporaire unique de marquer le back-end non sain.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Lorsque vous déployez Application Gateway pour conteneurs dans une région Azure qui prend en charge les zones de disponibilité, Microsoft configure automatiquement le plan de contrôle et le plan de données comme redondants entre zones sur plusieurs zones. Vous ne sélectionnez pas les zones que le service utilise.

Important

Microsoft gère la redondance de zone pour le plan de contrôle et le plan de données d’Application Gateway for Containers. Pour obtenir une résilience de zone de bout en bout, configurez votre cluster Kubernetes, vos ressources Kubernetes et vos charges de travail back-end pour fournir des cibles saines dans l’ensemble des zones.

Spécifications

Prise en charge de la région : Pour utiliser la redondance de zone, choisissez une région qui prend en charge à la fois Application Gateway for Containers et les zones de disponibilité. Vérifiez la disponibilité régionale d’Application Gateway for Containers et comparez-la à la liste des régions qui prennent en charge les zones de disponibilité.

Considérations

Responsabilité partagée avec votre plateforme Kubernetes : Microsoft gère la redirection du trafic pour Application Gateway pour conteneurs lors d’une défaillance de zone. Pour Azure Kubernetes Service (AKS), Microsoft gère le plan de contrôle Kubernetes. Vous êtes responsable de la configuration de la résilience de zone pour les pools de nœuds de votre cluster et d’autres ressources que vous gérez et pour le comportement de vos applications lors d’une panne de zone.

  • Cluster : Configurez vos pools de nœuds AKS et d’autres ressources de cluster liées aux zones que vous gérez pour couvrir les zones de disponibilité. AKS gère le plan de contrôle ; Consultez Configurer des zones de disponibilité pour les pools de nœuds AKS.

  • Vos charges de travail : Vous êtes responsable du déploiement de plusieurs réplicas de pods, de les répartir entre les zones et de garantir que les workloads backend sains sont disponibles pour servir le trafic pendant une panne de zone. Vous pouvez utiliser des pools de nœuds qui couvrent les zones de disponibilité, les contraintes de répartition de topologie et l’anti-affinité de pod.

  • Objets de configuration Kubernetes : Application Gateway pour conteneurs utilise des objets de configuration Kubernetes stockés par l’API de cluster. Leur disponibilité dépend du plan de contrôle Kubernetes et de la configuration que vous gérez dans votre cluster.

  • Contrôleur ALB : Vous déployez le contrôleur ALB dans votre cluster Kubernetes pour réconcilier la configuration. Il ne fait pas partie du chemin des données Application Gateway for Containers.

    Le contrôleur ALB exécute deux réplicas, l’un agissant comme le leader et l’autre comme réplica secondaire. Si le leader devient indisponible, le serveur secondaire peut devenir le leader et continuer à propager la configuration. Les deux réplicas peuvent s’exécuter dans la même zone de disponibilité, selon la façon dont le cluster les planifie. Vous êtes responsable de la configuration des pods de cluster et de contrôleur pour la résilience de zone. Utilisez des contraintes de répartition de topologie de pod ou une anti-affinité de pod pour distribuer les réplicas entre les zones. Pour plus d’informations, consultez Configurer des zones de disponibilité pour les pools de nœuds AKS.

Cost

La prise en charge des zones de disponibilité pour Application Gateway pour conteneurs n’entraîne pas de frais supplémentaires au-delà de la tarification du service standard. Pour plus d’informations sur la tarification, consultez Azure Application Gateway tarification.

Configurez la prise en charge des zones de disponibilité

Lorsque vous déployez une nouvelle passerelle dans une région prise en charge, elle est redondante interzone par défaut. Vous n'avez pas besoin d'activer la redondance de zone sur les ressources Azure.

Vous êtes responsable de la configuration de votre cluster Kubernetes, du contrôleur ALB et des charges de travail back-end pour la résilience de zone.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce que vous devez attendre lorsque vous déployez Application Gateway pour conteneurs dans une région qui prend en charge les zones de disponibilité et toutes les zones utilisées par le service sont opérationnelles.

  • Opération interzone : le plan de données de l’Application Gateway pour les conteneurs gérée par Azure distribue les demandes entrantes sur l’infrastructure de plusieurs zones.

    Vous êtes responsable de la configuration de vos charges de travail back-end pour qu’elles s’exécutent sur plusieurs zones et fournissent des cibles saines pour recevoir ce trafic.

  • Réplication des données interzones : Application Gateway pour conteneurs ne stocke pas les données d’application. La plateforme gère l’état de configuration via le plan de contrôle redondant interzone pour assurer la durabilité et la résilience.

Comportement lors d’une défaillance de zone

Cette section décrit ce à quoi vous devez vous attendre lorsque vous déployez Application Gateway for Containers dans une région qui prend en charge les zones de disponibilité et que l’une des zones utilisées par le service subit une panne.

  • Détection et réponse : Application Gateway pour conteneurs redirige le trafic vers l’infrastructure dans les zones saines restantes pendant une panne de zone. Vous n’avez pas besoin d’agir pour la redistribution du trafic de la passerelle.

    Toutefois, vous êtes responsable de l’effet de la panne sur votre cluster Kubernetes et vos applications back-end.

  • Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Requêtes actives : les connexions existantes à la zone ayant échoué sont supprimées. Les clients doivent réessayer les requêtes en suivant les instructions de résilience aux erreurs temporaires. De nouvelles connexions sont établies vers l’infrastructure dans les zones saines restantes.

  • Perte de données attendue : Application Gateway for Containers ne stocke pas les données d’application. La plateforme gère l’état de configuration via le plan de contrôle redondant interzone pour assurer la durabilité et la résilience.

  • Temps d’arrêt attendu : Les clients peuvent rencontrer une brève interruption lorsque les connexions à la zone défaillante sont supprimées. Les clients doivent réessayer les requêtes pour établir de nouvelles connexions à l’infrastructure dans les zones saines restantes.

    Le plan de contrôle géré par Azure reste disponible lors d’une panne d’une seule zone. Toutefois, votre capacité à appliquer des mises à jour de configuration dépend également de la disponibilité de votre plan de contrôle Kubernetes et du contrôleur ALB.

  • Redistribution : Application Gateway pour conteneurs redirige le trafic vers l’infrastructure dans les zones saines restantes.

Récupération de la zone

Application Gateway pour les conteneurs se remet automatiquement de problèmes sous-jacents. Azure gère le rétablissement de l’infrastructure de passerelle.

Tester les pannes de zone

La plateforme Application Gateway pour conteneurs gère le routage du trafic et la réponse aux défaillances de zone pour la passerelle elle-même. Vous n’avez pas besoin de lancer ou de gérer la réponse de la passerelle. Si vous disposez d'un cluster Kubernetes que vous gérez, vous pouvez utiliser Azure Chaos Studio pour tester la réponse du cluster aux défaillances de zone. Pour plus d’informations, consultez Test pour la résilience des zones de disponibilité.

Résilience aux défaillances à l’échelle de la région

Application Gateway pour conteneurs est un service à région unique. Si la région Azure où vous avez déployé une passerelle devient indisponible, cette passerelle n’est pas disponible.

Solutions multirégions personnalisées pour la résilience

Application Gateway pour conteneurs ne fournit pas de solution de déploiement ou de basculement multirégion intégrée. Pour se prémunir contre une panne régionale, déployez et configurez une passerelle distincte et un cluster Kubernetes dans chaque région. Vous êtes responsable d’acheminer le trafic entre les passerelles régionales et de configurer le basculement.

  • Configurez Application Gateway pour conteneurs de manière cohérente entre les régions. Pour simplifier les déploiements et maintenir les configurations alignées, définissez votre infrastructure en tant que code (IaC) à l’aide d’outils tels que Bicep ou Terraform.

  • Choisissez et configurez un service global de gestion du trafic, tel que Azure Front Door ou Azure Traffic Manager, pour diriger les clients vers vos passerelles régionales. Ces services utilisent différents modèles de routage et configurations de sonde d’intégrité. Configurez le service sélectionné pour diriger le trafic loin d’une passerelle indisponible et passez en revue sa documentation pour comprendre le comportement de routage et les considérations relatives au basculement. Azure Front Door fournit également des fonctionnalités telles que la protection par déni de service distribué (DDoS), les fonctionnalités de pare-feu d’applications web (WAF) et le routage basé sur des règles.

  • Déployez vos applications backend dans chaque région et configurez-les pour fournir des charges de travail opérationnelles lors d’une panne. Si vos applications dépendent de données ou d’autres services Azure, concevez et configurez également ces services pour la disponibilité multirégion. Passez en revue les conseils de fiabilité de chaque service pour comprendre ses options et limitations multirégions.

Sauvegarde et restauration

Application Gateway pour conteneurs ne stocke pas les données d’application. Azure Resource Manager stocke la configuration des ressources Azure de la passerelle. Vous pouvez recréer ces ressources en redéployant leur configuration.

Vous êtes responsable de la préservation de la configuration et des ressources Kubernetes qui définissent la façon dont la passerelle est déployée et achemine le trafic :

  • Définissez les ressources Azure et leurs paramètres sous forme d’infrastructure as code (IaC), tels que Bicep ou Terraform, et conservez les définitions dans le contrôle de version. Vous pouvez les utiliser pour redéployer les ressources de passerelle.

  • Sauvegardez les ressources Kubernetes qui configurent la passerelle, telles que les ressources ApplicationLoadBalancer, Gateway et HTTPRoute. Restaurez-les sur votre cluster lorsque vous devez recréer la configuration de routage.

  • Conservez la configuration associée, notamment les règles personnalisées et les stratégies de pare-feu d’applications web, dans le contrôle de version ou via votre processus de sauvegarde de configuration standard. Vous pouvez utiliser des pipelines de déploiement pour recréer les ressources Azure et Kubernetes de manière cohérente.

Résilience à la maintenance du service

Microsoft gère la maintenance d'Application Gateway pour conteneurs tout en conservant la haute disponibilité du service.

La taille minimale de sous-réseau requise de /24 pour chaque association tient compte des fenêtres de maintenance, vous n’avez donc pas besoin d’allouer d’espace d’adressage IP de sous-réseau supplémentaire pour la maintenance.

Pour plus d’informations, consultez Mise à l’échelle et disponibilité d’Application Gateway pour conteneurs.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Le contrat SLA Application Gateway pour les conteneurs mesure séparément le plan de contrôle et le plan de données. Les deux niveaux sont pris en compte dans le calcul global du contrat SLA.

Contenu connexe

  • Dernière mise à jour :