Disponibilité des applications dans AKS activée par Azure Arc

S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server

Azure Kubernetes Service (AKS) activé par Azure Arc offre une plateforme de conteneurs entièrement prise en charge qui peut exécuter des applications cloud natives sur la plateforme d’orchestration de conteneurs Kubernetes. L’architecture prend en charge l’exécution de charges de travail Windows et Linux virtualisées.

L’architecture AKS est générée avec le basculement clustering et la migration dynamique qui est automatiquement activée pour les clusters cibles (charge de travail). Pendant différents événements d’interruption, les machines virtuelles qui hébergent les charges de travail des clients sont librement déplacées sans temps d’arrêt perçu au niveau des applications. Cette architecture signifie qu’un client d’entreprise traditionnel, qui gère une application héritée en tant que singleton à AKS sur Azure Stack HCI ou Windows Server, bénéficie d’un temps de fonctionnement similaire (ou meilleur) à celui actuellement rencontré sur une application de machine virtuelle héritée.

Cet article décrit certains concepts fondamentaux pour les utilisateurs qui souhaitent exécuter des applications conteneurisées sur AKS Arc avec la migration dynamique activée afin de s’assurer que les applications sont disponibles pendant une interruption. La terminologie Kubernetes, comme interruptions volontaires et interruptions involontaires, est utilisée pour faire référence aux temps d’arrêt d’une application s’exécutant dans un pod.

Qu'est-ce que la migration dynamique ?

La migration dynamique est une fonctionnalité Hyper-V qui vous permet de déplacer en toute transparence des machines virtuelles en cours d’exécution d’un hôte Hyper-V vers un autre, sans temps d’arrêt perçu. Le principal avantage de la migration dynamique est la flexibilité ; l’exécution de machines virtuelles n’est pas liée à une seule machine hôte. Cela permet aux utilisateurs d’effectuer des actions telles que le drainage d’un hôte spécifique de machines virtuelles avant de désactiver ou de mettre à niveau l’hôte. Lorsqu’elle est associée au clustering de basculement Windows, la migration dynamique permet la création de systèmes hautement disponibles et tolérants aux pannes.

L’architecture actuelle d’AKS sur Azure Stack HCI et Windows Server suppose que vous avez activé la migration dynamique dans votre environnement en cluster Azure Stack HCI. Par conséquent, toutes les machines virtuelles de nœud Worker Kubernetes sont créées avec la migration dynamique configurée. Ces nœuds peuvent être déplacés autour des hôtes physiques en cas d’interruption pour garantir la haute disponibilité de la plateforme.

Lorsque vous exécutez une application héritée en tant que singleton sur Kubernetes, cette architecture répond à vos besoins de haute disponibilité. Kubernetes gère la planification des pods sur les nœuds Worker disponibles, tandis que la migration dynamique gère la planification des machines virtuelles de nœud Worker sur les hôtes physiques disponibles.

Scénarios d’interruption d’application

Une étude comparative des temps de récupération pour les applications s’exécutant sur des machines virtuelles et AKS sur Azure Stack HCI et Windows Server indique clairement que l’impact sur l’application est minimal quand des événements d’interruption courants se produisent. Voici trois exemples de scénarios d’interruption :

• Application d’une mise à jour entraînant un redémarrage de la machine physique.
• Application d’une mise à jour impliquant la recréation du nœud Worker.
• Défaillance matérielle non planifiée d’une machine physique.

Notes

Ces scénarios partent du principe que le propriétaire de l’application utilise toujours les paramètres d’affinité et d’anti-affinité de Kubernetes pour garantir une bonne planification des pods sur les nœuds Worker.

Événement d’interruption	Exécution d’applications dans des machines virtuelles sur Azure Stack HCI	Exécution d’applications dans des machines virtuelles sur AKS sur Azure Stack HCI ou Windows Server
Appliquer une mise à jour qui entraîne un redémarrage de la machine physique	Aucun impact	Aucun impact
Appliquer une mise à jour qui implique la recréation du nœud Worker (ou le redémarrage de la machine virtuelle)	Aucun impact	Variable
Défaillance matérielle non planifiée d’une machine physique	6-8 minutes	6-8 minutes

Appliquer une mise à jour qui entraîne un redémarrage de la machine physique

Durant un événement de maintenance de l’hôte physique, comme l’application d’une mise à jour entraînant le redémarrage d’un ordinateur hôte, aucun impact n’est attendu pour les applications s’exécutant dans le cluster. L’administrateur de cluster draine l’hôte et s’assure que toutes les machines virtuelles sont migrées en direct avant d’appliquer la mise à jour.

Appliquer une mise à jour qui implique la recréation du nœud Worker

Ce scénario implique l’arrêt de la machine virtuelle d’un nœud Worker pour effectuer une maintenance de routine. Pour préparer la mise à jour, l’administrateur de cluster draine et isole le nœud, afin que tous les pods soient supprimés vers un nœud Worker disponible avant d’appliquer les mises à jour. Une fois la mise à jour terminée, le nœud Worker est joint et mis à disposition pour la planification.

Notes

La disponibilité d’une application varie, car elle inclut le temps nécessaire pour télécharger l’image conteneur de base, en particulier pour les images plus volumineuses stockées dans le cloud public. Par conséquent, il est recommandé d’utiliser de petites images conteneur de base, et pour les conteneurs Windows, il est recommandé d’utiliser l’image nano server de base.

Défaillance matérielle non planifiée d’une machine physique

Dans ce scénario, un événement d’interruption involontaire se produit sur une machine physique hébergeant le conteneur/pod d’une application héritée dans l’une des machines virtuelles du nœud Worker. Le basculement clustering place l’hôte dans un état isolé, puis, après une période de 6 à 8 minutes, démarre le processus de migration dynamique de ces machines virtuelles vers des hôtes survivants. Dans ce cas, le temps d’arrêt de l’application est l’équivalent du temps nécessaire au redémarrage des machines virtuelles du nœud hôte et worker.

Conclusion

Les technologies de clustering de basculement AKS sont conçues pour garantir que les environnements informatiques dans Azure Stack HCI et Windows Server sont hautement disponibles et tolérants aux pannes. Toutefois, le propriétaire de l’application doit toujours configurer les déploiements pour qu’ils utilisent les fonctionnalités Kubernetes, comme Deployments, Affinity Mapping et RelicaSets, afin de garantir la résilience des pods dans des scénarios d’interruption.

Étapes suivantes

Vue d’ensemble d’AKS sur Windows Server et Azure Stack HCI