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

Brève description

Lorsque vous lancez une mise à jour d'un groupe de nœuds géré, Amazon EKS met automatiquement à jour vos nœuds. Si vous utilisez une AMI optimisée pour Amazon EKS, Amazon EKS applique automatiquement les derniers correctifs de sécurité et les mises à jour du système d'exploitation à vos nœuds.

Au cours de ce processus de mise à jour, l'une des erreurs suivantes pourrait se produire. Suivez les étapes de résolution des problèmes correspondant à l'erreur survenue. Pour plus d'informations sur les erreurs de mise à jour, reportez-vous à Comportement de mise à jour des nœuds gérés.

Résolution

Échec de la mise à jour en raison de PodEvictionFailure

L'erreur suivante indique qu'un PodEvictionFailure bloque la mise à niveau :

« Message d'erreur : nombre maximal de tentatives atteint lors de la tentative d'éviction des pods des nœuds d'un groupe de nœuds. »

Si les pods ne quittent pas le nœud dans les 15 minutes et qu'aucun indicateur de force n'apparaît, l’erreur PodEvictionFailure indiquera l’échec de la phase de mise à niveau.

Une erreur PodEvictionFailure peut se produire pour l'une des raisons suivantes :

PBD (budget de perturbation de pods) agressif

Lorsque plusieurs PDB pointent vers le même pod, le pod est caractérisé de PDB agressif.

Le PDB indique le nombre de perturbations qu'une classe de pods peut tolérer à un moment donné (ou un « budget de défauts »). Lorsqu'une perturbation volontaire fait chuter le nombre de pods d'un service en deçà du budget, l'opération s'arrête 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. Cela permet que vous ne dépassiez pas le budget en expulsant les pods. Pour plus d'informations, reportez-vous à la section Interruptions sur le site Web de Kubernetes.

Pour garantir une mise à jour fluide du groupe de nœuds géré, supprimez temporairement les budgets d'interruption des pods ou utilisez l'option de force pour effectuer la mise à jour. Cette option ne respecte pas les budgets d'interruption de service des pods. Au contraire, elle force les nœuds à redémarrer et par conséquent, à implémenter les mises à jour.

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

Pour vérifier que les PDB sont configurés dans votre cluster, exécutez la commande suivante :

$ kubectl get pdb --all-namespaces

Autrement, si vous avez activé la journalisation des audits dans la console Amazon EKS :

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

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

3. Dans la console CloudWatch, choisissez 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. Choisissez Personnaliser pour définir la date de mise à jour. En cas d'échec de la mise à jour du groupe de nœuds dû à un PDB agressif, resposeObject.message donne la raison de l'échec de l'expulsion du pod.

5. Si le PDB est à l'origine de l'échec, modifiez-le. Exécutez la commande suivante, puis refaites la mise à niveau du groupe de nœuds :

   $ kubectl edit pdb pdb_name;

Déploiement tolérant tous les rejets

Une fois que chaque pod est expulsé, le nœud devient vide, car il a été rejeté lors des étapes précédentes. Toutefois, si le déploiement tolère tous les rejets, il est fort probable que le nœud ne soit pas vide. Cela entraîne un échec de l'expulsion du pod. Pour plus d'informations, reportez-vous à Rejets et tolérances sur le site Web de Kubernetes.

Échec de la mise à jour en raison de l'invalidité de la version

Si votre version n'est pas valide, le message d'erreur suivant peut s'afficher :

« Message d'erreur : La version 1.xx demandée n'est pas valide pour la version 1.xx de kubernetes. »

Pour résoudre ce problème, exécutez à nouveau la commande de mise à niveau. Cette commande met à niveau les groupes de nœuds vers une version similaire à 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é, en raison des problèmes d’état des groupe de nœuds

Si votre groupe de nœuds présente des problèmes d'état, l'échec de la mise à jour renvoie le message d'erreur suivant :

« Message d'erreur : Nodegroup a un problème d'état autre que [AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable] »

Cela indique que le groupe Auto Scaling du groupe de nœuds ne trouve pas la version attendue de son modèle de lancement Amazon Elastic Compute Cloud (Amazon EC2). Cette erreur se produit si vous modifiez ou supprimez manuellement la version du modèle associé au groupe de nœuds. Cela pousse EKS à indiquer que le groupe de nœuds est dégradé.

Si vous n'avez pas 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 donc relancer le processus de mise à jour.

La mise à jour a échoué, car les nouveaux nœuds ne rejoignent pas le groupe de nœuds

Ce problème se produit si les nouveaux nœuds du groupe de nœuds ne peuvent pas rejoindre le cluster. Par conséquent, le groupe de nœuds revient à sa version précédente. Dans ce cas, le message d'erreur suivant peut s'afficher :

« NodeCreationFailure
Impossible de poursuivre le processus de mise à niveau, car les nouveaux nœuds ne rejoignent pas le groupe de nœuds ng-backend »

Les nœuds mis à jour ne peuvent pas rejoindre le cluster pour plusieurs raisons :

Vous avez modifié une règle du groupe de sécurité utilisée par le groupe de nœuds existant

Vérifiez que les règles sortantes du groupe de sécurité du nœud autorisent le port 443 à accéder au groupe de sécurité du cluster.

Le groupe de sécurité du cluster n'autorise pas le trafic provenant du groupe de sécurité du nœud

Vérifiez que les règles entrantes du groupe de sécurité du cluster autorisent le port 443 à partir du groupe de sécurité du nœud. Pour plus d'informations, consultez Exigences et considérations relatives aux groupes de sécurité Amazon EKS.

Vous avez créé un groupe de nœuds à partir d'un modèle de lancement personnalisé

Pour mettre à jour un modèle de lancement personnalisé, la nouvelle version du modèle doit contenir les bonnes données utilisateur. De même, si vous utilisez une AMI personnalisée, assurez-vous que vous l'avez correctement configurée pour rejoindre le cluster.

Pour résoudre les problèmes liés au modèle de lancement, créez un nouveau groupe de nœuds avec le même modèle de lancement. Assurez-vous que le modèle utilise la version la plus récente de l'AMI personnalisée. Vérifiez ensuite si le nœud rejoint effectivement le cluster. Si le nœud ne rejoint pas le cluster, connectez-vous à l'instance du nœud via SSH et vérifiez les journaux kubelet.

Autorisations IAM manquantes

Vérifiez si le rôle AWS Identity and Access Management (IAM) du groupe de nœuds dispose des autorisations nécessaires.

Les ACL refusent le trafic

La liste de contrôle d'accès (ACL) du sous-réseau d'un nœud peut refuser le trafic sortant pour le port 443 ou le trafic entrant pour un port éphémère. Assurez-vous d'autoriser ces règles pour le sous-réseau du nœud.

De même, l'ACL du sous-réseau d'un cluster peut refuser le trafic entrant pour le port 443. Assurez-vous d'autoriser ce trafic pour les sous-réseaux de votre cluster.

Échec des nouveaux nœuds à ajouter un plugin

Un plugin CNI Amazon Virtual Private Cloud (Amazon VPC) ou un module complémentaire kube-proxy pourrait ne pas apparaître sur les nouveaux nœuds. Pour plus d'informations, consultez Comment résoudre les problèmes liés aux plug-ins kubelet ou CNI pour Amazon EKS ?

Un sous-réseau présente des problèmes de connectivité

Le sous-réseau dans lequel Amazon EKS crée des nœuds n'est peut-être pas connecté aux points de terminaison nécessaires. Ces points de terminaison peuvent inclure Amazon Elastic Container Registry (Amazon ECR), Amazon Simple Storage Service (Amazon S3) ou Amazon EC2. La connectivité peut échouer via Internet ou via les points de terminaison d'un VPC. Pour les points de terminaison d'un VPC, vérifiez les groupes de sécurité des nœuds et des points de terminaison pour vous assurer qu'ils autorisent le trafic requis. Si vous utilisez une passerelle NAT ou une passerelle Internet, vérifiez que la règle de routage est correcte dans la table de routage de votre sous-réseau. Vérifiez également que la passerelle NAT ou la passerelle Internet correspondante existe.