Résoudre les problèmes liés aux EKS clusters et aux nœuds Amazon - Amazon EKS

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ésoudre les problèmes liés aux EKS clusters et aux nœuds Amazon

Ce chapitre décrit certaines erreurs courantes que vous pouvez rencontrer lors de l'utilisation d'Amazon EKS et explique comment les contourner. Si vous devez résoudre des problèmes dans des EKS domaines spécifiques d'Amazon, consultez les rubriques séparées Résolution des problèmes IAM et Résolution des problèmes liés à ADOT l'utilisation des EKS modules complémentaires. Résoudre les problèmes liés à Amazon EKS Connector

Pour d'autres informations de dépannage, consultez le contenu du centre de connaissances sur Amazon Elastic Kubernetes Service sur Re:post. AWS

Capacité insuffisante

Si vous recevez le message d'erreur suivant lors de la tentative de création d'un EKS cluster Amazon, 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

Réessayez de créer votre cluster avec des sous-réseaux hébergés dans VPC les zones de disponibilité renvoyées 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 la section Exigences et considérations relatives aux Exigences et considérations requises pour les sous-réseaux 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 au aws-auth ConfigMap 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 consulter vos aws-auth ConfigMap entrées actuelles en remplaçant my-cluster dans la commande suivante avec le nom de votre cluster, puis exécutez la commande modifiée : eksctl get iamidentitymapping --cluster my-cluster. The ARN of the role that you specify can’t include a path other than /. For example, if the name of your role is development/apps/my-role, you’d need to change it to my-role when specifying the ARN for the role. Make sure that you specify the node IAM role ARN (not the instance profile ARN).

    Si les nœuds sont autogérés et que vous n'avez pas créé Octroi IAM accès des utilisateurs à Kubernetes avec entrées EKS d'accès d'entrées ARN d'accès pour le IAM rôle 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 ARN pour le IAM rôle de votre nœud, il se peut qu'elle ne soit pas configurée correctement dans l'entrée d'accès. Assurez-vous que le IAM rôle du nœud ARN (et non le profil de l'instanceARN) est spécifié comme principal ARN dans votre aws-auth ConfigMap entrée ou votre entrée d'accès. Pour plus d'informations sur les entrées d'accès, consultez Octroi IAM accès des utilisateurs à Kubernetes avec entrées EKS 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. La transmission d'une valeur incorrecte à ce champ entraîne une configuration incorrecte du /var/lib/kubelet/kubeconfig fichier du nœud 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.

    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. Dans le cas contraire, 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 la section Modification de l'attribut d'IPv4adressage public de votre sous-réseau. Si le nœud est déployé sur un sous-réseau privé, le sous-réseau doit disposer d'une route vers une NAT passerelle à laquelle une adresse IP publique est attribuée.

  • Le AWS STS point de terminaison 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 AWS STS dans une AWS région.

  • Le nœud ne possède pas d'DNSentrée privée, ce qui entraîne une node "" not found erreur dans le kubelet journal. Assurez-vous que les valeurs de l'VPCendroit où le nœud est créé sont définies pour domain-name et domain-name-servers comme Options dans unDHCP options set. Les valeurs par défaut sont domain-name:<region>.compute.internal et domain-name-servers:AmazonProvidedDNS. Pour plus d'informations, consultez les ensembles DHCP d'options dans le guide de VPC l'utilisateur Amazon.

  • 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 surCreate failed. Dans Windows AMIsdont les temps de lancement sont lents, ce problème peut être résolu à l'aide d'un 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 le manuel AWSSupport-TroubleshootEKSWorkerNode 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 de kubectl commandes, cela signifie que vous n'avez pas kubectl configuré correctement pour Amazon EKS ou que les informations d'identification du IAM principal (rôle ou utilisateur) que vous utilisez ne correspondent pas à Kubernetes nom d'utilisateur disposant des autorisations suffisantes pour Kubernetes objets de votre EKS cluster Amazon.

  • 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 IAM principal et kubectl est configuré pour utiliser les informations d'identification d'un autre IAM principal. 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 Connect kubectl à un EKS cluster en créant un fichier kubeconfig.

  • Si votre cluster répond aux exigences minimales de plate-forme indiquées dans la section Conditions préalables de la section Octroi IAM accès des utilisateurs à Kubernetes avec entrées EKS d'accès Accorder aux IAM utilisateurs l'accès à Kubernetes avec des entrées EKS d'accès, aucune entrée d'accès n'existe auprès de votre principal. IAM S'il existe, il n'a pas le nécessaire Kubernetes noms de groupe définis pour celui-ci, ou auquel la politique d'accès appropriée n'est pas associée. Pour de plus amples informations, veuillez consulter Octroi IAM accès des utilisateurs à Kubernetes avec entrées EKS d'accès.

  • Si votre cluster ne répond pas à la configuration minimale requise dans la section Octroi IAM accès des utilisateurs à Kubernetes avec entrées EKS d'accès Accorder aux IAM utilisateurs l'accès à Kubernetes avec des entrées d'EKSaccès, aucune entrée avec votre IAM principal n'existe dans le. aws-auth ConfigMap S'il existe, il n'est pas mappé à Kubernetes noms de groupes liés à un Kubernetes Roleou ClusterRole avec les autorisations nécessaires. Pour plus d'informations sur Kubernetes objets d'autorisation basés sur les rôles (RBAC), voir Utilisation de l'RBACautorisation dans Kubernetes . Vous pouvez consulter vos aws-auth ConfigMap entrées actuelles en remplaçant my-cluster dans la commande suivante avec le nom de votre cluster, puis exécutez la commande modifiée : eksctl get iamidentitymapping --cluster my-cluster. If an entry for with the ARN of your IAM principal isn’t in the ConfigMap, enter eksctl create iamidentitymapping --help in your terminal to learn how to create one.

Si vous installez et configurez le AWS CLI, vous pouvez configurer les IAM informations d'identification que vous utilisez. Pour plus d'informations, consultez le guide de l'utilisateur AWS CLI de l'interface de ligne de AWS commande sur la configuration. Vous pouvez également configurer kubectl pour utiliser un IAM rôle, si vous assumez un IAM rôle pour accéder Kubernetes objets de votre cluster. Pour de plus amples informations, veuillez consulter Connect kubectl à un EKS cluster en créant un fichier kubeconfig.

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 AWS CLI des appels vers AmazonEKS. Pour plus d'informations, voir Quelles sont les erreurs « le nom d'hôte ne correspond pas » ? dans les questions fréquemment posées sur les requêtes Python.

getsockopt: no route to host

Docker fonctionne dans la 172.17.0.0/16 CIDR gamme des EKS clusters Amazon. Nous recommandons que les VPC sous-réseaux 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 CIDR blocs pour l'accès au point de terminaison public. Pour de plus amples informations, veuillez consulter Contrôlez l'accès réseau au point de terminaison API du serveur du cluster.

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 de santé matérielle, Amazon EKS renvoie un code d'erreur pour vous aider à diagnostiquer le problème. Ces bilans de santé ne détectent pas les problèmes logiciels car ils sont basés sur les bilans de EC2 santé d'Amazon. La liste suivante décrit les codes d'erreur.

AccessDenied

Amazon EKS ou un ou plusieurs de vos nœuds gérés ne parvient pas à s'authentifier ou à autoriser auprès de votre Kubernetes APIserveur de cluster. 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. Privé Windows AMIspeut é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.

AmiIdNotFound

Nous n'avons pas trouvé l'AMIidentifiant associé à votre modèle de lancement. Assurez-vous qu'il AMI existe et qu'il est partagé 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 sont pas en mesure de communiquer avec votre Kubernetes APIserveur de cluster. Cela peut se produire en cas de perturbations du réseau ou si les API serveurs tardent à traiter les demandes.

Eco 2 SecurityGroupNotFound

Nous n'avons pas pu trouver le groupe de sécurité du 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 trouvé le modèle de EC2 lancement Amazon pour votre groupe de nœuds géré. Vous devez recréer votre groupe de nœuds pour effectuer une récupération.

Eco 2 LaunchTemplateVersionMismatch

La version du modèle de EC2 lancement Amazon pour votre groupe de nœuds gérés ne correspond pas à la version EKS créée par Amazon. Vous pourrez peut-être revenir à la version EKS créée par Amazon pour la récupérer.

IamInstanceProfileNotFound

Nous n'avons pas trouvé le profil d'IAMinstance pour votre groupe de nœuds géré. 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 IAM rôle de votre groupe de nœuds gérés. Vous pouvez peut-être recréer un IAM rôle avec les mêmes paramètres pour le récupérer.

AsgInstanceLaunchFailures

Votre groupe Auto Scaling rencontre des problèmes lors d'une tentative de lancement d'instances.

NodeCreationFailure

Les instances que vous avez lancées ne peuvent pas s'enregistrer auprès de votre EKS cluster Amazon. Les causes courantes de cet échec sont l'insuffisance des autorisations de IAM rôle des IAMRôle EKS du nœud Amazon nœuds ou le manque d'accès Internet sortant pour les nœuds. Vos nœuds doivent répondre à l'une des exigences suivantes :

InstanceLimitExceeded

Votre AWS compte n'est plus en mesure de lancer d'autres instances du type d'instance spécifié. Vous pouvez peut-être demander une augmentation de la limite d'EC2instance Amazon pour récupérer.

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 disponibles pour les nouveaux nœuds.

InternalFailure

Ces erreurs sont généralement causées par un problème EKS côté serveur Amazon.

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'intégration aux groupes de nœuds gérés, et elles sont nécessaires à la gestion des 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é un élément manquant, défectueux ClusterRole ou à ClusterRoleBinding l'origine d'une AcessDenied erreur lors de la demande d'opérations de groupe de nœuds gérés, vous pouvez le 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 Not authorized for images d'erreur est l'utilisation d'un Amazon privé EKS Windows AMIpour lancer Windows groupes de nœuds gérés. Après avoir publié de nouvelles Windows AMIs, AMIs les AWS rend privés depuis plus de 4 mois, ce qui les rend inaccessibles. Si votre groupe de nœuds gérés utilise un nœud privé Windows AMI, pensez Mettre à jour un groupe de nœuds gérés pour votre cluster à mettre à jour votre groupe de nœuds gérés par Windows. 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 la section Patches du guide de EC2 l'utilisateur Amazon.

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 planifier un nouveau Pods. Cela peut se produire pour diverses raisons, telles que le fait que le nœud ne dispose pas de suffisamment de CPU ressources, de mémoire ou d'espace disque disponible.

EKSOptimisé pour Amazon Windows 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 fournissant des valeurs de kubelet configuration pour Kube Reserved et/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 Réserver des ressources de calcul pour les démons du système dans le Kubernetes dans la documentation et Paramètres de configuration du script d'amorçage dans ce guide de l'utilisateur.

CNIoutil de collecte de journaux

Le Amazon VPC CNI plugin for Kubernetes possède son propre script de dépannage qui est disponible sur les nœuds à l'adresse/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 à cet emplacement, le CNI conteneur 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 CNI version 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 :

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

    Pour résoudre le problème, consultez les entrées existantes dans votre ConfigMap my-cluster dans la commande suivante avec le nom de votre cluster, puis exécutez la commande modifiée : eksctl get iamidentitymapping --cluster my-cluster. If you receive an error message from the command, it might be because your cluster doesn’t have an aws-auth ConfigMap. The following command adds an entry to the ConfigMap. If the ConfigMap doesn’t exist, the command also creates it. Replace 111122223333 with the AWS account ID for the IAM role and myAmazonEKSNodeRole with the name of your node’s role.

    eksctl create iamidentitymapping --cluster my-cluster \ --arn arn:aws: iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \ --username system:node:{{EC2PrivateDNSName}}

    Le ARN rôle que vous spécifiez ne peut pas inclure de chemin autre que/. Par exemple, si le nom de votre rôle estdevelopment/apps/my-role, vous devrez le remplacer my-role lorsque vous spécifiez le ARN rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    chemin autre que/. Par exemple, si le nom de votre rôle estdevelopment/apps/my-role, vous devrez le remplacer my-role lorsque vous spécifiez le ARN rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    autre que/. Par exemple, si le nom de votre rôle estdevelopment/apps/my-role, vous devrez le remplacer my-role lorsque vous spécifiez le ARN rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    /. Par exemple, si le nom de votre rôle estdevelopment/apps/my-role, vous devrez le remplacer my-role lorsque vous spécifiez le ARN rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    . Par exemple, si le nom de votre rôle estdevelopment/apps/my-role, vous devrez le remplacer my-role lorsque vous spécifiez le ARN rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    development/apps/my-role, vous devez le remplacer par my-role lorsque vous spécifiez ARN le rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    , vous devez le remplacer par my-role lorsque vous spécifiez ARN le rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    my-rolelors ARN de la spécification du rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

    lors ARN de la spécification du rôle. Assurez-vous de spécifier le IAM rôle du nœud ARN (et non le profil d'instanceARN).

  2. Vos nœuds autogérés font partie d'un cluster dont la version de plateforme correspond à la version minimale répertoriée dans les conditions requises dans la rubrique Octroi IAM accès des utilisateurs à Kubernetes avec entrées EKS d'accès Accorder aux IAM utilisateurs l'accès à Kubernetes avec des entrées d'EKSaccès, mais aucune entrée n'est répertoriée dans le aws-auth ConfigMap (voir point précédent) pour le IAM rôle 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 en remplaçant my-cluster dans la commande suivante avec le nom de votre cluster, puis exécutez la commande modifiée : aws eks list-access-entries --cluster-name my-cluster. The following command adds an access entry for the node’s IAM role. Replace 111122223333 with the AWS account ID for the IAM role and myAmazonEKSNodeRole with the name of your node’s role. If you have a Windows node, replace EC2_Linux with EC2_Windows. Make sure that you specify the node IAM role ARN (not the instance profile ARN).

    aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/myAmazonEKSNodeRole --type EC2_Linux

TLSdélai d'expiration de la poignée de mains

Lorsqu'un nœud ne parvient pas à établir une connexion avec le point de terminaison API du serveur public, une erreur similaire à l'erreur suivante peut s'afficher.

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 kubelet processus réapparaîtra continuellement et testera le point de terminaison du API serveur. 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 IAM des rôles pour les comptes de service d'un Pod or DaemonSet déployé sur un cluster dans une AWS région de Chine, et vous n'avez pas défini la variable d'AWS_DEFAULT_REGIONenvironnement dans la spécification, Pod or DaemonSet le message d'erreur suivant peut s'afficher :

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_REGIONenvironnement à votre Pod or DaemonSet spécification, comme indiqué dans l'exemple suivant Pod spécification.

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 Kubernetes version avant mise à niveau du plan de contrôle

Avant de passer d'un plan de contrôle à un nouveau Kubernetes version, 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. Amazon EKS update-cluster-version API rejette les demandes jusqu'à ce que vous mettiez à niveau tous les nœuds EKS gérés par Amazon vers la version actuelle du cluster. Amazon EKS propose APIs de mettre à niveau les nœuds gérés. Pour plus d'informations sur la mise à niveau d'un groupe de nœuds gérés Kubernetes version, voirMettre à jour un groupe de nœuds gérés pour votre cluster. Pour mettre à niveau la version d'un nœud Fargate, supprimez le pod qui est représenté par le nœud et redéployez le pod après avoir amélioré votre plan de contrôle. Pour de plus amples informations, veuillez consulter Mettre à jour le cluster existant vers la nouvelle version de Kubernetes.

Lors du lancement de nombreux nœuds, des erreurs Too Many Requests se produisent

Si vous lancez plusieurs nœuds simultanément, un message d'erreur peut s'afficher dans les journaux d'exécution des données EC2 utilisateur d'Amazon indiquant Too Many Requests que 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 --dns-cluster-ip arguments --apiserver-endpoint--b64-cluster-ca, et sont transmis au script bootstrap du nœud. Lorsque vous incluez ces arguments, le script bootstrap n'a pas besoin d'effectuer un describeCluster appel, ce qui permet d'éviter une 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 un fichier EKS optimisé pour Amazon Linux/Bottlerocket AMI.

HTTPRéponse d'erreur 401 non autorisée sur Kubernetes APIrequêtes du serveur

Ces erreurs s'affichent si un Pod’s le jeton de compte de service a expiré sur un cluster.

Celui de votre EKS cluster Amazon Kubernetes APIle serveur rejette les demandes contenant des jetons datant de plus de 90 jours. Dans le précédent Kubernetes versions, les jetons n'avaient pas d'expiration. Cela signifie que les clients qui s'appuient sur ces jetons doivent les actualiser dans l'heure. Pour éviter que Kubernetes APIsi le serveur ne rejette pas votre demande en raison d'un jeton non valide, la SDK version du 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 versions ultérieures

Vous pouvez identifier tous ceux qui existent Pods dans votre cluster qui utilisent des jetons périmés. Pour de plus amples informations, veuillez consulter Jetons de compte de service.

EKSLa version de la plateforme Amazon a plus de deux versions de retard par rapport à 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 Afficher les versions de EKS la plateforme Amazon pour chaque version de Kubernetes 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, mais la version de sa plateforme ne sera tout simplement pas mise à jour par AmazonEKS.

Problème

Le IAM rôle du IAMRôle EKS du cluster Amazon 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 avec 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éez un nouveau IAM rôle de IAMRôle EKS du cluster Amazon 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 avec 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 mette EKS à 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 sélectionne de EKS manière aléatoire les sous-réseaux que vous avez spécifiés pour créer de nouvelles interfaces réseau élastiques. 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 sélectionné 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 Kubernetes mise à jour de la version de 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'IDsaide de la commande suivante. Remplacez my-cluster avec 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 elle [] est renvoyée, aucun groupe de sécurité n'a été spécifié lors de la création du cluster et aucun groupe de sécurité manquant n'est à l'origine du 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 mettra 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 Kubernetes mise à jour de la version de votre cluster, la mise à jour peut échouer pour la même raison.

  • Vous n'avez pas au moins six (mais nous recommandons 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 suffisamment 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 avec suffisamment d'adresses IP disponibles.

  • Vous avez activé le chiffrement des Chiffrez les secrets de Kubernetes sur des clusters existants AWS KMS 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 mette EKS à jour le cluster, vous devez en créer un nouveau

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 EKS clusters et à l'infrastructure du cluster et les enregistre dans l'état de santé 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 se peut qu'il vous soit impossible de passer à des versions plus récentes de Kubernetes ou pour EKS qu'Amazon installe des mises à jour de sécurité sur un cluster dégradé en raison de problèmes liés à l'infrastructure ou à la configuration du cluster nécessaires. 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 EKS cluster Amazon est une responsabilité partagée entre Amazon EKS et ses utilisateurs. Vous êtes responsable de l'infrastructure préalable des IAM rôles et des VPC sous-réseaux Amazon, 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 EKS console Amazon, consultez la section intitulée Health Issues dans l'onglet Overview de la page détaillée du EKS cluster Amazon. Ces données seront également disponibles en appelant l'DescribeClusteraction dans le EKSAPI, 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 EKS cluster Amazon, 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 EKS cluster Amazon, Amazon EKS ne sera pas en mesure de créer des interfaces réseau entre comptes et Kubernetes AWS CLIdes commandes telles que kubectl exec ou kubectl logs. Ils échoueront avec l'erreur : Vous verrez Error from server: error dialing backend: remote error: tls: internal error. maintenant un problème de EKS santé Amazon qui dit :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 ?

IAMles rôles et les VPC sous-réseaux Amazon sont deux exemples d'infrastructures prérequises avec lesquelles 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 de santé est-il payant ?

Oui, chaque EKS cluster Amazon est facturé au EKS tarif standard d'Amazon. La fonctionnalité liée à l'état du cluster est disponible sans frais supplémentaires.

Cette fonctionnalité fonctionne-t-elle avec les EKS clusters Amazon sur AWS Outposts ?

Oui, des problèmes de cluster sont détectés pour les EKS clusters 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 liés à 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 en cas de problème de santé ?

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 API réponse. Le troisième champ de l' ClusterIssueobjet Health est resourceIds, 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 Amazon EKS update-cluster-config APIpour 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 Amazon EKS update-cluster-config API 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 disponibles pour qu'Amazon puisse EKS effectuer des opérations de gestion du cluster. Libérez des adresses dans le ou les sous-réseaux ou associez différents sous-réseaux à votre cluster à l'aide d'Amazon. EKS update-cluster-config API

ID de sous-réseaux

Oui

VPC_NOT_FOUND

Nous n'avons pas trouvé le VPC fichier associé à votre cluster. Vous devez supprimer et recréer votre cluster.

VPCidentifiant

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 EKS de gestion Amazon requises. Vérifiez que le rôle existe et qu'il dispose de la politique de confiance requise.

Le IAM rôle 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 EKS à Amazon 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.

Le IAM rôle du cluster

Oui

ASSUME_ROLE_ACCESS_DENIED_USING_SLR

Nous ne pouvions pas assumer la gestion du EKS cluster Amazon 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 EKS cluster Amazon service-linked-role n'accorde pas d'autorisations suffisantes EKS à Amazon 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

Aucun abonnement au EC2 service Amazon n'est associé à votre compte. Mettez à jour les abonnements de votre compte sur la page des paramètres de votre compte.

N/A

Oui

STS_REGIONAL_ENDPOINT_DISABLED

Le STS le point de terminaison régional est désactivé. Activez le point de terminaison pour EKS qu'Amazon 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.

Le 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.

Le 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.

Le KMS Key Arn

Non