Comment résoudre les problèmes courants liés aux échecs de mise à jour des groupes de nœuds Amazon EKS ?

Brève description

Les nouvelles versions d'Amazon EKS incluent également de nouvelles versions d'Amazon AMI pour les mises à jour des groupes de nœuds. Les clients dont la charge de travail est déployée sur plusieurs groupes de nœuds sont confrontés à la difficulté de mettre à jour leurs nœuds pour suivre leur cycle de publication.

Lorsque vous lancez une mise à jour d'un groupe de nœuds géré, Amazon EKS met automatiquement à jour vos nœuds pour vous. Si vous utilisez une AMI optimisée pour Amazon EKS, Amazon EKS applique automatiquement les derniers correctifs de sécurité et mises à jour du système d'exploitation à vos nœuds dans le cadre de la dernière version de l'AMI. Pour implémenter la mise à jour, AWS Auto Scaling lance les nœuds dans chaque zone de disponibilité où les nœuds sont présents dans le groupe de nœuds. Ce service rééquilibre également la zone de disponibilité. Comme les nœuds existants ne sont vidés qu'une seule fois, l'étape de lancement est réussie. La phase de réduction réduit la taille maximale et la taille souhaitée du groupe Auto Scaling d'une unité pour revenir aux valeurs d'avant la mise à jour. Reportez-vous à la section « Phase de réduction » dans Comportement de mise à jour des nœuds gérés pour plus d'informations.

Résolution

Au cours de ce processus de mise à jour, il est possible que vous rencontriez certaines des erreurs suivantes, qui nécessitent des mesures d'atténuation particulières. Le fait de connaître ces problèmes à l'avance vous permet de réduire les temps d'arrêt. Reportez-vous à la section Comportement de mise à jour des nœuds gérés pour plus d'informations sur les erreurs de mise à jour.

La mise à jour a échoué à cause de PodEvictionFailure

Error message : Reached max retries while trying to evict pods from nodes in node group.

Cette erreur indique que la mise à jour est bloquée par PoDevictionFailure. Si les pods ne quittent pas le nœud dans les 15 minutes et qu'il n'y a pas d'indicateur de force, la phase de mise à jour échoue en indiquant PoDevictionFailure.

Voici les raisons de l'erreur PoDeCtionFailure lors de la phase de mise à jour :

PDB agressif (budget de perturbation de pod)

Un PDB agressif est défini sur le pod lorsque plusieurs PDB pointent vers le même pod.

PDB indique le nombre de perturbations qui peuvent être tolérées à un moment donné pour une classe de pods (un budget de fautes). Lorsqu'une perturbation volontaire fait chuter les pods d'un service en dessous du budget, l'opération s'interrompt jusqu'à ce qu'elle puisse maintenir le budget. L'événement de vidange des nœuds s'arrête temporairement jusqu'à ce que d'autres pods soient disponibles afin que le budget ne soit pas dépassé par l'expulsion des pods. Pour plus d'informations, veuillez consulter la section Perturbations sur le site Web de Kubernetes.

Pour confirmer le bon déroulement de la mise à jour des groupes de nœuds gérés, vous devez soit supprimer temporairement les budgets de perturbation des pods, soit utiliser l'option Forcer la mise à jour. Cette option ne respecte pas les budgets de perturbation des pods. Cette option implémente plutôt les mises à jour en forçant les nœuds à redémarrer.

Remarque : si l'application est une application basée sur Quorum, l'option force peut rendre l'application temporairement indisponible.

Exécutez la commande suivante pour vérifier que les PDB sont configurés dans votre cluster :

$ kubectl get pdb --all-namespaces

Ou, si vous avez activé la journalisation des audits dans la console Amazon EKS, procédez comme suit :

1.    Dans l'onglet Clusters, choisissez le cluster souhaité (par exemple, rpam-eks-qa2-control-plane) dans la liste.

2.    Dans l'onglet Journalisation, choisissez Audit. Cela vous redirige vers la console Amazon CloudWatch.

3.    Dans la console CloudWatch, sélectionnez Journaux. Choisissez ensuite Log Insights et exécutez la requête suivante :

fields @timestamp, @message
| filter @logStream like "kube-apiserver-audit"
| filter ispresent(requestURI)
| filter objectRef.subresource = "eviction" 
| display @logStream, requestURI, responseObject.message
| stats count(*) as retry by requestURI, responseObject.message

4.    Sélectionnez Personnalisé en haut à droite pour identifier la date de la mise à jour. En cas d'échec de la mise à jour d'un groupe de nœuds en raison d'un PDB agressif, ResposeObject.message décrit la raison de l'échec de l'expulsion du pod.

5.    Si le PDB est à l'origine de la panne, modifiez-le à l'aide de la commande suivante. Ensuite, mettez à nouveau à jour le groupe de nœuds :

$ kubectl edit pdb pdb_name;

Déploiement tolérant tous les rejets

Après l'expulsion de chaque pod, le nœud devient vide car il a été rejeté lors des étapes précédentes. Toutefois, si le déploiement tolère toutes les rejets, il est plus probable que le nœud ne soit pas vide, ce qui entraînera l'échec de l'expulsion du pod. Pour plus d'informations, consultez la section Rejets et tolérances sur le site Web de Kubernetes.

La mise à jour a échoué en raison d'une version de publication non valide

Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx.

Pour résoudre ce problème, exécutez à nouveau la commande de mise à jour. Cette commande met à jour les groupes de nœuds vers la même version que la version Kubernetes du plan de contrôle :

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

Remarque : remplacez la version 1.xx par la version prise en charge par le plan de contrôle Amazon EKS.

La mise à jour a échoué car le groupe de nœuds présente des problèmes de santé

Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]

Cet échec se produit si vous avez modifié manuellement le groupe Auto Scaling du groupe de nœuds pour utiliser une version différente de son modèle de lancement Amazon Elastic Compute Cloud (Amazon EC2). Vous avez peut-être également supprimé la version du modèle associée au groupe de nœuds. Le groupe de nœuds EKS utilise un modèle de lancement par défaut qui entre en conflit avec le modèle de lancement du groupe Auto Scaling. Ce modèle de lancement permet à EKS d'afficher le groupe de nœuds comme étant dégradé.

Si vous n'avez pas encore supprimé le modèle de lancement, remplacez manuellement la version du modèle de lancement du groupe Auto Scaling par la version appropriée. Cette action ramène le groupe de nœuds à un état sain et actif. Vous pouvez maintenant relancer le processus de mise à jour.

---