**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 liés aux clusters et aux nœuds Amazon EKS Ce chapitre traite de certaines erreurs courantes que vous pouvez rencontrer lorsque vous utilisez Amazon EKS, ainsi que des solutions. Si vous avez besoin de dépanner des zones spécifiques d'Amazon EKS, consultez les rubriques [Dépannage IAM](security-iam-troubleshoot.md), [Dépannage des problèmes liés à Amazon EKS Connector](troubleshooting-connector.md) et [Dépannage d'ADOT à l'aide de modules complémentaires EKS](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on/troubleshooting). *Pour d'autres informations de dépannage, consultez le [contenu du centre de connaissances sur Amazon Elastic Kubernetes Service sur Re:post](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service). AWS * ## Capacité insuffisante Si vous recevez l’erreur suivante lorsque vous essayez de créer un cluster Amazon EKS, cela signifie que l’une des zones de disponibilité que vous avez spécifiées ne dispose pas d’une capacité suffisante pour prendre en charge un cluster. `Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c` Essayez à nouveau de créer votre cluster avec des sous-réseaux de votre VPC de cluster hébergés dans les zones de disponibilité renvoyés par ce message d'erreur. Il existe des zones de disponibilité dans lesquelles un cluster ne peut pas résider. Veuillez comparer les zones de disponibilité dans lesquelles se trouvent vos sous-réseaux avec la liste des zones de disponibilité dans les [Exigences et considérations relatives aux sous-réseaux](network-reqs.md#network-requirements-subnets). ## Les nœuds ne parviennent pas à joindre le cluster Quelques raisons courantes empêchent les nœuds de joindre le cluster : + Si les nœuds sont des nœuds gérés, Amazon EKS ajoute des entrées à la `ConfigMap` `aws-auth` lorsque vous créez le groupe de nœuds. Si l’entrée a été supprimée ou modifiée, vous devez l’ajouter de nouveau. Pour plus d’informations, entrez `eksctl create iamidentitymapping --help` dans votre terminal. Vous pouvez afficher vos `aws-auth` `ConfigMap` entrées actuelles *my-cluster* en remplaçant la commande suivante par le nom de votre cluster, puis en exécutant la commande modifiée :`eksctl get iamidentitymapping --cluster my-cluster `. L’ARN du rôle que vous spécifiez ne peut pas inclure de [chemin](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) autre que `/`. Par exemple, si le nom de votre rôle est `development/apps/my-role`, vous devez le remplacer par `my-role` lorsque vous spécifiez l’ARN du rôle. Assurez-vous que vous spécifiez l'ARN pour le rôle IAM du nœud (et non l'ARN du profil d'instance). Si les nœuds sont autogérés et que vous n’avez pas créé d’[entrées d’accès](access-entries.md) pour l’ARN du rôle IAM du nœud, exécutez les mêmes commandes que celles répertoriées pour les nœuds gérés. Si vous avez créé une entrée d’accès pour l’ARN du rôle IAM de votre nœud, il se peut qu’elle ne soit pas correctement configurée dans l’entrée d’accès. Assurez-vous que l’ARN du rôle IAM du nœud (et non l’ARN du profil d’instance) est spécifié comme ARN principal dans votre entrée de `ConfigMap` `aws-auth` ou dans votre entrée d’accès. Pour plus d'informations sur les entrées d'accès, consultez [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md). + Le AWS CloudFormation modèle **ClusterName**de votre nœud ne correspond pas exactement au nom du cluster que vous souhaitez que vos nœuds rejoignent. Si vous transmettez une valeur incorrecte à ce champ, le fichier `/var/lib/kubelet/kubeconfig` du nœud sera mal configuré et les nœuds ne rejoindront pas le cluster. + Le nœud n'est pas étiqueté comme *appartenant* au cluster. La balise suivante doit être appliquée à vos nœuds, où *my-cluster* est remplacé par le nom de votre cluster. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/troubleshooting.html) + Les nœuds peuvent ne pas être en mesure d'accéder au cluster à l'aide d'une adresse IP publique. Assurez-vous qu'une adresse IP publique est attribuée aux nœuds déployés dans les sous-réseaux publics. Si ce n’est pas le cas, vous pouvez associer une adresse IP Elastic à un nœud après son lancement. Pour plus d'informations, consultez [Association d'une adresse IP élastique à une instance en cours d'exécution ou à une interface réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-associating). Si le sous-réseau public n'est pas défini pour attribuer automatiquement des adresses IP publiques aux instances qui y sont déployées, nous vous recommandons d'activer ce paramètre. Pour plus d'informations, consultez la section [Modification de l'attribut d' IPv4 adressage public de votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si le nœud est déployé sur un sous-réseau privé, ce sous-réseau doit disposer d'une route vers une passerelle NAT à laquelle une adresse IP publique est attribuée. + Le point de terminaison AWS STS de la AWS région dans laquelle vous déployez les nœuds n'est pas activé pour votre compte. Pour activer la région, voir [Activation et désactivation du AWS STS dans une AWS région.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) + Le nœud ne dispose pas d’une entrée DNS privée, ce qui entraîne l’apparition d’une erreur « `kubelet` » dans le journal `node "" not found`. Assurez-vous que le VPC sur lequel le nœud est créé a des valeurs définies pour `domain-name` et `domain-name-servers` comme `Options` dans un `DHCP options set`. Les valeurs par défaut sont `domain-name:.compute.internal` et `domain-name-servers:AmazonProvidedDNS`. Pour en savoir plus, consultez [Jeux d'options DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS) dans le *Guide de l'utilisateur Amazon VPC*. + Si les nœuds du groupe de nœuds gérés ne se connectent pas au cluster dans les 15 minutes, un problème de santé de type NodeCreationFailure « » sera émis et le statut de la console sera défini sur`Create failed`. Pour Windows AMIs dont les temps de lancement sont lents, ce problème peut être résolu à l'aide du [lancement rapide](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/win-ami-config-fast-launch.html). Pour identifier et résoudre les problèmes courants qui empêchent les composants master de rejoindre un cluster, vous pouvez utiliser le runbook`AWSSupport-TroubleshootEKSWorkerNode`. Pour plus d'informations, consultez le manuel ` [AWSSupport-TroubleshootEKSWorkerNode](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshooteksworkernode.html) ` de *référence du runbook AWS Systems Manager Automation*. ## Accès non autorisé ou refusé (`kubectl`) Si vous recevez l’une des erreurs suivantes lors de l’exécution des commandes `kubectl`, cela signifie que `kubectl` n’est pas correctement configuré pour Amazon EKS ou que les informations d’identification du principal IAM (rôle ou utilisateur) que vous utilisez ne correspondent pas à un nom d’utilisateur Kubernetes disposant des autorisations suffisantes pour les objets Kubernetes sur votre cluster Amazon EKS. + `could not get token: AccessDenied: Access denied` + `error: You must be logged in to the server (Unauthorized)` + `error: the server doesn’t have a resource type "svc"` Cela peut être dû à l'une des raisons suivantes : + Le cluster a été créé avec les informations d'identification d'un principal IAM et `kubectl` est configuré pour utiliser les informations d'identification d'un autre principal IAM. Pour résoudre ce problème, mettez à jour votre fichier `kube config` afin d’utiliser les informations d’identification à l’origine de la création du cluster. Pour de plus amples informations, veuillez consulter [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md). + Si votre cluster répond aux exigences minimales de la plateforme dans la section « Conditions préalables » de la section [Accorder aux utilisateurs IAM l’accès à Kubernetes avec des entrées d’accès EKS](access-entries.md), aucune entrée d’accès n’existe avec votre principal IAM. Si elle existe, elle ne dispose pas des noms de groupe Kubernetes nécessaires qui lui sont définis ou n’est pas associée à la stratégie d’accès appropriée. Pour de plus amples informations, veuillez consulter [Attribution de l’accès Kubernetes aux utilisateurs IAM avec les entrées d’accès EKS](access-entries.md). + Si votre cluster ne répond pas aux exigences minimales de la plateforme dans [Accorder aux utilisateurs IAM l’accès à Kubernetes avec des entrées d’accès EKS](access-entries.md), aucune entrée avec votre principal IAM n’existe dans le `aws-auth` `ConfigMap`. Si elle existe, elle n’est pas mappée aux noms de groupes Kubernetes liés à un `Role` ou un `ClusterRole` Kubernetes avec les autorisations nécessaires. Pour plus d’informations sur les objets d’autorisation basée sur les rôles (RBAC) Kubernetes, consultez [Utilisation de l’autorisation RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) dans la documentation Kubernetes. Vous pouvez afficher vos `aws-auth` `ConfigMap` entrées actuelles *my-cluster* en remplaçant la commande suivante par le nom de votre cluster, puis en exécutant la commande modifiée :`eksctl get iamidentitymapping --cluster my-cluster `. Si une entrée pour l’ARN de votre principal IAM ne se trouve pas dans le `ConfigMap`, saisissez `eksctl create iamidentitymapping --help` dans votre terminal pour savoir comment en créer une. Si vous installez et configurez la AWS CLI, vous pouvez configurer les informations d'identification IAM que vous utilisez. Pour plus d'informations, consultez [la section Configuration de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) dans le *guide de l'utilisateur de l'interface de ligne de AWS commande*. Vous pouvez également configurer `kubectl` pour utiliser un rôle IAM, si vous assumez un rôle IAM pour accéder aux objets Kubernetes sur votre cluster. Pour de plus amples informations, veuillez consulter [Connexion de kubectl à un cluster EKS en créant un fichier kubeconfig](create-kubeconfig.md). ## `hostname doesn’t match` La version Python de votre système doit être `2.7.9` ou ultérieure. Dans le cas contraire, vous recevrez `hostname doesn’t match` des erreurs lors des appels AWS CLI vers Amazon EKS. Pour plus d’informations, consultez [Que sont les erreurs « nom d’hôte ne correspond pas » ?](https://requests.readthedocs.io/en/latest/community/faq.html#what-are-hostname-doesn-t-match-errors) dans les *Questions fréquentes sur les demandes Python*. ## `getsockopt: no route to host` Docker s'exécute dans la plage d'adresses CIDR `172.17.0.0/16` dans les clusters Amazon EKS. Nous vous recommandons de ne pas faire chevaucher cette plage par les sous-réseaux VPC de votre cluster. Sinon, vous recevrez l'erreur suivante : ``` Error: : error upgrading connection: error dialing backend: dial tcp 172.17..:10250: getsockopt: no route to host ``` ## `Instances failed to join the Kubernetes cluster` Si le message d'erreur s'affiche `Instances failed to join the Kubernetes cluster` dans le AWS Management Console, assurez-vous que l'accès au point de terminaison privé du cluster est activé ou que vous avez correctement configuré les blocs CIDR pour l'accès au point de terminaison public. Pour de plus amples informations, veuillez consulter [Point de terminaison du serveur d’API du cluster](cluster-endpoint.md). ## Codes d'erreurs liées aux groupes de nœuds gérés Si votre groupe de nœuds gérés rencontre un problème d'intégrité matérielle, Amazon EKS renvoie un code d'erreur pour vous aider à diagnostiquer le problème. Ces surveillances de l’état ne détectent pas les problèmes logiciels, car elles sont basées sur les [surveillances de l’état Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html). La liste suivante décrit les codes d'erreur. **AccessDenied** Amazon EKS ou un ou plusieurs de vos nœuds gérés ne parviennent pas à s’authentifier ou à s’autoriser auprès du serveur API de votre cluster Kubernetes. Pour de plus amples informations sur la résolution d'une cause courante, consultez [Correction d'une cause courante d'erreurs `AccessDenied` pour les groupes de nœuds gérés](#access-denied-managed-node-groups). AMIs Les fenêtres privées peuvent également provoquer ce code d'erreur en même temps que le message `Not authorized for images` d'erreur. Pour de plus amples informations, veuillez consulter [`Not authorized for images`](#not-authorized-for-images). **AmiIdNotFound** Nous n’avons pas trouvé l’ID AMI associé à votre modèle de lancement. Assurez-vous que l'AMI existe et est partagée avec votre compte. **AutoScalingGroupNotFound** Nous n’avons pas trouvé le groupe Auto Scaling associé au groupe de nœuds gérés. Vous pouvez peut-être recréer un groupe Auto Scaling avec les mêmes paramètres pour effectuer une récupération. **ClusterUnreachable** Amazon EKS ou un ou plusieurs de vos nœuds gérés ne parviennent pas à communiquer avec votre serveur API du cluster Kubernetes. Cela peut se produire s'il y a des interruptions de réseau ou si les serveurs d'API temporisent le traitement des demandes. **Eco 2 SecurityGroupNotFound** Nous n’avons pas trouvé le groupe de sécurité du cluster. Vous devez recréer votre cluster. **Eco 2 SecurityGroupDeletionFailure** Nous n'avons pas pu supprimer le groupe de sécurité d'accès à distance pour votre groupe de nœuds gérés. Supprimez toutes les dépendances du groupe de sécurité. **Eco 2 LaunchTemplateNotFound** Nous n’avons pas trouvé le modèle de lancement Amazon EC2 pour votre groupe de nœuds gérés. Vous devez recréer votre groupe de nœuds pour effectuer une récupération. **Eco 2 LaunchTemplateVersionMismatch** La version du modèle de lancement Amazon EC2 pour votre groupe de nœuds gérés ne correspond pas à la version créée par Amazon EKS. Vous pouvez peut-être revenir à la version Amazon EKS créée pour effectuer une récupération. **IamInstanceProfileNotFound** Nous n’avons pas trouvé le profil d’instance IAM pour votre groupe de nœuds gérés. Vous pouvez peut-être recréer un profil d'instance avec les mêmes paramètres pour effectuer une récupération. **IamNodeRoleNotFound** Nous n’avons pas trouvé le rôle IAM pour votre groupe de nœuds gérés. Vous pouvez peut-être recréer un rôle IAM avec les mêmes paramètres pour effectuer une récupération. **AsgInstanceLaunchFailures** Votre groupe Auto Scaling rencontre des problèmes lors d'une tentative de lancement d'instances. **NodeCreationFailure** Vos instances lancées ne peuvent pas s'enregistrer auprès de votre cluster Amazon EKS. Les causes courantes de cet échec sont des autorisations de [rôle IAM de nœud](create-node-role.md) insuffisantes ou l'absence d'un accès Internet sortant pour les nœuds. Vos nœuds doivent répondre à l'une des exigences suivantes : + Accès à Internet à l'aide d'une adresse IP publique. Le groupe de sécurité associé au sous-réseau dans lequel se trouve le nœud doit autoriser la communication. Pour plus d’informations, consultez [Exigences et considérations requises pour les sous-réseaux](network-reqs.md#network-requirements-subnets) et [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). + Vos nœuds et votre VPC doivent répondre aux exigences décrites dans [Déployer des clusters privés avec un accès Internet limité](private-clusters.md). **InstanceLimitExceeded** Votre AWS compte n'est plus en mesure de lancer d'autres instances du type d'instance spécifié. Vous pouvez demander une augmentation de la limite d'instances Amazon EC2 pour effectuer une récupération. **InsufficientFreeAddresses** Un ou plusieurs sous-réseaux associés à votre groupe de nœuds gérés ne disposent pas d’adresses IP suffisantes pour les nouveaux nœuds. **InternalFailure** Ces erreurs sont généralement dues à un problème côté serveur Amazon EKS. ### Correction d'une cause courante d'erreurs `AccessDenied` pour les groupes de nœuds gérés La cause la plus courante d'erreurs `AccessDenied` lors de la réalisation d'opérations sur des groupes de nœuds gérés est l'absence de `eks:node-manager` `ClusterRole` ou `ClusterRoleBinding`. Amazon EKS configure ces ressources dans votre cluster dans le cadre de l'onboarding avec les groupes de nœuds gérés, et celles-ci sont nécessaires pour gérer les groupes de nœuds. La `ClusterRole` peut changer au fil du temps, mais elle doit ressembler à l'exemple suivant : ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: eks:node-manager rules: - apiGroups: - '' resources: - pods verbs: - get - list - watch - delete - apiGroups: - '' resources: - nodes verbs: - get - list - watch - patch - apiGroups: - '' resources: - pods/eviction verbs: - create ``` La `ClusterRoleBinding` peut changer au fil du temps, mais elle doit ressembler à l'exemple suivant : ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks:node-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-manager subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: eks:node-manager ``` Vérifiez que la `eks:node-manager` `ClusterRole` existe. ``` kubectl describe clusterrole eks:node-manager ``` Si elle est présente, comparez la sortie à l'exemple de la `ClusterRole`précédente. Vérifiez que la `eks:node-manager` `ClusterRoleBinding` existe. ``` kubectl describe clusterrolebinding eks:node-manager ``` Si elle est présente, comparez la sortie à l'exemple de la `ClusterRoleBinding`précédente. Si vous avez identifié un `ClusterRole` ou un `ClusterRoleBinding` manquant ou défectueux comme cause d’une erreur `AcessDenied` lors de la demande d’opérations sur le groupe de nœuds gérés, vous pouvez les restaurer. Enregistrez le contenu suivant dans un fichier nommé *eks-node-manager-role.yaml*. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: eks:node-manager rules: - apiGroups: - '' resources: - pods verbs: - get - list - watch - delete - apiGroups: - '' resources: - nodes verbs: - get - list - watch - patch - apiGroups: - '' resources: - pods/eviction verbs: - create --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks:node-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-manager subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: eks:node-manager ``` Appliquez le fichier. ``` kubectl apply -f eks-node-manager-role.yaml ``` Réessayez l'opération de groupe de nœuds pour voir si cela a résolu votre problème. ## `Not authorized for images` Une cause potentielle du message d’erreur `Not authorized for images` est l’utilisation d’une AMI Windows Amazon EKS privée pour lancer des groupes de nœuds gérés Windows. Après la sortie de nouveaux Windows AMIs, AWS AMIs les versions datant de plus de 4 mois deviennent privées, ce qui les rend inaccessibles. Si votre groupe de nœuds gérés utilise une AMI Windows privée, envisagez de [mettre à jour votre groupe de nœuds gérés Windows](update-managed-node-group.md). Bien que nous ne puissions pas garantir que nous puissions fournir un accès à AMIs ce qui a été rendu privé, vous pouvez demander l'accès en déposant un ticket auprès du AWS Support. Pour plus d’informations, consultez [Correctifs](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-windows-ami.html#ami-patches-security-ID) dans le *Guide de l’utilisateur Amazon EC2*. ## Le nœud est dans l’état `NotReady` Si votre nœud passe à l’état `NotReady`, cela indique probablement que le nœud est en mauvais état et indisponible pour planifier de nouveaux pods. Cela peut se produire pour diverses raisons, par exemple si le nœud ne dispose pas de ressources suffisantes pour le processeur, la mémoire ou l’espace disque disponible. Pour Windows optimisé pour Amazon EKS AMIs, aucune réservation n'est prévue pour les ressources de calcul spécifiées par défaut dans la `kubelet` configuration. [Pour éviter les problèmes de ressources, vous pouvez réserver des ressources de calcul pour les processus du système en `kubelet` fournissant des valeurs de configuration pour [Kube-reserved system-reserved.](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#kube-reserved) and/or ](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved) Pour ce faire, utilisez le paramètre de ligne de commande `-KubeletExtraArgs` dans le script d’initialisation. Pour plus d’informations, consultez [Réserver des ressources de calcul pour les démons système](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/) dans la documentation Kubernetes et [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) dans ce guide d’utilisation. ## Collecteur de journaux EKS Pour résoudre les problèmes liés aux nœuds Amazon EKS, un script pré-créé est disponible sur les nœuds à l’emplacement `/etc/eks/log-collector-script/eks-log-collector.sh`. Vous pouvez utiliser le script pour collecter des journaux de diagnostic pour les cas de support et le dépannage général. Utilisez la commande suivante pour exécuter le script sur votre nœud : ``` sudo bash /etc/eks/log-collector-script/eks-log-collector.sh ``` **Note** Si le script n’est pas présent à cet emplacement. Vous pouvez manuellement télécharger et exécuter le script à l'aide de la commande suivante : ``` curl -O https://amazon-eks.s3.amazonaws.com/support/log-collector-script/linux/eks-log-collector.sh sudo bash eks-log-collector.sh ``` Le script collecte les informations de diagnostic suivantes. ``` $ sudo bash /etc/eks/log-collector-script/eks-log-collector.sh This is version 0.7.8. New versions can be found at https://github.com/awslabs/amazon-eks-ami/blob/main/log-collector-script/ Trying to collect common operating system logs... Trying to collect kernel logs... Trying to collect mount points and volume information... ... ... Done... your bundled logs are located in /var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz ``` Les informations de diagnostic sont collectées et stockés dans : ``` /var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz ``` Pour récupérer le lot de journaux pour les nœuds Bottlerocket, veuillez vous reporter à la section [Journal Bottlerocket](https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#logs) pour plus de détails. ## Le réseau d'exécution du conteneur n'est pas prêt Vous pouvez recevoir une erreur `Container runtime network not ready` et des erreurs d'autorisation similaires aux suivantes : ``` 4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized 4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized 4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized 4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized ``` Les raisons possibles sont les suivantes : 1. Soit vous ne disposez pas d’un `aws-auth` `ConfigMap` sur votre cluster, soit celui-ci ne contient pas les entrées pour le rôle IAM avec lequel vous avez configuré vos nœuds. Pour résoudre le problème, consultez les entrées existantes dans votre *my-cluster* en remplaçant la commande suivante `ConfigMap` par le nom de votre cluster, puis en exécutant la commande modifiée :`eksctl get iamidentitymapping --cluster my-cluster `. Si vous recevez un message d’erreur de la commande, cela peut être dû au fait que votre cluster ne dispose pas d’un `aws-auth` `ConfigMap`. La commande suivante ajoute une entrée à la `ConfigMap`. Si le `ConfigMap` n’existe pas, la commande le crée également. *111122223333*Remplacez-le par l'ID de AWS compte du rôle IAM et *myAmazonEKSNodeRole* par le nom du rôle de votre nœud. ``` eksctl create iamidentitymapping --cluster my-cluster \ --arn arn:aws: iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \ --username system:node:{{EC2PrivateDNSName}} ``` L’ARN du rôle que vous spécifiez ne peut pas inclure de [chemin](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) autre que `/`. Par exemple, si le nom de votre rôle est `development/apps/my-role`, vous devez le remplacer par `my-role` lorsque vous spécifiez l’ARN du rôle. Assurez-vous que vous spécifiez l'ARN pour le rôle IAM du nœud (et non l'ARN du profil d'instance). 1. Vos nœuds autogérés se trouvent dans un cluster dont la version de plateforme correspond à la version minimale indiquée dans les conditions préalables de la rubrique [Accorder aux utilisateurs IAM l’accès à Kubernetes avec des entrées d’accès EKS](access-entries.md), mais aucune entrée n’est répertoriée dans le `aws-auth` `ConfigMap` (voir élément précédent) pour le rôle IAM du nœud ou aucune entrée d’accès n’existe pour le rôle. Pour résoudre le problème, consultez vos entrées d'accès existantes *my-cluster* en remplaçant la commande suivante par le nom de votre cluster, puis en exécutant la commande modifiée :`aws eks list-access-entries --cluster-name my-cluster `. La commande suivante ajoute une entrée d’accès pour le rôle IAM du nœud. *111122223333*Remplacez-le par l'ID de AWS compte du rôle IAM et *myAmazonEKSNodeRole* par le nom du rôle de votre nœud. Si vous possédez un nœud Windows, remplacez-le *EC2\$1LINUX* par`EC2_Windows`. Assurez-vous que vous spécifiez l'ARN pour le rôle IAM du nœud (et non l'ARN du profil d'instance). ``` aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/myAmazonEKSNodeRole --type EC2_LINUX ``` ## Délai d'expiration de la liaison TLS Lorsqu'un nœud est incapable d'établir une connexion avec le point de terminaison du serveur d'API public, vous pouvez voir une erreur similaire à l'erreur suivante. ``` server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post net/http: TLS handshake timeout\"" ``` Le processus `kubelet` se reproduira continuellement et testera le point de terminaison du serveur d'API. L'erreur peut également se produire temporairement au cours de toute procédure qui effectue une mise à jour continue du cluster dans le plan de contrôle, telle qu'une modification de configuration ou une mise à jour de version. Pour résoudre le problème, vérifiez la table de routage et les groupes de sécurité pour vous assurer que le trafic provenant des nœuds peut atteindre le point de terminaison public. ## InvalidClientTokenId Si vous utilisez des rôles IAM pour les comptes de service d'un pod ou si vous êtes DaemonSet déployé sur un cluster dans une AWS région de Chine, et que vous n'avez pas défini la variable d'`AWS_DEFAULT_REGION`environnement dans la spécification, le pod ou le pod DaemonSet peut recevoir le message d'erreur suivant : ``` An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid ``` Pour résoudre le problème, vous devez ajouter la variable d'`AWS_DEFAULT_REGION`environnement à votre Pod ou à votre DaemonSet spécification, comme indiqué dans l'exemple de spécification de Pod suivant. ``` apiVersion: v1 kind: Pod metadata: name: envar-demo labels: purpose: demonstrate-envars spec: containers: - name: envar-demo-container image: gcr.io/google-samples/node-hello:1.0 env: - name: AWS_DEFAULT_REGION value: "region-code" ``` ## Les groupes de nœuds doivent correspondre à la version Kubernetes avant de mettre à niveau le plan de contrôle Avant de mettre à niveau un plan de contrôle vers une nouvelle version Kubernetes, la version mineure des nœuds gérés et Fargate de votre cluster doit être identique à la version actuelle de votre plan de contrôle. L'API `update-cluster-version` Amazon EKS rejette les demandes tant que vous n'avez pas mis à niveau tous les nœuds gérés par Amazon EKS vers la version actuelle du cluster. Amazon EKS permet APIs de mettre à niveau les nœuds gérés. Pour plus d’informations sur la mise à niveau de la version Kubernetes d’un groupe de nœuds gérés, consultez [Mettre à jour un groupe de nœuds gérés pour votre cluster](update-managed-node-group.md). Pour mettre à niveau la version d’un nœud Fargate, supprimez le pod représenté par le nœud et redéployez-le après avoir mis à niveau votre plan de contrôle. Pour de plus amples informations, veuillez consulter [Mettre à jour un cluster existant vers une nouvelle version de Kubernetes](update-cluster.md). ## Lors du lancement de nombreux nœuds, des erreurs `Too Many Requests` se produisent Si vous lancez plusieurs nœuds simultanément, vous pouvez voir un message d'erreur dans les journaux d'exécution des [données utilisateur Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html#user-data-shell-scripts) indiquant `Too Many Requests`. Cela peut se produire parce que le plan de contrôle est surchargé d'appels `describeCluster`. Cette surcharge se traduit par une limitation, des nœuds qui ne parviennent pas à exécuter le script d'amorçage et des nœuds qui ne parviennent pas à rejoindre le cluster. Assurez-vous que les arguments `--apiserver-endpoint`, `--b64-cluster-ca` et `--dns-cluster-ip` sont transmis au script de démarrage du nœud. Lorsque vous incluez ces arguments, le script d’initialisation n’a pas besoin d’effectuer d’appel `describeCluster`, ce qui permet d’éviter la surcharge du plan de contrôle. Pour de plus amples informations, veuillez consulter [Fournissez des données utilisateur pour transmettre des arguments au `bootstrap.sh` fichier inclus dans une Linux/Bottlerocket AMI optimisée pour Amazon EKS](launch-templates.md#mng-specify-eks-ami). ## Réponse d'erreur non autorisée HTTP 401 sur les requêtes du serveur API Kubernetes Ces erreurs s’affichent si le jeton de compte de service d’un pod a expiré sur un cluster. Le serveur API Kubernetes de votre cluster Amazon EKS rejette les demandes dont les jetons datent de plus de 90 jours. Dans les versions précédentes de Kubernetes, les jetons n'avaient pas de période d'expiration. Cela signifie que les clients qui s'appuient sur ces jetons doivent les actualiser dans l'heure. Pour éviter que le serveur API Kubernetes ne rejette votre demande en raison d’un jeton non valide, la version du [kit SDK client Kubernetes](https://kubernetes.io/docs/reference/using-api/client-libraries/) utilisée par votre charge de travail doit être identique ou postérieure aux versions suivantes : + Go version `0.15.7` et ultérieure + Python version `12.0.0` et ultérieure + Java version `9.0.0` et ultérieure + JavaScript version `0.10.3` et versions ultérieures + Branche `master` Ruby + Haskell version `0.3.0.0` + Version C\$1 `7.0.5` et ultérieure Vous pouvez identifier tous les pod existants dans votre cluster qui utilisent des jetons périmés. Pour de plus amples informations, veuillez consulter [Jetons de compte de service](service-accounts.md#service-account-tokens). ## La version de la plateforme Amazon EKS est inférieure de plus de deux versions à la version actuelle de la plateforme Cela peut se produire lorsque Amazon EKS n’est pas en mesure de mettre à jour automatiquement la [platform-version](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) de votre cluster. Bien qu'il existe de nombreuses causes à cela, certaines des causes les plus courantes suivent. Si l’un de ces problèmes s’applique à votre cluster, celui-ci peut continuer à fonctionner, mais sa version de plateforme ne sera pas mise à jour par Amazon EKS. **Problème** Le [Rôle IAM du cluster](cluster-iam-role.md) a été supprimé : ce rôle a été spécifié lors de la création du cluster. Vous pouvez voir quel rôle a été spécifié à l'aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster. ``` aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2 ``` L'exemple qui suit illustre un résultat. ``` eksClusterRole ``` **Solution** Création d'un nouveau [rôle IAM du cluster](cluster-iam-role.md) portant le même nom. **Problème** Un sous-réseau spécifié lors de la création du cluster a été supprimé : les sous-réseaux à utiliser avec le cluster ont été spécifiés lors de la création du cluster. Vous pouvez voir quels sous-réseaux ont été spécifiés à l'aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster. ``` aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.subnetIds ``` L'exemple qui suit illustre un résultat. ``` [ "subnet-EXAMPLE1", "subnet-EXAMPLE2" ] ``` **Solution** Vérifiez si le sous-réseau IDs existe dans votre compte. ``` vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text) aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId" ``` L'exemple qui suit illustre un résultat. ``` [ "subnet-EXAMPLE3", "subnet-EXAMPLE4" ] ``` Si le sous-réseau IDs renvoyé dans la sortie ne correspond pas au sous-réseau spécifié lors de la création du cluster, si vous souhaitez IDs qu'Amazon EKS mette à jour le cluster, vous devez modifier les sous-réseaux utilisés par le cluster. En effet, si vous avez spécifié plus de deux sous-réseaux lors de la création de votre cluster, Amazon EKS sélectionne de manière aléatoire les sous-réseaux que vous avez spécifiés pour y créer de nouvelles interfaces réseau Elastic. Ces interfaces réseau permettent au plan de contrôle de communiquer avec vos nœuds. Amazon EKS ne mettra pas à jour le cluster si le sous-réseau qu’il sélectionne n’existe pas. Vous n'avez aucun contrôle sur les sous-réseaux que vous avez spécifiés lors de la création du cluster dans lesquels Amazon EKS choisit de créer une nouvelle interface réseau. Lorsque vous lancez une mise à jour de la version Kubernetes pour votre cluster, la mise à jour peut échouer pour la même raison. **Problème** Un groupe de sécurité spécifié lors de la création du cluster a été supprimé : si vous avez spécifié des groupes de sécurité lors de la création du cluster, vous pouvez les voir à l' IDs aide de la commande suivante. Remplacez *my-cluster* par le nom de votre cluster. ``` aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds ``` L'exemple qui suit illustre un résultat. ``` [ "sg-EXAMPLE1" ] ``` Si `[]` est renvoyé, cela signifie qu’aucun groupe de sécurité n’a été spécifié lors de la création du cluster et que l’absence de groupe de sécurité n’est pas le problème. Si des groupes de sécurité sont renvoyés, vérifiez qu'ils existent dans votre compte. **Solution** Vérifiez si ces groupes de sécurité existent dans votre compte. ``` vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text) aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId" ``` L'exemple qui suit illustre un résultat. ``` [ "sg-EXAMPLE2" ] ``` Si le groupe de sécurité IDs renvoyé dans la sortie ne correspond pas au groupe de sécurité spécifié lors de la création du cluster, si vous souhaitez IDs qu'Amazon EKS mette à jour le cluster, vous devez modifier les groupes de sécurité utilisés par le cluster. Amazon EKS ne met pas à jour un cluster si le groupe de sécurité IDs spécifié lors de la création du cluster n'existe pas. Lorsque vous lancez une mise à jour de la version Kubernetes pour votre cluster, la mise à jour peut échouer pour la même raison. + Vous ne disposez pas d’au moins six (bien que nous recommandions 16) adresses IP disponibles dans chacun des sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Si vous ne disposez pas d’un nombre suffisant d’adresses IP disponibles dans le sous-réseau, vous devez soit libérer des adresses IP dans le sous-réseau, soit modifier les sous-réseaux utilisés par le cluster afin d’utiliser des sous-réseaux disposant d’un nombre suffisant d’adresses IP disponibles. + Vous avez activé [le chiffrement secret](enable-kms.md) lorsque vous avez créé votre cluster et la clé AWS KMS que vous avez spécifiée a été supprimée. Si vous souhaitez qu'Amazon EKS mette à jour le cluster, vous devez créer un nouveau cluster ## Codes d'erreur FAQs et d'intégrité du cluster avec chemins de résolution Amazon EKS détecte les problèmes liés à vos clusters EKS et à l’infrastructure du cluster, puis les stocke dans l’objet *health* de votre ressource de cluster EKS. Vous pouvez détecter et résoudre les problèmes de cluster plus rapidement à l'aide des informations relatives à l'état du cluster. Cela vous permet de créer des environnements d'applications plus sécurisés et up-to-date. De plus, il peut vous être impossible de mettre à niveau vers des versions plus récentes de Kubernetes ou d’Amazon EKS d’installer des mises à jour de sécurité sur un cluster dégradé en raison de problèmes liés à l’infrastructure nécessaire ou à la configuration du cluster. Amazon EKS peut mettre 3 heures pour détecter les problèmes ou détecter qu'un problème est résolu. La santé d'un cluster Amazon EKS est une responsabilité partagée entre Amazon EKS et ses utilisateurs. Vous êtes responsable de l'infrastructure préalable des rôles IAM et des sous-réseaux Amazon VPC, ainsi que des autres infrastructures nécessaires, qui doivent être fournies à l'avance. Amazon EKS détecte les modifications apportées à la configuration de cette infrastructure et du cluster. Pour accéder à l’état de votre cluster dans la console Amazon EKS, recherchez un tableau intitulé **Problèmes d’état** dans l’onglet **Problèmes d’état du cluster** du tableau de bord d’observabilité accessible depuis la page de détails du cluster Amazon EKS. Ces données seront également disponibles en appelant l'`DescribeCluster`action dans l'API EKS, par exemple depuis l'interface de ligne de AWS commande. **Pourquoi utiliser cette fonctionnalité ?** Vous bénéficierez d'une visibilité accrue sur l'état de santé de votre cluster Amazon EKS, diagnostiquerez et résoudrez rapidement les problèmes, sans avoir à passer du temps à déboguer ou à ouvrir des dossiers de AWS support. Par exemple : vous avez accidentellement supprimé un sous-réseau pour le cluster Amazon EKS, Amazon EKS ne sera pas en mesure de créer des interfaces réseau entre comptes et des commandes de la AWS CLI Kubernetes `kubectl` telles que exec ou logs. `kubectl` L'erreur suivante s'affiche : `Error from server: error dialing backend: remote error: tls: internal error.` Le problème d'état Amazon EKS indique : `subnet-da60e280 was deleted: could not create network interface`. **Comment cette fonctionnalité est-elle liée ou fonctionne-t-elle avec d'autres AWS services ?** Les rôles IAM et les sous-réseaux Amazon VPC sont deux exemples d'infrastructure préalable avec laquelle l'état du cluster détecte les problèmes. Cette fonctionnalité renvoie des informations détaillées si ces ressources ne sont pas correctement configurées. **Un cluster présentant des problèmes d’état entraîne-t-il des frais ?** Oui, chaque cluster Amazon EKS est facturé au tarif standard d'Amazon EKS. La fonctionnalité liée à l'*état du cluster* est disponible sans frais supplémentaires. **Cette fonctionnalité fonctionne-t-elle avec les clusters Amazon EKS sur AWS Outposts ?** Oui, des problèmes de cluster sont détectés pour les clusters EKS dans le AWS cloud, y compris les *clusters étendus* sur les AWS Outposts et les *clusters locaux* sur les AWS Outposts. L’état du cluster ne détecte pas les problèmes avec Amazon EKS Anywhere ou Amazon EKS Distro (EKS-D). **Puis-je être averti lorsque de nouveaux problèmes sont détectés ?** Oui. AWS envoie un e-mail et une notification au Personal Health Dashboard lorsque de nouveaux problèmes de santé du cluster sont détectés. **La console m’avertit-elle des problèmes d’état ?** Oui, tout cluster présentant des problèmes d'état présentera une bannière en haut de la console. Les deux premières colonnes sont celles qui sont nécessaires pour les valeurs de réponse de l'API. Le troisième champ de l' ClusterIssueobjet [Health](https://docs.aws.amazon.com/eks/latest/APIReference/API_ClusterIssue.html) est ResourceIds, dont le retour dépend du type de problème. | Code | Message | ResourceIds | Le cluster est-il récupérable ? | | --- | --- | --- | --- | | SUBNET\$1NOT\$1FOUND | Nous n’avons pas pu trouver un ou plusieurs sous-réseaux actuellement associés à votre cluster. Appelez l'API update-cluster-config Amazon EKS pour mettre à jour les sous-réseaux. | ID de sous-réseaux | Oui | | SECURITY\$1GROUP\$1NOT\$1FOUND | Nous n’avons pas pu trouver un ou plusieurs groupes de sécurité actuellement associés à votre cluster. Appelez l' update-cluster-configAPI Amazon EKS pour mettre à jour les groupes de sécurité | ID de groupe de sécurité | Oui | | IP\$1NOT\$1AVAILABLE | Un ou plusieurs sous-réseaux associés à votre cluster ne disposent pas d'un nombre suffisant d'adresses IP pour qu'Amazon EKS puisse effectuer des opérations de gestion de cluster. Libérez des adresses dans le ou les sous-réseaux ou associez différents sous-réseaux à votre cluster à l'aide de l'API Amazon EKS update-cluster-config. | ID de sous-réseaux | Oui | | VPC\$1NOT\$1FOUND | Nous n’avons pas pu trouver le VPC associé à votre cluster. Vous devez supprimer et recréer votre cluster. | ID du VPC | Non | | ASSUME\$1ROLE\$1ACCESS\$1DENIED | Votre cluster n'utilise pas Amazon EKS service-linked-role. Nous n’avons pas pu assumer le rôle associé à votre cluster pour effectuer les opérations de gestion Amazon EKS requises. Vérifiez que le rôle existe et qu'il dispose de la politique de confiance requise. | Rôle IAM du cluster | Oui | | PERMISSION\$1ACCESS\$1DENIED | Votre cluster n'utilise pas Amazon EKS service-linked-role. Le rôle associé à votre cluster n'accorde pas les autorisations suffisantes à Amazon EKS pour effectuer les opérations de gestion requises. Vérifiez les politiques associées au rôle de cluster et si des politiques de refus distinctes sont appliquées. | Rôle IAM du cluster | Oui | | ASSUME\$1ROLE\$1ACCESS\$1DENIED\$1USING\$1SLR | Nous ne pouvions pas assumer la gestion du cluster Amazon EKS service-linked-role. Vérifiez que le rôle existe et qu'il dispose de la politique de confiance requise. | L'Amazon EKS service-linked-role | Oui | | PERMISSION\$1ACCESS\$1DENIED\$1USING\$1SLR | La gestion du cluster Amazon EKS service-linked-role n'accorde pas d'autorisations suffisantes à Amazon EKS pour effectuer les opérations de gestion requises. Vérifiez les politiques associées au rôle de cluster et si des politiques de refus distinctes sont appliquées. | L'Amazon EKS service-linked-role | Oui | | OPT\$1IN\$1REQUIRED | Votre compte ne dispose pas d’un abonnement au service Amazon EC2. Mettez à jour les abonnements de votre compte sur la page des paramètres de votre compte. | N/A | Oui | | STS\$1REGIONAL\$1ENDPOINT\$1DISABLED | Le point de terminaison régional STS est désactivé. Activez le point de terminaison pour qu'Amazon EKS effectue les opérations de gestion de cluster requises. | N/A | Oui | | KMS\$1KEY\$1DISABLED | La clé AWS KMS associée à votre cluster est désactivée. Réactivez la clé pour récupérer votre cluster. | L’ARN de la clé KMS | Oui | | KMS\$1KEY\$1NOT\$1FOUND | Nous n'avons pas trouvé la clé AWS KMS associée à votre cluster. Vous devez supprimer et recréer le cluster. | L’ARN de la clé KMS | Non | | KMS\$1GRANT\$1REVOKED | Les autorisations pour la clé AWS KMS associée à votre cluster sont révoquées. Vous devez supprimer et recréer le cluster. | L’ARN de la clé KMS | Non | | ETCD\$1DB\$1SIZE\$1EXCEEDED | Votre cluster Amazon EKS a dépassé la limite de taille de base de données etcd. etcd est un magasin de données clé-valeur qui s'exécute dans le plan de contrôle Kubernetes et conserve la configuration et l'état de votre cluster. Pour éviter que votre cluster n'entre dans un état dégradé, réduisez la taille de la base de données etcd en supprimant les objets Kubernetes inutiles. Pour obtenir des conseils sur l'identification et le nettoyage des objets qui contribuent à la taille de la base de données, consultez la section [Gestion de la taille de la base de données etcd sur les clusters Amazon EKS](https://aws.amazon.com/blogs/containers/managing-etcd-database-size-on-amazon-eks-clusters/). Si les problèmes persistent après le nettoyage, contactez le AWS Support. | L'ARN du cluster | Oui |