Partage via

Vue d’ensemble de la solution haute disponibilité active/active recommandée 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 pendant la création des ressources, il s’agit d’une application à région unique. En cas de sinistre entraînant l’indisponibilité de la région, votre application devient également indisponible. 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.

Bien qu’il existe plusieurs modèles permettant de récupérer une solution AKS, ce guide décrit la solution haute disponibilité active/active recommandée pour AKS. Nous déployons dans cette solution deux clusters AKS indépendants et identiques dans deux régions Azure jumelées, les deux clusters traitant activement le trafic.

Remarque

Le cas d’usage suivant peut être considéré comme une pratique standard dans AKS. Il a fait l’objet d’une révision interne et d’un examen approfondi conjointement avec les partenaires de Microsoft.

Vue d’ensemble de la solution haute disponibilité active/active

Cette solution repose sur deux clusters AKS identiques configurés pour traiter activement le trafic. Vous placez un gestionnaire de trafic global, par exemple Azure Front Door, devant les deux clusters pour répartir le trafic entre eux. Vous devez toujours configurer les clusters pour héberger une instance de toutes les applications nécessaires au bon fonctionnement de la solution.

Les zones de disponibilité sont un autre moyen de garantir la haute disponibilité et la tolérance aux pannes pour votre cluster AKS au sein de la même région. Les zones de disponibilité vous permettent de répartir vos nœuds de cluster entre plusieurs emplacements isolés au sein d’une région Azure. De cette façon, si une zone tombe en panne en raison d’une coupure de courant, d’une défaillance matérielle ou d’un problème réseau, votre cluster peut continuer à s’exécuter et à traiter vos applications. Les zones de disponibilité améliorent également les performances et la scalabilité de votre cluster en réduisant la latence et la contention entre les nœuds. Pour configurer des zones de disponibilité pour votre cluster AKS, vous devez spécifier les numéros de zone lors de la création ou de la mise à jour de vos pools de nœuds. Pour plus d’informations, consultez Que sont les zones de disponibilité Azure ?

Remarque

De nombreuses régions prennent en charge les zones de disponibilité. Envisagez d’utiliser des régions avec des zones de disponibilité pour offrir plus de résilience et de disponibilité à vos charges de travail. Pour plus d’informations, consultez Récupérer après une interruption de service à l’échelle de la région.

Scénarios et configurations

Nous vous conseillons d’implémenter cette solution lorsque vous hébergez des applications sans état et/ou lorsque vous utilisez d’autres technologies également déployées dans les deux régions, telles que la mise à l’échelle horizontale. Dans les scénarios où l’application hébergée dépend de ressources, par exemple des bases de données, qui se trouvent activement dans une seule région, nous vous recommandons d’implémenter plutôt une solution active/passive. Une solution active/passive génère en effet plus de temps d’arrêt qu’une solution active/active, ce qui peut vous permettre de réaliser des économies.

Composants

La solution haute disponibilité active/active utilise de nombreux services Azure. Cette section couvre uniquement les composants propres à cette architecture multicluster. Pour plus d’informations sur les composants restants, consultez l’architecture de référence d’AKS.

Plusieurs clusters et régions : vous déployez plusieurs clusters AKS, chacun dans une région Azure distincte. En situation normale, votre configuration Azure Front Door achemine le trafic réseau entre toutes les régions. Si une région devient indisponible, le trafic est acheminé vers une région avec le temps de chargement le plus rapide pour l’utilisateur.

Réseau hub-and-spoke par région : une paire de réseaux hub-and-spoke régionaux est déployée pour chaque instance régionale d’AKS. Des stratégies Azure Firewall Manager gèrent les stratégies de pare-feu dans toutes les régions.

Magasin de clés régional : vous approvisionnez Azure Key Vault dans chaque région pour stocker les valeurs sensibles et les clés spécifiques à l’instance d’AKS ainsi que pour prendre en charge les services présents dans la région correspondante.

Azure Front Door : Azure Front Door équilibre la charge et achemine le trafic vers une instance régionale d’Azure Application Gateway qui se trouve devant chaque cluster AKS. Azure Front Door permet le routage global de la couche sept.

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é. Avec 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 et fournit 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 correctement 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. Là encore, 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 de 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 :