Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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

Avec le mode automatique d'EKS, vous AWS assumez une plus grande responsabilité pour les EC2 instances de votre AWS compte. 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 AWS Kubernetes APIs pour dépanner les nœuds. Vous pouvez effectuer les actions suivantes :

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, veuillez consulter Activation de la réparation automatique des nœuds et examen des problèmes d’état de ces derniers.

Obtenez la sortie de console d'une instance EC2 gérée à l'aide de la AWS EC2 CLI

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

Tout d'abord, vous devez déterminer l'ID d' EC2 instance de l'instance associée à votre charge de travail. Ensuite, utilisez la AWS CLI pour récupérer la sortie 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

Afficher les ressources associées au mode automatique EKS dans la AWS console

Vous pouvez utiliser la AWS console pour afficher l'état des ressources associées à votre cluster EKS Auto Mode.

Afficher les erreurs IAM dans votre AWS compte

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 d'EKS configure automatiquement les nouvelles EC2 instances avec les informations correctes pour rejoindre le cluster, y compris le 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 EC2 instance. 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 en mode automatique EKS sont configurés SELinux en mode d'application, ce qui permet une meilleure isolation entre les pods exécutés sur le même nœud. Lorsque cette option SELinux est activée, la plupart des pods non privilégiés se verront automatiquement appliquer leur propre étiquette de sécurité multi-catégories (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 consulter les événements liés à Karpenter, utilisez la requête CloudWatch Logs Insights suivante :

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 ces articles de AWS Re:Post pour connaître les étapes de dépannage avancées :