Partager via


Réparation automatique des nœuds AKS

Azure Kubernetes Service (AKS) surveille en permanence l’état d’intégrité des nœuds Worker et effectue une réparation automatique des nœuds s’ils ne sont pas sains. La plateforme de machines virtuelles Azure effectue la maintenance des machines virtuelles qui rencontrent des problèmes. AKS et les machines virtuelles Azure opèrent ensemble pour réduire les interruptions de service pour vos clusters.

Dans cet article, vous découvrirez comment la fonctionnalité de réparation automatique des nœuds fonctionne pour les nœuds Windows et Linux.

Comment AKS vérifie les nœuds NotReady

AKS utilise les règles suivantes pour déterminer si un nœud est dans un état non sain et nécessite une réparation :

  • Le nœud signale l’état NotReady lors de vérifications consécutives sur une période de 10 minutes.
  • Le nœud ne signale aucun état pendant 10 minutes.

Vous pouvez vérifier manuellement l’état d’intégrité de vos nœuds avec la commande kubectl get nodes.

Fonctionnement de la réparation automatique

Notes

AKS lance des opérations de réparation avec le compte d’utilisateur aks-remediator.

Si AKS identifie un nœud qui reste non sain pendant au moins cinq minutes, AKS effectue les actions suivantes :

  1. AKS redémarre le nœud.
  2. Si le nœud reste non sain après la réinitialisation, AKS réinitialise le nœud.
  3. Si le nœud reste non sain après la réinitialisation et qu’il s’agit d’un nœud Linux, AKS redéploie le nœud.

AKS retente le redémarrage, la réinitialisation et la séquence de redéploiement jusqu’à trois fois si le nœud reste non sain. Le processus global de réparation automatique peut prendre jusqu’à une heure.

Limites

La réparation automatique des nœuds AKS est un service d’effort optimal et nous ne garantissons pas la restauration du nœud à un état sain. Si votre nœud reste dans un état non sain, nous vous encourageons vivement à effectuer un examen manuel du nœud. En savoir plus sur la résolution des problèmes liés à l’état NotReady du nœud.

Il existe des cas où AKS n’effectue pas de réparation automatique. L’échec de la réparation automatique du nœud peut se produire par conception ou si Azure ne peut pas détecter qu’un problème existe. Voici quelques exemples de cas où la réparation automatique n’est pas effectuée :

  • Un état de nœud n’est pas signalé en raison d’une erreur dans la configuration réseau.
  • Un nœud n’a pas pu s’inscrire initialement en tant que nœud intègre.
  • Si l’une des teintes suivantes est présente sur le nœud : node.cloudprovider.kubernetes.io/shutdown, ToBeDeletedByClusterAutoscaler.

Surveiller la réparation automatique des nœuds à l’aide d’événements Kubernetes

Lorsque AKS effectue une réparation automatique des nœuds sur votre cluster, AKS émet des événements Kubernetes à partir de la source aks-auto-repair pour la visibilité. Les événements suivants s’affichent sur un objet de nœud lorsque la réparation automatique se produit.

Pour en savoir plus sur l’accès, le stockage et la configuration des alertes sur les événements Kubernetes, consultez Utiliser des événements Kubernetes pour la résolution des problèmes dans Azure Kubernetes Service.

Motif Message d'événement. Description
NodeRebootStart La réparation automatique des nœuds lance une action de redémarrage en raison de la persistance de l’état NotReady pendant plus de 5 minutes. Cet événement est émis pour vous avertir lorsque votre nœud est sur le point d’être redémarré. Cette action est la première dans la séquence globale de réparation automatique des nœuds.
NodeRebootEnd L’action de redémarrage de la réparation automatique des nœuds est terminée. Émis une fois le redémarrage terminé sur le nœud. Cet événement n’indique pas l’état d’intégrité (sain ou non sain) du nœud après le redémarrage.
NodeReimageStart La réparation automatique des nœuds lance une action de réinitialisation en raison de la persistance de l’état NotReady pendant plus de 5 minutes. Cet événement est émis pour vous avertir lorsque votre nœud est sur le point d’être réinitialisé.
NodeReimageEnd L’action de réinitialisation de la réparation automatique des nœuds est terminée. Émis une fois la réinitialisation terminée sur le nœud. Cet événement n’indique pas l’état d’intégrité (sain ou non sain) du nœud après la réinitialisation.
NodeRedeployStart La réparation automatique des nœuds lance une action de redéploiement en raison de la persistance de l’état NotReady pendant plus de 5 minutes. Cet événement est émis pour vous avertir lorsque votre nœud est sur le point d’être redéployé. Le redéploiement est la dernière action de la séquence de réparation automatique des nœuds.
NodeRedeployEnd L’action de redéploiement de la réparation automatique du nœud est terminée. Émis une fois le redéploiement terminé sur le nœud. Cet événement n’indique pas l’état d’intégrité (sain ou non sain) du nœud après le redéploiement.

Si des erreurs se produisent pendant le processus de réparation automatique des nœuds, les événements suivants sont émis avec le message d’erreur détaillé. En savoir plus sur la résolution des erreurs courantes de réparation automatique des nœuds.

Remarque

Le code d’erreur dans les messages d’événement suivants varie en fonction de l’erreur signalée.

Motif Message d'événement. Description
NodeRebootError Échec de l’action de redémarrage de la réparation automatique des nœuds en raison d’un échec d’une opération. Consultez les détails de l’erreur ici : Code d’erreur Émis en cas d’erreur avec l’action de redémarrage.
NodeReimageError Échec de l’action de réinitialisation de la réparation automatique des nœuds en raison d’un échec d’une opération. Consultez les détails de l’erreur ici : Code d’erreur Émis en cas d’erreur avec l’action de réinitialisation.
NodeRedeployError L’action de redéploiement de la réparation automatique des nœuds a échoué en raison d’un échec d’une opération. Consultez les détails de l’erreur ici : Code d’erreur Émis en cas d’erreur avec l’action de redéploiement.

Étapes suivantes

Par défaut, vous pouvez accéder aux événements et journaux Kubernetes sur votre cluster AKS de la dernière heure. Pour stocker et interroger des événements et des journaux des 90 derniers jours, activez Container Insights pour une résolution plus approfondie des problèmes sur votre cluster AKS.