Vue d'ensemble de la solution de récupération d'urgence active/passive pour Azure Kubernetes Service (AKS)

Lorsque vous créez une application dans Azure Kubernetes Service (AKS) et que vous choisissez une région Azure lors de la création des ressources, il s'agit d'une application à région unique. Quand la région devient indisponible lors d’un sinistre, votre application le devient également. Si vous créez un déploiement identique dans une région Azure secondaire, votre application devient moins vulnérable à une catastrophe dans une seule région, ce qui garantit la continuité de l’activité. Grâce à une réplication des données entre les régions, vous pouvez récupérer le dernier état de l’application.

Ce guide décrit une solution de récupération d'urgence active-passive pour AKS. Nous déployons dans cette solution deux clusters AKS indépendants et identiques dans deux régions Azure appariées avec un seul cluster servant activement le trafic.

Vue d'ensemble de la solution active-passive

Cette approche de récupération d'urgence prévoit le déploiement de deux clusters AKS indépendants dans deux régions Azure. Toutefois, un seul des clusters sert activement le trafic à tout moment. Le cluster secondaire (qui ne sert pas activement le trafic) contient les mêmes données de configuration et d'application que le cluster principal. Cependant, il n'accepte aucun trafic, sauf s'il est dirigé par Azure Front Door Traffic Manager.

Scénarios et configurations

Cette solution est mieux implémentée lors de l'hébergement d'applications dépendantes de ressources, notamment des bases de données, qui servent activement le trafic dans une région. Dans les scénarios qui prévoient l'hébergement d'applications sans état déployées dans les deux régions, comme la mise à l'échelle horizontale, nous recommandons d'envisager une solution active/active, car la solution active/passive implique un temps de latence supplémentaire.

Composants

La solution de récupération d'urgence active/passive utilise de nombreux services Azure. Cet exemple d'architecture implique les composants suivants :

Plusieurs clusters et régions : vous déployez plusieurs clusters AKS, chacun dans une région Azure distincte. Lors des opérations normales, le trafic réseau est acheminé vers le cluster AKS principal défini dans la configuration d'Azure Front Door.

Configuration de la priorité accordée aux clusters : vous définissez un niveau de priorité entre 1 et 5 pour chaque cluster (1 étant la priorité la plus élevée et 5 la priorité la plus faible). Vous pouvez définir plusieurs clusters au même niveau de priorité et spécifier le poids de chaque cluster. Si le cluster principal se révèle indisponible, le trafic est automatiquement acheminé vers la région suivante sélectionnée dans Azure Front Door. Tout le trafic doit passer par Azure Front Door pour que ce système fonctionne.

Azure Front Door : Azure Front Door équilibre la charge et achemine le trafic vers l'instance Azure Application Gateway dans la région primaire (le cluster doit être marqué en 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.

Pour plus d'informations, consultez la Routage du trafic basé sur la priorité.

Paire hub-spoke : une paire hub-spoke est déployée pour chaque instance AKS régionale. Stratégies Azure Firewall Manager : elles gèrent les règles de pare-feu dans chaque région.

Key Vault : vous approvisionnez un Azure Key Vault dans chaque région pour stocker les secrets et les clés.

Log Analytics : les instances régionales de Log Analytics stockent les métriques réseau et les journaux de diagnostic régionaux. Une instance partagée stocke les métriques et les journaux de diagnostic pour toutes les instances AKS.

Container Registry : les images conteneur de la charge de travail sont stockées dans un registre de conteneurs managé. Avec cette solution, une seule instance Azure Container Registry est utilisée pour toutes les instances Kubernetes du cluster. La géoréplication pour Azure Container Registry vous permet de répliquer des images sur les régions Azure sélectionnées et fournit un accès continu à ces images, même si une région connaît une panne.

Processus de basculement

Si un service ou un composant de service n’est plus disponible dans une région, le trafic doit être acheminé 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, nous abordons les points de défaillance potentiels.

Pods d’applications (régionaux)

Un objet de déploiement Kubernetes crée plusieurs réplicas d’un pod (ReplicaSet). Si l’un d’eux n’est pas disponible, le trafic est acheminé entre les réplicas restants. Le ReplicaSet Kubernetes tente de maintenir opérationnels le nombre spécifié de réplicas. Si une instance tombe en panne, une nouvelle instance doit être recréée. Les probes liveness peuvent vérifier l’état de l’application ou du processus exécuté dans le pod. Si le pod ne répond pas, la probe liveness supprime le pod, ce qui oblige le ReplicaSet à créer une nouvelle 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 Azure Front Door achemine tout le trafic vers les régions saines restantes. Les clusters et pods Kubernetes de ces régions continuent à traiter les demandes. Pour compenser l’augmentation du trafic et des demandes vers le cluster restant, gardez à l’esprit les conseils suivants :

• Vérifiez que les ressources réseau et de calcul ont la bonne taille pour absorber les augmentations soudaines de trafic dues au basculement d’une région. Par exemple, quand vous utilisez Azure Container Network Interface (CNI), veillez à disposer 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 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.

Pools de nœuds Kubernetes (régionaux)

Une panne localisée peut parfois se produire au niveau des ressources de calcul, par exemple une coupure de courant affectant un 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. Les zones de disponibilité garantissent que les nœuds AKS de chaque zone de disponibilité sont physiquement séparés de ceux définis dans une autre zone de disponibilité.

Pools de nœuds Kubernetes (globaux)

En cas de panne régionale totale, Azure Front Door achemine le trafic vers les régions saines restantes. Une fois de plus, veillez à compenser l’augmentation du trafic et des demandes à destination du cluster restant.

Stratégie de test de basculement

Bien qu’il n’existe actuellement aucun mécanisme dans AKS pour supprimer une région entière d’un déploiement à des fins de test, Azure Chaos Studio permet de créer une expérience de chaos sur votre cluster.

Étapes suivantes

Si vous envisagez une solution différente, consultez les articles suivants :

• Vue d'ensemble de la solution de haute disponibilité active pour Azure Kubernetes Service (AKS)
• Vue d'ensemble de la solution passive à froid pour Azure Kubernetes Service (AKS)