Résoudre les problèmes liés au mode automatique d'EKS

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.

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.

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 du 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 :

Vous pouvez rencontrer les problèmes suivants qui ont des solutions spécifiques aux composants du mode automatique d'EKS :

Vous pouvez utiliser les méthodes suivantes pour dépanner les 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 dépannage et de débogage relatives aux nœuds. L'agent de surveillance des nœuds publie Kubernetes events et le nœud. conditions Pour de plus amples informations, veuillez consulter Activez la réparation automatique des nœuds et étudiez les problèmes de santé des nœuds.

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 liés au démarrage ou au niveau du noyau.

Vous devez d'abord 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.

Obtenez les journaux des nœuds à l'aide de conteneurs de débogage et de la CLI kubectl

La méthode recommandée pour récupérer les journaux à partir d'un nœud en mode automatique EKS consiste à utiliser NodeDiagnostic des ressources. Pour ces étapes, voirRécupérez les journaux d'un nœud géré à l'aide de kubectl et S3.

Cependant, vous pouvez diffuser des journaux en direct à partir d'une instance à l'aide de la kubectl debug node commande. Cette commande lance un nouveau Pod sur le nœud que vous souhaitez déboguer, que vous pouvez ensuite utiliser de manière interactive.

Pour des raisons de sécurité, l'image du conteneur Amazon Linux n'installe pas beaucoup de fichiers binaires par défaut. Vous pouvez utiliser la yum whatprovides commande pour identifier le package qui doit être installé pour fournir un binaire donné.

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 liées à votre cluster EKS. Utilisez les messages d'erreur pour mettre à jour vos entrées d'accès EKS, votre rôle IAM de cluster ou votre rôle IAM de nœud. Vous devrez peut-être associer une nouvelle politique à ces rôles avec des autorisations pour le mode automatique EKS.

Résoudre les problèmes liés à l'échec de la planification du Pod sur le nœud en mode automatique

Si les pods restent dans Pending cet état et ne sont pas programmés sur un nœud en mode auto, vérifiez si votre pod ou votre manifeste de déploiement possède unnodeSelector. Si un nodeSelector est présent, assurez-vous qu'il est utilisé eks.amazonaws.com/compute-type: auto pour être planifié sur les nœuds créés par le mode automatique EKS. Pour plus d'informations sur les étiquettes de nœuds utilisées par le mode automatique d'EKS, consultezContrôler si une charge de travail est déployée sur les nœuds du mode automatique EKS.

Résoudre les problèmes liés au fait que le 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, ces instances peuvent toujours ne pas rejoindre le cluster EKS en tant que nœud. Exécutez les commandes suivantes pour identifier les instances qui n'ont pas rejoint le cluster :

Messages d'erreur courants :

Détectez les problèmes de connectivité des nœuds avec le 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 pour 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 NodeClaim objet 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. Chacun NodeClaim contient l'ID d'instance sous forme de champ, puis de 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 le point de terminaison de votre 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 s. Accédez d'abord à l'Analyzer de Reachability VPC dans le.AWS Management Console

Partage de 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 par pod et est conçue pour garantir qu'un processus dans un pod ne peut pas manipuler 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 a accès au système de fichiers hôte, il ne pourra pas manipuler les fichiers, effectuer des appels système sensibles sur l'hôte, accéder au runtime du conteneur ou obtenir la clé secrète de Kubelet.

De ce fait, vous pouvez rencontrer des problèmes lorsque vous essayez de partager des données entre des pods. Par exemple, un mode PersistentVolumeClaim d'accès de n'ReadWriteOnceautorisera toujours pas plusieurs pods à accéder simultanément au volume.

Pour activer ce partage entre les pods, vous pouvez utiliser les pods seLinuxOptions 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'entrera pas en conflit avec les catégories attribuées automatiquement aux pods sur le nœud, car seules deux catégories leur seront attribuées.

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

Résoudre les problèmes liés aux manettes incluses en mode automatique

Si vous rencontrez un problème avec une manette, vous devez rechercher :