Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Résolution des problèmes avec le mode automatique EKS

Avec le mode automatique EKS, AWS assume une part plus importante de la responsabilité concernant les instances EC2 dans votre compte AWS. EKS assume la responsabilité de l’exécution de conteneur sur les nœuds, du système d’exploitation sur les nœuds et de certains contrôleurs. Cela inclut un contrôleur de stockage par blocs, un contrôleur d’équilibrage de charge et un contrôleur de calcul.

Vous devez utiliser les API AWS et Kubernetes pour résoudre les problèmes liés aux nœuds. Vous pouvez :

Vous pouvez rencontrer les problèmes suivants, qui disposent de solutions spécifiques aux composants du mode automatique EKS :

Vous pouvez utiliser les méthodes suivantes pour diagnostiquer et résoudre les problèmes liés aux composants du mode automatique EKS :

Agent de surveillance des nœuds

Le mode automatique EKS inclut l’agent de surveillance des nœuds Amazon EKS. Vous pouvez utiliser cet agent pour consulter les informations de diagnostic et de débogage relatives aux nœuds. L’agent de surveillance des nœuds publie les events Kubernetes et les conditions du nœud. Pour de plus amples informations, consultez Activer la réparation automatique des nœuds et étudier les problèmes d’intégrité de ces derniers.

Extraction du résultat de la console d’une instance EC2 gérée à l’aide de la CLI AWS EC2

Cette procédure permet de résoudre les problèmes survenant au démarrage ou au niveau du noyau.

Tout d’abord, déterminez l’ID de l’instance EC2 associée à votre charge de travail. Ensuite, utilisez la CLI AWS pour extraire le résultat de la console.

Extraction des journaux des nœuds à l’aide des conteneurs de débogage et de la CLI kubectl

La méthode recommandée pour extraire les journaux d’un nœud du mode automatique EKS consiste à utiliser la ressource NodeDiagnostic. Pour les étapes, consultez Extraction des journaux d’un nœud géré à l’aide de kubectl et S3.

Cependant, vous pouvez également diffuser les journaux en temps réel à partir d’une instance en utilisant la commande kubectl debug node. Cette commande lance un nouveau pod sur le nœud à déboguer, avec lequel vous pouvez ensuite interagir.

Pour des raisons de sécurité, l’image de conteneur Amazon Linux n’installe pas de nombreux binaires par défaut. Vous pouvez utiliser la commande yum whatprovides pour identifier le package à installer afin d’obtenir le binaire correspondant.

yum whatprovides ps

Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : @System
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : amazonlinux
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

Affichage des ressources associées au mode automatique EKS dans la console AWS

Vous pouvez utiliser la console AWS pour afficher l’état des ressources associées à votre cluster du mode automatique EKS.

Affichage des erreurs IAM dans votre compte AWS

Recherchez les erreurs associées à votre cluster EKS. Utilisez les messages d’erreur pour mettre à jour les entrées d’accès EKS, le rôle IAM du cluster ou le rôle IAM du nœud. Vous devrez peut-être attacher une nouvelle politique à ces rôles pour leur accorder les autorisations nécessaires au mode automatique EKS.

Résolution des problèmes liés à l’échec de la planification des pods sur un nœud du mode automatique

Si des pods restent dans l’état Pending et ne sont pas planifiés sur un nœud du mode automatique, vérifiez si le manifeste de pod ou de déploiement contient un nodeSelector. Si un nodeSelector est présent, assurez-vous qu’il utilise eks.amazonaws.com/compute-type: auto pour être planifié sur les nœuds gérés par le mode automatique EKS. Pour plus d’informations sur les étiquettes de nœud utilisées par le mode automatique EKS, consultez Contrôle du déploiement d’une charge de travail sur les nœuds du mode automatique EKS.

Résolution problèmes liés au fait qu’un nœud ne rejoint pas le cluster

Le mode automatique EKS configure automatiquement les nouvelles instances EC2 avec les informations nécessaires pour rejoindre le cluster, notamment l’adresse de point de terminaison du cluster et l’autorité de certification (CA) du cluster. Cependant, certaines instances peuvent ne pas rejoindre le cluster EKS en tant que nœuds. Exécutez les commandes suivantes pour identifier les instances qui n’ont pas rejoint le cluster :

Messages d’erreur courants :

Détection des problèmes de connectivité des nœuds avec l’outil VPC Reachability Analyzer

L’une des raisons pour lesquelles une instance n’a pas rejoint le cluster est un problème de connectivité réseau qui l’empêche d’atteindre le serveur d’API. Pour diagnostiquer ce problème, vous pouvez utiliser le VPC Reachability Analyzer afin d’effectuer une analyse de la connectivité entre un nœud qui ne parvient pas à rejoindre le cluster et le serveur d’API. Vous aurez besoin de deux informations :

Pour obtenir l’ID d’instance, vous devez créer une charge de travail sur le cluster afin que le mode automatique EKS lance une instance EC2. Cela crée également un objet NodeClaim dans votre cluster qui aura l’ID d’instance. Exécutez kubectl get nodeclaim -o yaml pour imprimer tous les éléments NodeClaims de votre cluster. Chaque NodeClaim contient l’ID d’instance en tant que champ et à nouveau dans le providerID :

kubectl get nodeclaim -o yaml

L'exemple qui suit illustre un résultat.

    nodeName: i-01234567890123456
    providerID: aws:///us-west-2a/i-01234567890123456

Vous pouvez déterminer votre point de terminaison de serveur d’API Kubernetes en exécutant kubectl get endpoint kubernetes -o yaml. Les adresses se trouvent dans le champ des adresses :

kubectl get endpoints kubernetes -o yaml

L'exemple qui suit illustre un résultat.

apiVersion: v1
kind: Endpoints
metadata:
  name: kubernetes
  namespace: default
subsets:
- addresses:
  - ip: 10.0.143.233
  - ip: 10.0.152.17
  ports:
  - name: https
    port: 443
    protocol: TCP

Avec ces deux informations, vous pouvez effectuer l’analyse de connectivité. Tout d’abord, accédez à VPC Reachability Analyzer dans la AWS Management Console.

Partage des volumes entre les pods

Les nœuds du mode automatique EKS sont configurés avec SELinux en mode d’application, ce qui assure une meilleure isolation entre les pods exécutés sur un même nœud. Lorsque SELinux est activé, la plupart des pods non privilégiés reçoivent automatiquement une étiquette de sécurité multi-catégorie (Multi-Category Security, MCS). Cette étiquette MCS est unique pour chaque pod et vise à garantir qu’un processus dans un pod ne puisse pas interagir avec un processus dans un autre pod ou sur l’hôte. Même si un pod étiqueté s’exécute en tant que root et dispose d’un accès au système de fichiers de l’hôte, il ne pourra pas modifier des fichiers sur l’hôte, exécuter des appels système sensibles, accéder à l’exécution du conteneur, ni obtenir les clés secrètes du kubelet.

En conséquence, vous pouvez rencontrer des problèmes lors du partage de données entre pods. Par exemple, un PersistentVolumeClaim avec un mode d’accès ReadWriteOnce ne permettra toujours pas à plusieurs pods d’accéder simultanément au volume.

Pour autoriser le partage entre pods, vous pouvez utiliser les seLinuxOptions du pod pour configurer la même étiquette MCS sur ces pods. Dans cet exemple, nous attribuons les trois catégories c123,c456,c789 au pod. Cela n’entre pas en conflit avec les catégories attribuées automatiquement aux pods sur le nœud, car ces derniers ne reçoivent que deux catégories.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456,c789"

Affichage des événements Karpenter dans les journaux du plan de contrôle

Pour les clusters EKS disposant des journaux du plan de contrôle activés, vous pouvez analyser les actions et les décisions de Karpenter en interrogeant les journaux. Cela est particulièrement utile pour la résolution des problèmes du mode automatique EKS liés à la mise en service des nœuds, la mise à l’échelle ou la suppression des nœuds. Pour afficher les événements liés à Karpenter, utilisez la requête suivante dans CloudWatch Logs Insights :

fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
sort @timestamp desc

Cette requête filtre les événements spécifiques liés à Karpenter dans les journaux d’audit de kube-apiserver. Les événements incluent différents états d’interruption, des échecs de planification, des problèmes de capacité et des anomalies liées aux nœuds. En analysant ces journaux, vous pouvez mieux comprendre :

Pour utiliser cette requête, procédez comme suit :

Les résultats afficheront une chronologie des événements liés à Karpenter, ce qui vous aidera à résoudre les problèmes et à comprendre le comportement du mode automatique EKS dans votre cluster. Pour examiner les actions de Karpenter sur un nœud particulier, vous pouvez ajouter un filtre de ligne indiquant l’ID de l’instance à la requête mentionnée précédemment :

|filter @message like /[.replaceable]`i-12345678910123456`/

Résolution des problèmes liés aux contrôleurs inclus dans le mode automatique

Si vous rencontrez un problème avec un contrôleur, vérifiez les points suivants :

Ressources connexes

Utilisez les articles suivants d’AWS re:Post pour obtenir des étapes avancées de résolution des problèmes :