Partager via

Vue d’ensemble d’une solution passive-froide 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. 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 passive-froide 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 lorsque l’application est sollicitée.

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 passive-froide

Dans cette approche, nous avons deux clusters AKS indépendants déployés dans deux régions Azure. Lorsque l’application est sollicitée, nous activons le cluster passif pour recevoir le trafic. Si le cluster passif tombe en panne, nous devons activer manuellement le cluster froid pour prendre en charge le flux du trafic. Nous pouvons définir cette condition par le biais d’une entrée manuelle à chaque fois ou pour spécifier un événement en particulier.

Scénarios et configurations

Cette solution est parfaite pour être implémentée en « cas de besoin », car elle est utile dans les scénarios où des charges de travail doivent être exécutées à des moments précis de la journée ou à la demande. Voici quelques exemples de cas d’usage pour une approche passive-froide :

  • Une usine qui a besoin d’exécuter une simulation complexe et gourmande en ressources sur un grand jeu de données. Dans ce cas, le cluster passif se trouve dans une région cloud qui offre des services de calcul et de stockage hautes performances. Le cluster passif est utilisé uniquement lorsque la simulation est déclenchée par l’utilisateur ou par une planification. Si le cluster ne fonctionne pas lors du déclenchement, le cluster froid peut être utilisé comme solution de secours et la charge de travail peut s’y exécuter en remplacement.
  • Un organisme public qui a besoin de maintenir une sauvegarde de ses systèmes et données critiques en cas de cyberattaque ou de catastrophe naturelle. Dans ce cas, le cluster passif se trouve dans un emplacement sécurisé et isolé qui n’est pas accessible au public.

Composants

La solution de récupération d’urgence passive-froide 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. Lorsque l’application est sollicitée, le cluster passif est activé pour recevoir le trafic réseau.

Coffre de clés : vous provisionnez un coffre de clés Azure 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.

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.

Registre de conteneurs : 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 le cluster passif ne fonctionne pas correctement en raison d’un problème dans sa région Azure spécifique, vous pouvez activer le cluster froid et rediriger tout le trafic vers la région de ce cluster. Vous pouvez utiliser ce processus pendant que le cluster passif est désactivé jusqu’à ce qu’il redémarre. Le cluster froid peut prendre quelques minutes à venir en ligne, car il a été désactivé et doit effectuer le processus d’installation. Cette approche n’est pas idéale pour les applications où le temps est compté. Dans ce cas, nous vous recommandons d’envisager un basculement actif-actif.

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 réfléchissez à une autre solution, consultez les articles suivants :