Capacité insuffisante Les nœuds ne parviennent pas à joindre le cluster Accès non autorisé ou refusé (kubectl)hostname doesn't match getsockopt: no route to host Instances failed to join the Kubernetes cluster Codes d'erreurs liées aux groupes de nœuds gérés Not authorized for images Le nœud est en NotReady état Outil de collecte de journaux CNI Le réseau d'exécution du conteneur n'est pas prêt Délai d'expiration de la liaison TLS InvalidClientTokenId Expiration du certificat webhook d'admission VPC Les groupes de nœuds doivent correspondre à la version de Kubernetes avant de mettre à niveau le plan de contrôle Lors du lancement de nombreux nœuds, des erreurs Too Many Requests se produisent Erreurs non autorisées HTTP 401 Version antérieure de la plateforme FAQ sur l'état du cluster et codes d'erreur avec chemins de résolution

Dépannage d'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, Résolution des problèmes dans Amazon EKS Connector et Dépannage d'ADOT à l'aide de modules complémentaires EKS.

Pour obtenir d'autres informations permettant de résoudre les problèmes, consultez la section Contenu du centre de connaissances concernant Amazon Elastic Kubernetes Service sur AWS re:Post.

Capacité insuffisante

Si vous recevez le message d'erreur suivant lorsque vous tentez de créer un cluster Amazon EKS, cela signifie que l'une des zones de disponibilité 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. Comparez les zones de disponibilité dans lesquelles se trouvent vos sous-réseaux avec la liste des zones de disponibilité figurant dans les Exigences et considérations requises pour les sous-réseaux.

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 entrées actuelles de ConfigMap aws-auth en remplaçant my-cluster dans la commande suivante par le nom de votre cluster et 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 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 pour l’ARN du rôle IAM du nœud, exécutez les mêmes commandes 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 Gérer les entrées d'accès.
Le AWS CloudFormation modèle ClusterNamede votre nœud ne correspond pas exactement au nom du cluster que vous souhaitez que vos nœuds rejoignent. Une valeur incorrecte pour ce champ génère une configuration incorrecte du fichier /var/lib/kubelet/kubeconfig du nœud, et les nœuds ne seront pas en mesure de joindre 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.

Clé	Valeur
`kubernetes.io/cluster/my-cluster`	`owned`

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 élastique à 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. 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 Modification de l'attribut d'adressage IPv4 public de votre sous-réseau. 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 AWS STS point de terminaison sur Région AWS lequel vous déployez les nœuds n'est pas activé pour votre compte. Pour activer la région, voir Activation et désactivation AWS STS dans un Région AWS.
Le nœud n'a pas d'entrée DNS privée, ce qui fait que le journal kubelet contient une erreur 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:<region>.compute.internal et domain-name-servers:AmazonProvidedDNS. Pour en savoir plus, consultez Jeux d'options DHCP 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 d'état de « NodeCreationFailure » sera émis et le statut de la console sera défini surCreate failed. Pour les Windows AMI dont les temps de lancement sont lents, ce problème peut être résolu grâce au lancement rapide.

Pour identifier et résoudre les problèmes courants qui empêchent les composants master de rejoindre un cluster, vous pouvez utiliser le runbookAWSSupport-TroubleshootEKSWorkerNode. Pour plus d'informations, consultez AWSSupport-TroubleshootEKSWorkerNode dans la référence AWS Systems Manager Automation runbook.

Accès non autorisé ou refusé (`kubectl`)

Si vous obtenez l'une des erreurs suivantes lors de l'exécution de commandes kubectl, votre kubectl n'est pas correctement configuré pour Amazon EKS, ou les informations d'identification du principal IAM (rôle ou utilisateur) que vous utilisez ne sont pas mappées vers un nom d'utilisateur Kubernetes disposant des autorisations suffisantes pour des objets Kubernetes dans 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 plus d’informations, consultez Création ou mise à jour d'un fichier kubeconfig pour un cluster Amazon EKS.
Si votre cluster répond aux exigences de plateforme minimales indiquées dans la section des conditions préalables des Gérer les entrées d'accès, aucune entrée d’accès n’existe auprès de votre principal IAM. Si elle existe, elle n’a pas les noms de groupe Kubernetes nécessaires définis ou n’a pas la bonne stratégie d’accès associée. Pour plus d’informations, consultez Gérer les entrées d'accès.
Si votre cluster ne répond pas aux exigences de plateforme minimales indiquées dans la section Gérer les entrées d'accès, aucune entrée d'accès n'existe auprès de votre principal IAM dans la ConfigMap aws-auth. Si elle existe, elle n’est pas mappée vers les noms de groupes Kubernetes liés à un Role ou ClusterRole Kubernetes dotés des autorisations nécessaires. Pour plus d'informations sur les objets de contrôle d'autorisation basé sur les rôles (RBAC) de Kubernetes, consultez la rubrique Utilisation de l'autorisation RBAC de la documentation Kubernetes. Vous pouvez afficher vos entrées actuelles de ConfigMap aws-auth en remplaçant my-cluster dans la commande suivante par le nom de votre cluster et en exécutant la commande modifiée : eksctl get iamidentitymapping --cluster my-cluster. Si aucune entrée contenant l’ARN de votre principal IAM ne figure dans ConfigMap, entrez eksctl create iamidentitymapping --help dans votre terminal pour savoir comment en créer une.

Si vous installez et configurez le AWS CLI, vous pouvez configurer les informations d'identification IAM que vous utilisez. Pour plus d'informations, veuillez consulter configuration de l'outil AWS CLI dans le guide de l'utilisateur de l'outil AWS Command Line Interface . Vous pouvez également configurer kubectl pour utiliser un rôle IAM, si vous assumez un rôle IAM pour accéder aux objets Kubernetes de votre cluster. Pour plus d’informations, consultez Création ou mise à jour d'un fichier kubeconfig pour un cluster Amazon EKS.

`hostname doesn't match`

La version Python de votre système doit être la version 2.7.9 ou une version ultérieure. Dans le cas contraire, vous recevrez hostname doesn't match des erreurs lors AWS CLI des appels vers Amazon EKS. Pour de plus amples informations, veuillez consulter Que sont les erreurs « hostname doesn't match » ? dans les Questions fréquentes (FAQ) relatives aux 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 veiller à ce que les sous-réseaux VPC de votre cluster ne chevauchent pas cette plage. Sinon, vous recevrez l'erreur suivante :

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>: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 plus d’informations, consultez Contrôle d'accès au point de terminaison du cluster Amazon EKS..

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 d'Amazon EC2. 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 à procéder à l'authentification ou à obtenir l'autorisation avec le serveur d'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. Les AMI Windows privées peuvent également provoquer ce code d'erreur à côté du message d'erreur Not authorized for images. Pour plus d’informations, consultez Not authorized for images.

AmiIdNotFound

Nous n'avons pas pu trouver l'ID d'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 pu trouver 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 peuvent pas communiquer avec le serveur d'API de votre 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 pu trouver le groupe de sécurité de cluster pour le 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 pu trouver 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 de 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 pu trouver 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 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 et Considérations et exigences relatives aux groupes de sécurité Amazon EKS.
Vos nœuds et VPC doivent répondre aux exigences dans Exigences relatives aux clusters privés.

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'un nombre suffisant d'adresses IP pour de nouveaux nœuds.

InternalFailure

Ces erreurs sont généralement dues à un problème côté serveur Amazon EKS.

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 ClusterRolepré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 ClusterRoleBindingprécédente.

Si vous avez identifié une ClusterRole ou ClusterRoleBinding manquante ou cassée comme la cause d'une erreur AcessDenied lors de la demande d'opérations de 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`

L'une des causes potentielles d'un 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 Windows gérés. Après avoir publié de nouvelles Windows AMI, AWS les AMI 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 Windows AMI privée, pensez à mettre à jour votre groupe de nœuds Windows gérés. Bien que nous ne puissions pas garantir l'accès aux AMI qui ont été rendues privées, vous pouvez demander l'accès en déposant un ticket auprès du AWS Support. Pour plus d'informations, consultez Correctifs, mises à jour de sécurité et ID d'AMI dans le Guide de l'utilisateur Amazon EC2 pour les instances Windows.

Le nœud est en `NotReady` état

Si votre nœud entre dans un NotReady état, cela indique probablement qu'il n'est pas en bon état et qu'il n'est pas disponible pour en planifier un nouveauPods. Cela peut se produire pour diverses raisons, telles que le fait que le nœud ne dispose pas de ressources suffisantes pour le processeur, la mémoire ou l'espace disque disponible.

Pour les Windows AMI optimisées pour Amazon EKS, 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 fournissant kubelet des valeurs de configuration pour kube-reservedet/ou system-reserved. Pour ce faire, utilisez le paramètre de -KubeletExtraArgs ligne de commande du script bootstrap. Pour plus d'informations, consultez la section Reserve Compute Resources for System Daemons dans la Kubernetes documentation et les paramètres de configuration du script Bootstrap dans ce guide de l'utilisateur.

Outil de collecte de journaux CNI

Le Amazon VPC CNI plugin for pour Kubernetes dispose de son propre script de dépannage disponible sur les nœuds au niveau de /opt/cni/bin/aws-cni-support.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 /opt/cni/bin/aws-cni-support.sh

Note

Si le script n'est pas présent dans cet emplacement, alors le conteneur CNI n'a pas pu être exécuté. Vous pouvez manuellement télécharger et exécuter le script à l'aide de la commande suivante :


curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

Le script collecte les informations de diagnostic suivantes. La version CNI que vous avez déployée peut être antérieure à la version du script.

      This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami

Trying to collect common operating system logs... 
Trying to collect kernel logs... 
Trying to collect mount points and volume information... 
Trying to collect SELinux status... 
Trying to collect iptables information... 
Trying to collect installed packages... 
Trying to collect active system services... 
Trying to collect Docker daemon information... 
Trying to collect kubelet information... 
Trying to collect L-IPAMD information... 
Trying to collect sysctls information... 
Trying to collect networking information... 
Trying to collect CNI configuration information... 
Trying to collect running Docker containers and gather container data... 
Trying to collect Docker daemon logs... 
Trying to archive gathered information... 

	Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Les informations de diagnostic sont collectées et stockés dans :


/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

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 :

Soit vous n’avez pas de ConfigMap aws-auth sur votre cluster, soit celui-ci n’inclut pas d’entrées pour le rôle IAM avec lequel vous avez configuré vos nœuds.

Cette entrée ConfigMap est nécessaire si vos nœuds répondent à l’un des critères suivants :
- Nœuds gérés dans un cluster avec n’importe quelle version Kubernetes ou version de plateforme.
- Nœuds autogérés dans un cluster antérieur à l’une des versions de plateforme répertoriées dans la section des conditions préalables de la rubrique Gérer les entrées d'accès.
Pour résoudre le problème, affichez les entrées existantes de votre ConfigMap en remplaçant my-cluster dans la commande suivante par le nom de votre cluster et en exécutant la commande modifiée : eksctl get iamidentitymapping --cluster my-cluster. Si vous commande renvoie un message d’erreur, cela peut être dû au fait que votre cluster ne possède pas de ConfigMap aws-auth. La commande suivante ajoute une entrée à la ConfigMap. Si la ConfigMap n'existe pas, la commande peut également la créer. Remplacez 111122223333 par l' Compte AWS ID du rôle IAM et MyAmazoneks NodeRole 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 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).
Vos nœuds autogérés font partie d’un cluster dont la version de plateforme est la version minimale répertoriée dans les conditions requises de la rubrique Gérer les entrées d'accès, mais aucune entrée n’est répertoriée dans la ConfigMap aws-auth (voir point 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, affichez vos entrées existantes en remplaçant my-cluster dans la commande suivante par le nom de votre cluster et 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. Remplacez 111122223333 par l' Compte AWS ID du rôle IAM et MyAmazoneks NodeRole par le nom du rôle de votre nœud. Si vous avez un nœud Windows, remplacez EC2_Linux 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 cluster en Chine Pod ou que vous l'avez DaemonSet déployé sur un cluster Région AWS, et que vous n'avez pas défini la variable d'AWS_DEFAULT_REGIONenvironnement dans la spécification, le Pod ou 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'environnement AWS_DEFAULT_REGION à votre spécification de Pod ou de DaemonSet, comme indiqué dans l'exemple suivant de spécification de Pod.


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"

Expiration du certificat webhook d'admission VPC

Si le certificat utilisé pour signer le webhook d'admission VPC expire, l'état des nouveaux déploiements de Pod Windowsreste à ContainerCreating.

Pour résoudre le problème si vous disposez d'un support Windows hérité sur votre plan de données, consultez Renouvellement du certificat du webhook d'admission VPC. Si la version de votre cluster et de votre plateforme est postérieure à une version répertoriée dans les prérequis à la prise en charge de Windows, nous vous recommandons de supprimer la prise en charge héritée de Windows sur votre plan de données et de l'activer pour votre plan de contrôle. Une fois que vous l'avez fait, vous n'avez pas besoin de gérer le certificat Webhook. Pour plus d’informations, consultez Activation de la prise en charge de Windows pour votre cluster Amazon EKS.

Les groupes de nœuds doivent correspondre à la version de Kubernetes avant de mettre à niveau le plan de contrôle

Avant de mettre à niveau un plan de contrôle vers une nouvelle version de Kubernetes, la version mineure des nœuds gérés et Fargate de votre cluster doit être la même que 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 fournit des API pour 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 Mise à jour d'un groupe de nœuds gérés. Pour mettre à niveau la version d'un nœud Fargate, supprimez le pod représenté par le nœud et redéployez le pod après avoir mis à niveau votre plan de contrôle. Pour plus d’informations, consultez Mise à jour d'une version Kubernetes de cluster Amazon EKS.

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 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 d'amorçage du nœud. Lorsque vous incluez ces arguments, le script d'amorçage n'a pas besoin d'effectuer un appel describeCluster, ce qui permet d'éviter la surcharge du plan de contrôle. Pour plus d’informations, consultez Fournir des données utilisateur pour passer des arguments au fichier bootstrap.sh inclus avec une AMI Linux/Bottlerocket optimisée pour Amazon EKS.

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 d'API Kubernetes de votre cluster Amazon EKS rejette les demandes dont les jetons datent 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 empêcher le serveur d'API Kubernetes de rejeter votre demande en raison d'un jeton non valide, la version du SDK client Kubernetes utilisée par votre charge de travail doit être identique ou ulté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
C# version 7.0.5 et ultérieure

Vous pouvez identifier tous les Pods existants de votre cluster qui utilisent des jetons obsolètes. Pour plus d'informations, consultez comptes de service Kubernetes.

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 lorsqu'Amazon EKS n'est pas en mesure de mettre à jour automatiquement la version de la plateforme 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, il est possible qu'il fonctionne toujours. Sa version de plateforme ne sera tout simplement pas mise à jour par Amazon EKS.

Problème

Le Rôle IAM du cluster 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 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 les ID de sous-réseau existent 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 les ID de sous-réseau renvoyés dans la sortie ne correspondent pas aux ID de sous-réseau spécifiés lors de la création du cluster, vous devez modifier les sous-réseaux utilisés par le cluster si vous souhaitez qu'Amazon EKS mette à jour 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 met 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 voir leurs ID à 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.securityGroupIds

L'exemple qui suit illustre un résultat.

[
    "sg-EXAMPLE1"
]

Si [] est renvoyé, aucun groupe de sécurité n'a été spécifié lors de la création du cluster et un groupe de sécurité manquant 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 les ID des groupes de sécurité renvoyés dans la sortie ne correspondent pas aux ID des groupes de sécurité spécifiés lors de la création du cluster, vous devez modifier les groupes de sécurité utilisés par le cluster si vous souhaitez qu'Amazon EKS mette à jour le cluster. Amazon EKS ne met pas à jour un cluster si les ID de groupe de sécurité spécifiés lors de la création du cluster n'existent pas.

Lorsque vous lancez une mise à jour de la version Kubernetes pour votre cluster, la mise à jour peut échouer pour la même raison.

Autres raisons pour lesquelles Amazon EKS ne met pas à jour la version de plateforme de votre cluster

Vous n'avez pas au moins six (bien que nous en 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 n'avez pas assez 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 pour utiliser des sous-réseaux ayant suffisamment d'adresses IP disponibles.
Vous avez activé le chiffrement des secrets lorsque vous avez créé votre cluster et la AWS KMS clé 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

FAQ sur l'état du cluster et codes d'erreur avec chemins de résolution

Amazon EKS détecte les problèmes liés à vos clusters EKS et à l'infrastructure du cluster et les enregistre dans l'état du cluster. 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. En outre, il peut s'avérer impossible pour vous de passer à des versions plus récentes de Kubernetes ou pour 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 santé de votre cluster dans la console Amazon EKS, consultez la section intitulée Problèmes d'état dans l'onglet Présentation de la page détaillée du cluster Amazon EKS. Ces données sont également disponibles en appelant l'action DescribeCluster dans l'API EKS, par exemple depuis l' AWS Command Line Interface.

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, si 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 et des Kubernetes AWS CLI commandes inter-comptes telles que kubectl exec ou kubectl logs. 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 activés AWS Outposts et les clusters locaux activés AWS Outposts. L'état du cluster ne détecte pas les problèmes liés à Amazon EKS Anywhere ou à Amazon EKS Distro (EKS-D).
Puis-je être averti lorsque de nouveaux problèmes sont détectés ?: Non, vous devez vérifier la console Amazon EKS ou appeler l'API DescribeCluster EKS.
La console m'avertit-elle en cas de problème 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 estresourceIds, dont le retour dépend du type de problème.

Code	Message	ResourceIds	Le cluster est-il récupérable ?
SUBNET_NOT_FOUND	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_GROUP_NOT_FOUND	Nous n'avons pas pu trouver un ou plusieurs groupes de sécurité actuellement associés à votre cluster. Appelez l' update-cluster-config API Amazon EKS pour mettre à jour les groupes de sécurité	ID de groupe de sécurité	Oui
IP_NOT_AVAILABLE	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_NOT_FOUND	Nous n'avons pas pu trouver le VPC associé à votre cluster. Vous devez supprimer et recréer votre cluster.	ID du VPC	Non
ASSUME_ROLE_ACCESS_DENIED	Votre cluster n'utilise pas Amazon EKS service-linked-role. Nous ne pouvions pas 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_ACCESS_DENIED	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_ROLE_ACCESS_DENIED_USING_SLR	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_ACCESS_DENIED_USING_SLR	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_IN_REQUIRED	Votre compte ne possède pas d'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_REGIONAL_ENDPOINT_DISABLED	Le point de terminaison STS régional 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_KEY_DISABLED	La AWS KMS clé associée à votre cluster est désactivée. Réactivez la clé pour récupérer votre cluster.	L'interface KMS Key Arn	Oui
KMS_KEY_NOT_FOUND	Nous n'avons pas trouvé la AWS KMS clé associée à votre cluster. Vous devez supprimer et recréer le cluster.	L'interface KMS Key ARN	Non
KMS_GRANT_REVOKED	Les autorisations pour la AWS KMS clé associée à votre cluster sont révoquées. Vous devez supprimer et recréer le cluster.	L'interface KMS Key Arn	Non

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Amazon Detective

Amazon EKS Connector