Partager via

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

  • Article

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.

Remarque

La pratique suivante a fait l'objet d'une révision interne et d'un examen approfondi conjointement avec nos partenaires Microsoft.

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 au niveau de la région. 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é. Grâce à cette solution, une seule instance d'Azure Container Registry est utilisée pour toutes les instances de Kubernetes dans le cluster. La géoréplication pour Azure Container Registry vous 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.

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 autre instance doit être recréée. Les probes liveness peuvent vérifier l'état de l'application ou du processus en cours d'exécution dans le pod. Si le pod ne répond pas, la probe liveness supprime le pod, ce qui oblige le ReplicaSet à créer une autre instance.

Pour plus d’informations, consultez ReplicaSet Kubernetes.

Pods d'applications (globaux)

Quand une région entière cesse d’être disponible, les pods du cluster ne sont plus disponibles pour traiter les requêtes. Dans ce cas, l'instance d'Azure Front Door achemine tout le trafic vers les régions saines restantes. Les clusters et pods Kubernetes de ces régions continuent à traiter les requêtes. Pour compenser l'augmentation du trafic et des requêtes vers le cluster restant, gardez à l'esprit les conseils suivants :

  • vérifiez que les ressources réseau et de calcul sont bien dimensionnées pour absorber les augmentations soudaines de trafic dues au basculement d'une région. Par exemple, quand vous utilisez Azure Container Network Interface (CNI), vérifiez que vous disposez d'un sous-réseau qui peut prendre en charge toutes les IP de pods faisant l'objet d'un pic de charge du trafic.
  • Utilisez la mise à l'échelle automatique horizontale de pods pour augmenter le nombre de réplicas de pod afin de répondre à l'augmentation de la demande régionale.
  • Utilisez la mise à l'échelle automatique de clusters AKS pour augmenter le nombre de nœuds d'instance de Kubernetes afin de répondre à l'augmentation de la demande régionale.

Pools de nœuds Kubernetes (régionaux)

Une défaillance localisée peut parfois se produire au niveau des ressources de calcul, par exemple une coupure de courant affectant un seul rack de serveurs Azure. Pour empêcher vos nœuds AKS de devenir un point de défaillance régionale unique, utilisez la fonctionnalité 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 défaillance régionale complète, Azure Front Door achemine le trafic vers les régions saines restantes. Une fois de plus, veillez à compenser l'augmentation du trafic et des requêtes à 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 dans le cadre 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 :