Dépannage Amazon EKS - 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.

Dépannage Amazon EKS

Ce chapitre traite de certaines erreurs courantes que vous pouvez rencontrer lorsque vous utilisez Amazon EKS, ainsi que des solutions.

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.

Les nœuds n'arrivent pas à joindre le cluster

Quelques raisons courantes empêchent les nœuds de joindre le cluster :

  • Leaws-auth-cm.yamlLe fichier n'a pas le bon ARN pour Rôle IAM pour vos nœuds. Assurez-vous que l'ARN du rôle IAM du nœud (et non l'ARN du profil d'instance) est spécifié dans la commandeaws-auth-cm.yamldans le fichier. Pour de plus amples informations, veuillez consulter Lancement de nœuds Amazon Linux autogérés.

  • LeClusterNamedans votre nœudAWS CloudFormationne correspond pas exactement au nom du cluster que vos nœuds doivent joindre. Une valeur incorrecte pour ce champ génère une configuration incorrecte de la propriété/var/lib/kubelet/kubeconfig, et les nœuds ne rejoindront pas le cluster.

  • Le nœud n'est pas balisé comme étant.Appartientpar le cluster. La balise suivante doit être appliquée à vos nœuds, où<cluster-name>est remplacé par le nom de votre cluster.

    Key Valeur

    kubernetes.io/cluster/<cluster-name>

    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 non, vous pouvez associer une adresse IP Elastic à un nœud après son lancement. Pour de plus amples informations, veuillez consulterAssociation d'une adresse IP Elastic à 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 point de terminaison STS pour la région dans laquelle vous déployez les nœuds n'est pas activé pour votre compte. Pour activer la région, reportez-vous à la section Activation et désactivation d'AWS STS dans une région AWS.

  • Le nœud de travail n'a pas d'entrée DNS privée, ce qui entraîne la propriétékubeletjournal contenant unnode "" not foundErreur. Assurez-vous que le VPC sur lequel le nœud de travail est créé a des valeurs définies pourdomain-nameanddomain-name-serverscommeOptionsdans unDHCP options set. Les valeurs par défaut sont.domain-name:<region>.compute.internalanddomain-name-servers:AmazonProvidedDNS. Pour plus d'informations, consultez Jeux d'options DHCP dans le Amazon VPC Guide de l'utilisateur.

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

Si vous recevez un message pour l'une des erreurs suivantes lors de l'exécutionkubectl, puis votrekubectlN'est pas correctement configurée pour Amazon EKS ou les informations d'identification de l'utilisateur IAM ou du rôle que vous utilisez ne sont pas mappées à un utilisateur RBAC Kubernetes avec des autorisations suffisantes 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û au fait que le cluster a été créé avec un ensemble deAWSInformations d'identification (à partir d'un rôle ou d'un utilisateur IAM) etkubectlutilise un ensemble différent d'informations d'identification.

Lorsqu'un cluster Amazon EKS est créé, l'entité IAM (utilisateur ou rôle) qui crée le cluster est ajoutée à la table d'autorisation RBAC Kubernetes en tant qu'administrateur (avecsystem:mastersAutorisations). Initialement, seul cet utilisateur IAM peut effectuer des appels vers le serveur d'API Kubernetes à l'aide dekubectl. Pour de plus amples informations, veuillez consulter Gestion des utilisateurs ou des rôles IAM pour votre cluster. Si vous utilisez la console pour créer le cluster, vous devez vous assurer que les mêmes informations d'identification IAM sont dans la boîte de dialogueAWSChaîne d'informations d'identification SDK lorsque vous exécutezkubectlsur votre cluster.

Si vous installez et configurez leAWS CLI, vous pouvez configurer les informations d'identification IAM pour votre utilisateur. Pour plus d'informations, consultez Configuration de l'AWS CLI dans le Guide de l'utilisateur de l'AWS Command Line Interface.

Si vous avez assumé un rôle pour créer le cluster Amazon EKS, vous devez vous assurer quekubectlest configuré pour assumer le même rôle. Utilisez la commande suivante pour mettre à jour vos donnéeskubeconfigpour utiliser un rôle IAM. Pour de plus amples informations, veuillez consulter Création d'unkubeconfigpour Amazon EKS.

aws eks update-kubeconfig \ --region <region-code> \ --name <cluster_name> \ --role-arn arn:aws:iam::<aws_account_id>:role/<role_name>

Pour mapper un utilisateur IAM à un utilisateur RBAC Kubernetes, consultezGestion des utilisateurs ou des rôles IAM pour votre cluster.

aws-iam-authenticator introuvable

Si vous recevez l'erreur"aws-iam-authenticator": executable file not found in $PATH, puis votrekubectln'est pas configuré pour Amazon EKS. Pour de plus amples informations, veuillez consulter Installation d'aws-iam-authenticator.

Note

Leaws-iam-authenticatorn'est pas obligatoire si vous avez leAWS CLIversion 1.16.156 ou supérieure installée.

hostname doesn't match

La version Python de votre système doit être la version 2.7.9 ou une version ultérieure. Sinon, vous recevezhostname doesn't matchErreurs avecAWS CLIappels vers Amazon EKS. Pour de plus amples informations, veuillez consulter Que sont les erreurs « hostname doesn't match » ? dans le Forum Aux Questions (FAQ) relatif aux demandes Python.

getsockopt: no route to host

Docker s'exécute dans le172.17.0.0/16Gamme CIDR 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

Erreurs liées aux groupes de nœuds gérés

Si vous recevez l'erreur « 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 Contrôle d'accès au point de terminaison de cluster Amazon EKS.

Si votre groupe de nœuds gérés rencontre un problème d'intégrité, Amazon EKS renvoie un message d'erreur pour vous aider à diagnostiquer le problème. Les messages d'erreur suivants et leurs descriptions associées sont affichés ci-dessous.

  • AccessDenied : Amazon EKS ou un ou plusieurs de vos nœuds gérés ne peuvent pas s'authentifier ou autoriser auprès de votre serveur d'API de votre cluster Kubernetes. Pour plus d'informations sur la résolution de cette erreur, consultezFixationAccessDeniedErreurs pour les groupes de nœuds gérés.

  • AmiidNotFound : Nous n'avons pas trouvé l'ID AMI associé à votre modèle de lancement. Assurez-vous que l'AMI existe et qu'elle 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.

  • ClusterUnjoignable : 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 API sont en retard de traitement des demandes.

  • EC2SecurityGroupNotFound : Nous n'avons pas pu trouver le groupe de sécurité de cluster pour le cluster. Vous devez recréer votre cluster.

  • EC2SecurityGroupDeletionFailure : 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é.

  • EC2LaunchTemplatenotFound : 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 récupérer.

  • EC2LaunchTemplateVersionMismatch : 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 créée par Amazon EKS pour effectuer une récupération.

  • IAMInstanceProfileNotFound : Nous n'avons pas pu trouver 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 insuffisantesRôle IAM de nœudou l'absence d'un accès Internet sortant pour les nœuds. Pour fonctionner correctement, vos nœuds doivent pouvoir accéder à Internet à l'aide d'une adresse IP publique. Pour de plus amples informations, veuillez consulter Adressage IP VPC. Vos nœuds doivent également avoir des ports ouverts à Internet. Pour de plus amples informations, veuillez consulter Considérations relatives aux groupes de sécurité Amazon EKS.

  • InstanceLimitExceeded : VotreAWSImpossible 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 de suffisamment d'adresses IP pour de nouveaux nœuds.

  • InternalFailure : Ces erreurs sont généralement dues à un problème lié serveur Amazon EKS.

La cause la plus courante deAccessDeniedlors de l'exécution d'opérations sur des groupes de nœuds gérés manque la propriétéeks:node-manager ClusterRoleouClusterRoleBinding. Amazon EKS configure ces ressources dans votre cluster dans le cadre de l'intégration avec les groupes de nœuds gérés, et celles-ci sont nécessaires pour gérer les groupes de nœuds.

LeClusterRolepeut changer avec le temps, mais cela doit être similaire à 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

LeClusterRoleBindingpeut changer avec le temps, mais cela doit être similaire à 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 leeks:node-manager ClusterRoleexiste.

kubectl describe clusterrole eks:node-manager

Si elle est présente, comparez la sortie à la précédenteClusterRoleExemple d' d'

Vérifiez que leeks:node-manager ClusterRoleBindingexiste.

kubectl describe clusterrolebinding eks:node-manager

Si elle est présente, comparez la sortie à la précédenteClusterRoleBindingExemple d' d'

Si vous avez identifié un manquant ou casséClusterRoleouClusterRoleBindingcomme la cause d'unAcessDeniedlors 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.

Outil de collecte de journaux CNI

Le plugin Amazon VPC CNI pour Kubernetes a son propre script de dépannage disponible sur les nœuds sur/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 erreurs sont très probablement liées à laAWSLe mappage de configuration IAM Authenticator n'est pas appliqué aux nœuds. La carte de configuration fournit lesystem:bootstrappersandsystem:nodesAutorisations RBAC Kubernetes pour que les nœuds s'inscrivent dans le cluster. Pour de plus amples informations, veuillez consulterPour autoriser les nœuds à joindre votre clustersur leNods autogérésonglet deLancement de nœuds Amazon Linux autogérés. Assurez-vous que vous spécifiez l'ARN de rôle du rôle d'instance dans le mappage de configuration, et non l'ARN de profil d'instance.

L'authentificateur ne reconnaît pas un ARN de rôle s'il inclut un chemin d'accès autre que /, comme dans l’exemple suivant :

arn:aws:iam::<111122223333>:role/<development/apps/prod-iam-role-NodeInstanceRole-621LVEXAMPLE>

Lorsque vous spécifiez dans le mappage de configuration un ARN de rôle qui inclut un chemin d'accès autre que /, vous devez supprimer le chemin d'accès. L'ARN ci-dessus serait spécifié comme suit :

arn:aws:iam::<111122223333>:role/<prod-iam-role-NodeInstanceRole-621LVEXAMPLE>

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, une erreur similaire à l'erreur suivante peut se produire.

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 pour un pod ou un démon déployé sur un cluster dans une région Chine, et que vous n'avez pas défini la propriétéAWS_DEFAULT_REGIONDans la spécification, le module ou le démon peut recevoir l'erreur suivante :

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 module ou à votre spécification de processus, comme indiqué dans l'exemple suivant de spécification de module.

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 Windows reste àContainerCreating. Si cela s'affiche, affichez les informations sur le conteneur dans cet état à l'aide de la commande suivante.

kubectl describe pod my-pod -n my-namespace

Vous voyez l'événement suivant dans la sortie renvoyée.

Warning FailedCreatePodSandBox 39s kubelet

Vous pouvez vérifier la date d'expiration de votre certificat à l'aide de la commande suivante.

kubectl get secret \ -n kube-system \ vpc-admission-webhook-certs -o json | \ jq -r '.data."cert.pem"' | \ base64 --decode | \ openssl x509 \ -noout \ -enddate | \ cut -d= -f2

Sortie

May 27 14:23:00 2021 GMT

Si votre certificat a expiré, vous devez le renouveler. Pour de plus amples informations, veuillez consulter Renouvellement du certificat webhook d'admission VPC. Une fois que vous avez déployé le nouveau certificat, vous devez redéployer chaque conteneur bloqué avec unContainerCreatingÉtat.