Bonnes pratiques pour la continuité d’activité et la reprise d’activité dans AKS (Azure Kubernetes Services)
Quand vous gérez des clusters dans AKS (Azure Kubernetes Service), le temps de fonctionnement des applications s’avère important. Par défaut, AKS fournit une haute disponibilité en utilisant différents nœuds au sein d'un groupe de machines virtuelles identiques. Mais ces nœuds multiples ne protègent pas votre système contre une défaillance régionale. Pour optimiser votre temps de fonctionnement, soyez prévoyant pour assurer la continuité de l’activité et faire face à une situation de récupération d’urgence.
Cet article porte essentiellement sur la planification de la continuité d’activité et la récupération d’urgence dans AKS. Vous allez apprendre à effectuer les actions suivantes :
- Planifier des clusters AKS dans plusieurs régions.
- Router le trafic sur plusieurs clusters avec Azure Traffic Manager.
- Utiliser la géoréplication pour les registres d’images conteneur.
- Planifier l’état de l’application sur plusieurs clusters.
- Répliquer le stockage dans plusieurs régions.
Planifier le déploiement multirégion
Bonne pratique
Lorsque vous déployez plusieurs clusters AKS, choisissez des régions où AKS est disponible. Utilisez des régions jumelées.
Un cluster AKS est déployé dans une seule région. Pour protéger votre système contre la défaillance d’une région, déployez votre application sur plusieurs clusters AKS dans différentes régions. Pour savoir à quel emplacement déployer votre cluster AKS, tenez compte des points suivants :
-
- Choisissez des régions proches de vos utilisateurs.
- AKS s’étend en permanence à de nouvelles régions.
-
- Pour votre zone géographique, choisissez deux régions appairées.
- Les mises à jour de la plateforme AKS (maintenance planifiée) sont sérialisées avec un délai d’au moins 24 heures entre les régions jumelées.
- Les efforts de récupération pour les régions jumelées sont prioritaires quand cela est nécessaire.
Disponibilité du service
- Décidez si vos régions appairées doivent avoir un niveau de disponibilité chaud/chaud, chaud/tiède ou chaud/froid.
- Souhaitez-vous utiliser les deux régions en même temps, avec une région prête à commencer à traiter le trafic ? ou
- Souhaitez-vous donner à une région le temps de se préparer à traiter le trafic ?
La disponibilité des régions AKS et les régions appairées sont des questions qui vont de pair. Déployez vos clusters AKS sur des régions appairées conçues pour gérer ensemble la récupération d'urgence. Par exemple, AKS est disponible dans les régions USA Est et USA Ouest. Ces régions sont appairées. Choisissez ces deux régions si vous créez une stratégie AKS de continuité d’activité/récupération d’urgence (BC/DR).
Quand vous déployez votre application, ajoutez une autre étape à votre pipeline d’intégration continue/déploiement continu (CI/CD) pour effectuer le déploiement sur ces divers clusters AKS. La mise à jour de vos pipelines empêche le déploiement des applications dans une région et un cluster AKS particuliers. Dans ce cas, le trafic client dirigé vers une région secondaire ne recevra pas les dernières mises à jour de code.
Utiliser Azure Traffic Manager pour router le trafic
Bonne pratique
Pour optimiser les performances et la redondance, faites transiter l’ensemble du trafic d’application par Traffic Manager avant qu’il parvienne à votre cluster AKS.
Si vous disposez de plusieurs clusters AKS dans différentes régions, utilisez Traffic Manager pour contrôler le flux de trafic vers les applications exécutées dans chaque cluster. Azure Traffic Manager est un équilibreur de charge de trafic DNS qui peut répartir le trafic réseau entre les régions. Utilisez Traffic Manager pour acheminer les utilisateurs selon le temps de réponse des clusters ou en fonction de la propriété.
Si vous disposez d'un seul cluster AKS, vous vous connectez généralement à l'adresse IP du service ou au nom DNS d'une application donnée. Dans un déploiement impliquant plusieurs clusters, vous devez vous connecter à un nom DNS Traffic Manager qui pointe vers les services de chaque cluster AKS. Définissez ces services en utilisant des points de terminaison Traffic Manager. Chaque point de terminaison est l’adresse IP d’équilibreur de charge de service. Cette configuration vous permet de diriger le trafic réseau du point de terminaison Traffic Manager d’une région vers le point de terminaison d’une autre région.
Traffic Manager effectue des recherches DNS et renvoie votre point de terminaison le plus approprié. Avec le routage prioritaire, vous pouvez activer un point de terminaison de service principal et plusieurs points de terminaison de sauvegarde au cas où le point de terminaison principal ou l’un des points de terminaison de sauvegarde n’est pas disponible.
Pour savoir comment configurer des points de terminaison et le routage, consultez Configurer la méthode de routage du trafic basé sur la priorité dans Traffic Manager.
Routage d’applications avec Azure Front Door Service
Grâce au protocole anycast basé sur Split TCP, Azure Front Door Service connecte rapidement vos utilisateurs finaux au point de présence (POP) Front Door le plus proche. Autres fonctionnalités d'Azure Front Door Service :
- Arrêt TLS
- Domaine personnalisé
- Pare-feu d’applications web
- Réécriture d’URL
- Affinité de session
Passez en revue les besoins de trafic de votre application pour comprendre la solution qui est la plus adaptée.
Interconnecter des régions avec l’appairage de réseau virtuel global
Connectez les deux réseaux virtuels l'un à l'autre par le biais de l'appairage de réseaux virtuels pour permettre la communication entre les clusters. L'appairage de réseaux virtuels interconnecte les réseaux virtuels pour fournir une bande passante élevée à travers le réseau principal de Microsoft, même entre différentes régions géographiques.
Avant d'appairer des réseaux virtuels contenant des clusters AKS en cours d'exécution, utilisez Standard Load Balancer dans votre cluster AKS. Cette condition préalable rend les services Kubernetes accessibles via l'appairage de réseau virtuel.
Activer la géoréplication pour les images conteneur
Bonne pratique
Stockez vos images conteneur dans Azure Container Registry et géorépliquez le registre dans chaque région AKS.
Pour déployer et exécuter vos applications dans AKS, vous avez besoin d’un moyen de stocker et d’extraire les images conteneur. Container Registry s’intègre avec AKS, ce qui lui permet de stocker de manière sécurisée vos images conteneur ou graphiques Helm. Container Registry prend en charge la géoréplication multimaître pour répliquer automatiquement vos images dans les régions Azure à l’échelon mondial.
Pour améliorer les performances et la disponibilité, utilisez la géoréplication Container Registry pour créer un registre dans chaque région où vous avez un cluster AKS. Chaque cluster AKS extrait ensuite les images conteneur du registre de conteneurs local dans la même région.
L’utilisation de la géoréplication Container Registry pour extraire des images de la même région présente les avantages suivants :
- Plus rapides : vous extrayez les images à partir de connexions réseau haut débit et à faible latence dans la même région Azure.
- Plus fiables : Si une région n’est pas disponible, votre cluster AKS extrait les image auprès d’un registre de conteneurs disponible.
- Plus économiques : pas de frais de sortie de réseau entre les centres de données.
La géoréplication est une fonctionnalité des registres de conteneurs de la référence SKU Premium. Pour savoir comment configurer la géoréplication, consultez Géoréplication dans Container Registry.
Supprimer l’état du service des conteneurs
Bonne pratique
Évitez de stocker l'état du service à l'intérieur du conteneur. Utilisez plutôt une plateforme Azure en tant que service (PaaS) qui prend en charge la réplication multirégion.
L'état du service correspond aux données en mémoire ou sur disque nécessaires au bon fonctionnement du service. L’état comprend des variables membres et des structures de données que le service lit et écrit. Selon l'architecture du service, l'état peut aussi inclure des fichiers ou d'autres ressources stockés sur le disque, par exemple, les fichiers qu’utilise une base de données pour stocker les journaux de données et de transactions.
L'état peut être externalisé ou colocalisé avec le code qui le manipule. En règle générale, l’état est externalisé au moyen d’une base de données ou d’un autre magasin de données qui s’exécute sur différentes machines du réseau ou en dehors du processus sur la même machine.
Les conteneurs et microservices sont plus résilients quand les processus qui s’y exécutent ne conservent pas l’état. Étant donné que les applications contiennent presque toujours un état, utilisez une solution PaaS, telle que :
- Azure Cosmos DB
- Azure Database pour PostgreSQL
- Azure Database pour MySQL
- Azure SQL Database
Pour créer des applications portables, suivez les recommandations suivantes :
- The 12 -factor app methodology (méthodologie des applications à 12 facteurs)
- Exécuter une application web dans plusieurs régions Azure
Créer un plan de migration de stockage
Bonne pratique
Si vous utilisez Stockage Azure, préparez et testez la migration de votre stockage de la région principale vers la région de sauvegarde.
Vos applications peuvent utiliser Stockage Azure pour leurs données. Dans ce cas, vos applications sont réparties sur plusieurs clusters AKS de régions différentes. Le stockage doit rester synchronisé. Voici deux méthodes courantes pour répliquer le stockage :
- Réplication asynchrone basée sur l’infrastructure
- Réplication asynchrone basée sur l’application
Réplication asynchrone basée sur l’infrastructure
Vos applications peuvent nécessiter un stockage persistant même après la suppression d’un pod. Dans Kubernetes, vous pouvez utiliser des volumes persistants pour conserver le stockage de données. Ces volumes persistants sont montés sur une machine virtuelle de nœud, puis exposés aux pods. Les volumes persistants suivent les pods même si ceux-ci sont déplacés vers un autre nœud au sein du même cluster.
La stratégie de réplication que vous utilisez dépend de votre solution de stockage. Les solutions de stockage courantes suivantes fournissent toutes leurs propres recommandations en matière de récupération d'urgence et de réplication.
En général, vous fournissez un point de stockage commun où les applications écrivent leurs données. Ces données sont ensuite répliquées entre les régions et rendues accessibles localement.
Si vous utilisez Disques managés Azure, vous pouvez utiliser Velero sur Azure et Kasten pour gérer la réplication et la récupération d'urgence. Ces options sont des solutions de sauvegarde natives du système Kubernetes, mais non prises en charge par celui-ci.
Réplication asynchrone basée sur l’application
Kubernetes ne propose actuellement aucune implémentation native pour la réplication asynchrone basée sur l’application. Dans la mesure où les conteneurs et Kubernetes sont faiblement couplés, toute approche traditionnelle basée sur l'application ou le langage doit fonctionner. En règle générale, les applications elles-mêmes répliquent les demandes de stockage, qui sont ensuite écrites dans le stockage de données sous-jacent de chaque cluster.
Étapes suivantes
Cet article porte essentiellement sur les considérations relatives à la continuité d’activité et à la récupération d’urgence pour les clusters AKS. Pour plus d’informations sur les opérations liées aux clusters dans AKS, consultez ces articles relatifs aux bonnes pratiques :