Comment lancer la résolution des problèmes de mise à jour des groupes de nœuds gérés pour Amazon EKS ?

Lecture de 7 minute(s)
0

J'essaie de mettre à jour mon groupe de nœuds géré par Amazon Elastic Kubernetes Service (Amazon EKS) et je rencontre des problèmes.

Brève description

Lorsque vous mettez à jour votre groupe de nœuds gérés Amazon EKS, vous pouvez recevoir l'une des erreurs suivantes :

  • « PodEvictionFailure a atteint le nombre maximum de tentatives lors de la tentative d'expulsion des pods des nœuds du groupe de nœuds nodegroup-1234 »
  • « Erreur : L'état du groupe de nœuds présente des problèmes autres que des échecs lors du lancement d'une instance ASG, un dépassement de la limite d'instances, des adresses libres insuffisantes, un groupe inaccessible »
  • « Erreur : InvalidParameterException : Les détails du modèle de lancement ne peuvent pas être nuls pour le groupe de nœuds de type ami personnalisé »

          -ou-

        « Une erreur s'est produite (InvalidParameterException) lors de l'appel de l'opération UpdateNodegroupVersion : Tu ne peut pas spécifier le champ « KubernetesVersion » lorsque vous utilisez des AMI personnalisées

  • « UPDATE_FAILED Le gestionnaire de ressources a renvoyé le message suivant : La version 1.xx demandée n'est pas valide pour la version 1.yy de kubernetes »

Résolution

Pour résoudre les erreurs de mise à jour des groupes de nœuds gérés par Amazon EKS, suivez ces étapes pour des résolution des problèmes.

Remarque : Si des erreurs surviennent lors de l’exécution des commandes de l’interface de la ligne de commande (AWS CLI), vérifiez que vous utilisez la version la plus récente d’AWS CLI.

PodEvictionFailure a atteint le nombre maximum de tentatives lors de la tentative d'expulsion des pods des nœuds du groupe de nœuds nodegroup-1234

L'erreur PodEvictionFailure se produit lorsque la mise à niveau ne parvient pas à vider tous les pods du nœud. Si un budget d'interruption des pods (PDB) empêche les pods d'être vidés du nœud, cela peut être à l'origine du problème. Par exemple, si une application possède une PDB de deux, au moins deux pods doivent être en cours d'exécution pour cette application.

Pour vérifier si votre application utilise une PDB, exécutez la commande kubectl suivante :

$ kubectl get pdb —all-namespaces

Si vous utilisez une PDB, effectuez l'une des actions suivantes :

L'option de mise à jour forcée ne reconnaît pas les PDB. Les mises à jour se produisent indépendamment des problèmes liés à la PDB en forçant le nœud à redémarrer.

**Remarque :**Si les pods d'un contrôleur Kubernetes ne sont pas répartis entre les nœuds, cette option peut entraîner des temps d'arrêt pour vos applications.

Pour utiliser l'option force, exécutez la commande AWS CLI similaire à la suivante :

$ aws eks update-nodegroup-version --cluster-name cluster-123 --nodegroup-name nodegroup-1234 --force

-ou-

Exécutez la commande eksctl suivante :

$ eksctl upgrade nodegroup --cluster OneCluster --name managed-ng --force-upgrade

Résolution des problèmes d'éviction de PodDisruptionBudget avec CloudWatch Logs Insights

Vous pouvez utiliser Amazon CloudWatch Logs Insights pour effectuer des recherches dans les données du journal du plan de contrôle Amazon EKS. Pour plus d'informations, consultez la section Analyse des données des journaux avec CloudWatch Logs Insights.

Important : Vous pouvez consulter les événements du journal dans CloudWatch Logs uniquement après avoir activé la journalisation du plan de contrôle dans un groupe. Avant de sélectionner une plage de temps pour exécuter des requêtes dans CloudWatch Logs Insights, vérifiez que vous avez activé la journalisation du plan de contrôle. Pour plus d'informations, consultez la section Comment puis-je récupérer les journaux du plan de contrôle Amazon EKS à partir de CloudWatch Logs ?

Pour identifier le pod dont l'expulsion a échoué et le nombre d'échecs, exécutez une requête similaire à la suivante :

fields @timestamp, @message
| stats count(*) as count by objectRef.name
| filter @logStream like /audit/
| filter user.username == "eks:node-manager" and requestURI like "eviction" and requestURI like "pod" and responseStatus.code > 400
| sort count desc

Le nombre maximum de nouvelles tentatives pour un pod d'expulsion est de 20. Si le nombre d'échecs d'un pod affiché est supérieur ou égal à 20 échecs, il s'agit du pod dont l'expulsion a échoué.

Pour identifier le nom du budget d'interruption du pod qui empêche l'expulsion du pod précédent, exécutez la requête suivante.

filter @logStream like /^kube-apiserver-audit/
  | fields @logStream, @timestamp, @message
  | sort @timestamp desc
  | filter user.username == "eks:node-manager" and requestURI like "eviction" and requestURI like "pod_name" and responseStatus.code > 400
  | limit 999
  | display responseObject.details.causes.0.message,objectRef.name,objectRef.namespace,objectRef.resource

Remarque : Remplacez pod_name par le nom de votre pod.

La sortie contient un message similaire au suivant, où pod_distruption_budget est l'objet à l'origine des échecs d'expulsion :

The disruption budget pod_distruption_budget needs 1 healthy pods and has 1 currently

Erreur : L'état du groupe de nœuds présente des problèmes autres que des échecs lors du lancement d'une instance ASG, un dépassement de la limite d'instances, des adresses libres insuffisantes, un cluster inaccessible

Si vous recevez ce message d'erreur, vérifiez les détails du groupe de nœuds gérés et localisez les problèmes de santé. Pour plus d'informations et la résolution des problèmes, consultez les erreurs liées aux groupes de nœuds gérés et consultez la référence de l'API Amazon EKS issue.

Erreur : InvalidParameterException : Les détails du modèle de lancement ne peuvent pas être nuls pour un groupe de nœuds de type ami personnalisé

-ou-

Une erreur s'est produite (InvalidParameterException) lors de l'appel de l'opération UpdateNodegroupVersion : Vous ne pouvez pas spécifier le champ KubernetesVersion lorsque vous utilisez des AMI personnalisées.

Pour les groupes de nœuds gérés dotés d'une AMI personnalisée, vous devez créer une nouvelle version d'AMI avec la version de Kubernetes vers laquelle vous souhaitez effectuer la mise à niveau. Pendant la mise à niveau, spécifiez le modèle de lancement et la version.

Si vous utilisez l'interface de ligne de commande AWS, utilisez l'indicateur --launch-template. Pour eksctl, utilisez le drapeau --launch-template-version.

Remarque : Évitez d'utiliser l'indicateur --kubernetes-version avec ces commandes.

UPDATE_FAILED Le gestionnaire de ressources a renvoyé le message suivant : « La version 1.xx demandée n'est pas valide pour la version 1.yy de kubernetes »

Cette erreur se produit lors de la mise à niveau du groupe de nœuds gérés avec le groupe Amazon EKS à partir de la même pile AWS CloudFormation à l'aide de l'appel d'API UpdateStack.

CloudFormation tente de restaurer la pile, mais elle échoue car le groupe Amazon EKS a été mis à niveau avec succès et ne peut pas être restauré. Le groupe Amazon EKS ne peut pas faire correspondre la version 1.xx à la version 1.yy (par exemple, 1.21 et 1.22).

Vérifiez la première erreur qui s'est produite pour le groupe de nœuds dans la pile CloudFormation pour plus de détails sur la façon de résoudre le problème. Ensuite, mettez à nouveau à jour votre pile CloudFormation.

Pour plus d'informations, consultez la section Comportement de mise à jour des nœuds gérés.


Informations connexes

Comment résoudre les problèmes liés à la création de groupes de nœuds gérés par Amazon EKS ?

Comment résoudre les erreurs liées aux groupes de nœuds gérés dans un groupe Amazon EKS ?

Résolution des problèmes d'Amazon EKS

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an