Fiabilité dans Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) est un service d’orchestration de conteneurs managé qui simplifie le déploiement, la gestion et les opérations de Kubernetes.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Azure Kubernetes Service (AKS) résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service (SLA) Azure Kubernetes Service (AKS).

Recommandations concernant le déploiement de production

Pour obtenir des recommandations sur le déploiement de charges de travail de production fiables dans AKS, consultez les articles suivants :

• Meilleures pratiques en matière de fiabilité de déploiement et de cluster pour AKS
• Vue d’ensemble de la haute disponibilité et de la récupération d’urgence (DR) pour AKS
• Considérations relatives à la résilience de zone pour AKS

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous créez un cluster AKS, la plateforme Azure crée et configure automatiquement :

• Plan de contrôle qui a le serveur d’API, etcd, le planificateur et d’autres pods requis pour gérer votre charge de travail.

• Un pool de nœuds système à votre abonnement qui héberge vos modules complémentaires et d’autres pods qui s’exécutent dans l’espace de noms kube-system.

Une fois cette configuration initiale du pool de nœuds terminée, vous pouvez ajouter ou supprimer des pools de nœuds pour vos propres charges de travail utilisateur. AKS ne gère pas les pools de nœuds pour la fiabilité et vous devez vous assurer que vos charges de travail sont résilientes aux défaillances de l’infrastructure.

La résilience est une responsabilité partagée entre vous et Microsoft. En tant que service de calcul, AKS gère certains aspects de la fiabilité de votre cluster, mais vous êtes responsable de la gestion d’autres aspects.

• Microsoft gère le plan de contrôle et d’autres composants managés d’AKS.

• C’est votre responsabilité de :

  • Définissez la façon dont les composants, y compris les pools de nœuds et les équilibreurs de charge qui s’attachent aux services, doivent être configurés pour répondre à vos exigences de fiabilité. Après avoir défini les composants, Microsoft les déploie et les gère en votre nom.

  • Gérez tous les composants en dehors du cluster AKS, y compris le stockage et les bases de données. Vérifiez que ces composants répondent à vos exigences de fiabilité. Lorsque vous déployez vos charges de travail, vérifiez que d’autres composants Azure sont également configurés pour la résilience en suivant les meilleures pratiques pour ces services.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des défaillances transitoires.

Lorsque vous utilisez AKS, des erreurs temporaires peuvent se produire en raison de plusieurs facteurs, notamment les crashs d'application, la mise à l'échelle et l'équilibrage des pods, les correctifs des nœuds et les défaillances d'infrastructure temporaires telles que des problèmes matériels ou de réseau.

Il est impossible d’éliminer toutes les erreurs temporaires, de sorte que les clients qui accèdent à vos applications hébergées par AKS doivent être prêts à réessayer les demandes ayant échoué et à suivre d’autres recommandations de gestion des erreurs temporaires. Vous pouvez réduire la probabilité d’erreurs temporaires et éviter ou atténuer les temps d’arrêt qu’ils peuvent provoquer en suivant Kubernetes et les meilleures pratiques Azure dans votre déploiement.

• Définissez des Budgets d’interruption de pod (PDB) dans le fichier YAML de votre pod afin de spécifier le nombre de pods devant rester dans un état Ready à tout moment. Lorsque vous définissez des PDB, AKS garantit une disponibilité minimale des réplicas lorsqu’il exécute des opérations pour isoler et vider les nœuds. Si une base de données PDB ne peut pas être satisfaite pendant les processus tels que les mises à niveau, le pod continue de fonctionner et l’opération peut échouer. Pour plus d’informations, consultez les PDB.
• Utilisez maxUnavailable pour définir le nombre maximal de réplicas qui peuvent devenir indisponibles à un moment donné. Par exemple, lorsque vous effectuez un redémarrage progressif, AKS garantit que pas plus que le nombre maxUnavailable de pods ne soient résiliés à un moment donné. Pour plus d’informations, consultez maxUnavailable.
• Suivez les meilleures pratiques de déploiement. Les réplicas de pod peuvent également échouer en raison de problèmes d’application. Pour plus d’informations, consultez les meilleures pratiques au niveau du déploiement pour la fiabilité du cluster AKS.

Remarque

Si vous souhaitez qu’AKS valide vos déploiements pour respecter les bonnes pratiques et fournir des notifications de blocage ou d’avertissement, vous pouvez utiliser des protections de déploiement. Les protections de déploiement sont une offre managée qui permet d’appliquer les meilleures pratiques de produit avant que votre code ne soit déployé sur le cluster.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Lorsque vous déployez un cluster AKS dans une région qui prend en charge les zones de disponibilité, différents composants nécessitent différents types de configuration.

Le plan de contrôle AKS est par défaut résilient aux zones. En cas d’échec d’une zone, le plan de contrôle ne nécessite aucune configuration ni gestion pour obtenir une résilience. Toutefois, la résilience du plan de contrôle n’est pas suffisante pour que votre cluster reste opérationnel lorsqu’une zone échoue. Pour le pool de nœuds système et les pools de nœuds utilisateur que vous déployez, vous devez activer la prise en charge des zones de disponibilité pour vous assurer que vos charges de travail sont résilientes aux défaillances de zone de disponibilité.

Spécifications

Prise en charge de la région : Vous pouvez déployer des clusters AKS résilients aux zones dans n’importe quelle région prenant en charge les zones de disponibilité.

Considérations

Pour améliorer la fiabilité et la résilience des charges de travail de production AKS dans une région, vous devez configurer AKS pour la redondance de zone en effectuant les configurations suivantes :

• Déployez plusieurs réplicas. Kubernetes répartit vos pods entre les nœuds en fonction des étiquettes de nœud. Pour répartir votre charge de travail entre les zones, vous devez déployer plusieurs réplicas de votre pod. Par exemple, si vous configurez le pool de nœuds avec trois zones mais que vous déployez une seule réplique de votre pod, votre déploiement n'est pas résilient aux zones.

• Activer la mise à l’échelle automatique. Les pools de nœuds Kubernetes fournissent des options de mise à l’échelle manuelles et automatiques. En utilisant la mise à l’échelle manuelle, vous pouvez ajouter ou supprimer des nœuds en fonction de vos besoins. Les pods en attente attendent que vous effectuiez un scale-up d’un pool de nœuds. La mise à l’échelle gérée par AKS utilise le dimensionnement automatique du cluster ou le provisionnement automatique de nœuds (NAP). AKS effectue un scale-up ou un scale-down du pool de nœuds en fonction des besoins du pod dans le quota et la capacité des références SKU de votre abonnement. Cette méthode permet de s’assurer que vos pods sont planifiés sur les nœuds disponibles dans les zones de disponibilité.

• Définissez les contraintes de topologie de pod. Utilisez des contraintes de répartition topologique des pods pour contrôler comment les pods sont répartis sur différents nœuds ou zones. Les contraintes vous aident à atteindre la haute disponibilité, la résilience et l’utilisation efficace des ressources. Si vous préférez répartir les pods strictement entre les zones, vous pouvez définir des contraintes pour forcer un pod dans un état en attente pour maintenir l’équilibre des pods entre les zones. Pour plus d’informations, consultez les contraintes de répartition de la topologie des pods.

• Configurez la mise en réseau à résilience de zone. Si vos pods servent du trafic externe, configurez votre architecture réseau de cluster à l’aide de services tels qu’Azure Application Gateway, Azure Load Balancer ou Azure Front Door.

• Vérifiez que les dépendances sont à résilience de zone. La plupart des applications AKS utilisent d’autres services pour le stockage, la sécurité ou la mise en réseau. Vérifiez que vous passez en revue les recommandations de résilience de zone pour ces services.

Coûts

Il n’existe aucun frais supplémentaire pour activer la prise en charge des zones de disponibilité dans AKS. Vous payez les machines virtuelles et d’autres ressources que vous déployez dans les zones de disponibilité.

Configurez la prise en charge des zones de disponibilité

• Créez un cluster AKS qui prend en charge la zone de disponibilité : Pour configurer la prise en charge des zones de disponibilité, consultez Créer un cluster Azure Kubernetes Service (AKS) qui utilise des zones de disponibilité.
• Migration: Vous ne pouvez pas activer la prise en charge des zones de disponibilité après avoir créé un cluster. Au lieu de cela, vous devez créer un cluster pour lequel la prise en charge de la zone de disponibilité est activée et supprimer le cluster existant.
• Désactiver la prise en charge des zones de disponibilité : Vous ne pouvez pas désactiver la prise en charge des zones de disponibilité après avoir créé un cluster. Au lieu de cela, vous devez créer un cluster avec prise en charge de la zone de disponibilité désactivée et supprimer le cluster existant.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque les clusters AKS sont configurés pour la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : Lorsque vous déployez un cluster AKS qui utilise des zones de disponibilité, il est important de s’assurer que vos composants réseau sont également résilients aux zones. Selon les équilibreurs de charge et d’autres composants réseau que vous utilisez, vous devrez peut-être configurer explicitement les composants pour router le trafic vers les nœuds appropriés dans les zones appropriées et répondre aux pannes de zone. Pour plus d’informations, consultez considérations relatives à la résilience de zone pour AKS.

• Réplication des données entre les zones : Si vous exécutez une charge de travail sans état, vous devez utiliser des services Azure gérés, tels que des bases de données Azure, azure Cache pour Redis ou Stockage Azure pour stocker les données de l’application. Vous pouvez utiliser ces services pour vous assurer que votre trafic peut être déplacé entre les nœuds et les zones sans risquer de perte de données ou affecter l’expérience utilisateur. Vous pouvez utiliser les déploiements, les services et les sondes d’intégrité Kubernetes pour gérer les pods sans état et garantir une distribution équilibrée entre les zones.

  Si vous devez stocker l’état au sein de votre cluster à l’aide de disques Azure, utilisez le stockage redondant interzone Azure pour vous assurer que vos données sont répliquées dans plusieurs zones de disponibilité. Pour plus d’informations, consultez Choisir le type de disque approprié en fonction des besoins de l’application.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsqu’une panne de zone de disponibilité se produit pendant que les clusters AKS sont configurés avec la prise en charge de la zone de disponibilité.

• Détection et réponse : lorsqu’une défaillance de zone se produit, le plan de contrôle bascule automatiquement. Si vos pools de nœuds utilisent des zones de disponibilité et respectent les meilleures pratiques en matière de résilience zonale, vous pouvez vous attendre à ce qu’AKS démarre les nœuds et les réplicas dans les zones opérationnelles. AKS effectue cette tâche automatiquement lorsque vous utilisez des solutions gérées, comme le mécanisme de mise à l’échelle automatique du cluster ou NAP. Sans mise à l’échelle automatique, les nœuds et les réplicas restent dans l’état En attente et attendent qu’une intervention manuelle effectue un scale-up du pool de nœuds.

  AKS tente également de rééquilibrer les pods entre les zones saines. Si vous choisissez de mettre à l’échelle manuellement votre pool de nœuds dans un scénario de défaillance de zone, vos pods peuvent rester En attente si aucun nœud n’est disponible dans les zones saines. L'extension dans les zones restantes est également soumise à la disponibilité du quota et de la capacité du SKU de la machine virtuelle que vous utilisez.

• Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  Vous pouvez également utiliser les métriques de santé de vos nœuds ou pods pour surveiller l’état de santé de vos nœuds et pods.

• Demandes actives : Toutes les demandes actives peuvent rencontrer des interruptions. Certaines requêtes peuvent échouer et la latence peut augmenter pendant que votre charge de travail bascule vers une autre zone.

• Perte de données attendue : Si vous stockez l’état au sein de votre cluster à l’aide de disques Azure et que vous utilisez le stockage redondant interzone, une défaillance de zone n’est pas censée entraîner une perte de données.

• Temps d’arrêt attendu : Si vous configurez correctement la résilience de zone pour votre cluster et vos pods, une défaillance de zone n’est pas censée entraîner un temps d’arrêt pour votre charge de travail AKS.

• Réacheminement du trafic : Les équilibreurs de charge redirigent de nouvelles requêtes entrantes vers des pods qui s’exécutent sur des nœuds sains.

Pour plus d’informations, consultez considérations relatives à la résilience de zone pour AKS.

Récupération de la zone

Lors de la récupération de la zone de disponibilité, le comportement de restauration automatique dépend du composant :

• Plan de contrôle : AKS restaure automatiquement les opérations du plan de contrôle dans toutes les zones de disponibilité. Aucune intervention manuelle n’est nécessaire.

• Pools de nœuds et nœuds : immédiatement après la restauration automatique, les nœuds restent dans les zones précédemment saines et ne sont pas restaurés dans la zone récupérée. Toutefois, la prochaine fois que vous effectuez une opération de mise à l’échelle des nœuds, par exemple lorsque vous effectuez un scale-out de votre pool de nœuds, le pool de nœuds peut créer des nœuds dans la zone récupérée.

• Pods : immédiatement après la restauration automatique, les pods continuent à s’exécuter sur les nœuds sur lesquels ils s’exécutent actuellement. Lorsque de nouveaux pods sont créés ou que des pods existants sont recréés, ils sont éligibles à l’utilisation des nœuds dans la zone récupérée.

• Stockage: Tout stockage attaché aux pods récupère en fonction du fonctionnement du stockage redondant interzone.

Tester les pannes de zone

Vous pouvez tester votre résilience aux défaillances de zone de disponibilité à l’aide des méthodes suivantes :

• Cordon et nœuds de drainage dans une seule zone de disponibilité
• Simuler un échec de zone de disponibilité à l’aide d’Azure Chaos Studio

Résilience aux défaillances à l’échelle de la région

Les clusters AKS sont des ressources à région unique. Si la région n’est pas disponible, votre cluster AKS n’est pas disponible également.

Solutions multirégions personnalisées pour la résilience

Si vous devez déployer votre charge de travail Kubernetes dans plusieurs régions Azure, vous avez deux options pour gérer l’orchestration de ces clusters.

• Utilisez Azure Kubernetes Fleet Manager si vous souhaitez une expérience managée plus simple. À l’aide d’Azure Kubernetes Fleet Manager, vous pouvez :

  • Gérez un ensemble de clusters AKS en tant qu’unité unique, et ces clusters peuvent être distribués dans plusieurs régions Azure.

  • Automatisez des aspects spécifiques de la gestion des clusters, tels que les mises à niveau des images de cluster et de nœud.

  • Utilisez les fonctionnalités de distribution du trafic pour répartir le trafic entre les clusters et basculer automatiquement si une région n’est pas disponible.

• Orchestrez le basculement à l’aide d’un modèle de déploiement actif/actif ou actif/passif manuel si votre charge de travail nécessite un contrôle plus nuancé sur les différents composants des basculements interrégionaux. Pour plus d’informations, consultez Vue d’ensemble de la haute disponibilité et de la récupération d’urgence pour AKS.

Sauvegarde et restauration

Sauvegarde Azure dispose d’une extension que vous pouvez utiliser pour sauvegarder des ressources de cluster AKS et des volumes persistants qui s’attachent au cluster. Le coffre de sauvegarde communique avec le cluster AKS via l’extension pour effectuer des opérations de sauvegarde et de restauration.

Si votre cluster AKS se trouve dans une région jumelée, vous pouvez configurer les sauvegardes à stocker dans un stockage géoredondant. Vous pouvez restaurer des sauvegardes géo-redondantes dans la région associée.

Pour plus d’informations, consultez les articles suivants :

• Qu’est-ce que la sauvegarde Azure Kubernetes Service ?
• Sauvegarder AKS à l’aide de Sauvegarde Azure

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Essayez d’utiliser des clusters sans état qui réduisent le besoin de sauvegarde. Stockez des données dans des systèmes de stockage externes et des bases de données au lieu de votre cluster.

Résilience à la maintenance du service

AKS effectue une maintenance sur votre cluster, y compris les mises à jour du cluster et des images de nœud. Pour vous assurer que, même pendant les mises à niveau, Kubernetes conserve le nombre minimal d’instances de pod requises pour servir votre trafic de production, vous devez configurer vos pods pour utiliser des budgets d’interruption de pod.

Pour réduire les interruptions de service pendant les périodes critiques, AKS fournit des contrôles afin de pouvoir spécifier des temps de maintenance planifiés. Pour plus d’informations, consultez Utiliser la maintenance planifiée pour planifier et contrôler les mises à niveau de votre cluster Azure Kubernetes Service.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

AKS fournit trois niveaux tarifaires pour la gestion des clusters : Gratuit, Standard et Premium. Le niveau Gratuit vous permet d’utiliser AKS pour tester vos charges de travail. Les niveaux Standard et Premium sont conçus pour les charges de travail de production. Lorsque vous déployez un cluster AKS sur lequel les zones de disponibilité sont activées, le pourcentage de temps d’activité défini dans le contrat SLA augmente. Toutefois, le contrat SLA s’applique uniquement si vous déployez un cluster dans le niveau tarifaire Standard ou Premium.

Contenu connexe

• Fiabilité dans Azure