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

Ce chapitre traite de certaines erreurs courantes que vous pouvez rencontrer lorsque vous utilisez Amazon EKS, ainsi que des solutions. Si vous avez besoin de dépanner des zones spécifiques d'Amazon EKS, consultez les rubriques Dépannage IAM, Résoudre les problèmes liés au connecteur Amazon EKS et Dépannage d'ADOT à l'aide de modules complémentaires EKS.

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 cluster Amazon EKS, cela signifie que l'une des zones de disponibilité que vous avez spécifiées ne dispose pas d'une capacité suffisante pour prendre en charge un cluster.

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

Essayez à nouveau de créer votre cluster avec des sous-réseaux de votre VPC de cluster hébergés dans les zones de disponibilité renvoyés par ce message d'erreur.

Il existe des zones de disponibilité dans lesquelles un cluster ne peut pas résider. 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 sous-réseaux.

Les nœuds ne parviennent pas à joindre le cluster

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

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 correctement kubectl configuré Amazon EKS ou que les informations d'identification du principal IAM (rôle ou utilisateur) que vous utilisez ne sont pas mappées à un Kubernetes nom d'utilisateur disposant des autorisations suffisantes pour Kubernetes objets de votre cluster Amazon EKS.

Cela peut être dû à l'une des raisons suivantes :

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

hostname doesn’t match

La version Python de votre système doit être 2.7.9 ou ultérieure. Dans le cas contraire, vous recevrez hostname doesn’t match des erreurs lors des appels AWS CLI vers Amazon EKS. Pour plus d'informations, 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 s'exécute dans la plage 172.17.0.0/16 CIDR dans les clusters Amazon EKS. Nous recommandons 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 de plus amples informations, veuillez consulter Contrôlez l'accès réseau au point de terminaison du serveur API 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 d'intégrité 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.

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

kubectl describe clusterrole eks:node-manager

kubectl describe clusterrolebinding eks:node-manager

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

kubectl apply -f eks-node-manager-role.yaml

Not authorized for images

L'une des causes potentielles d'un message Not authorized for images d'erreur est l'utilisation d'un Amazon EKS privé Windows Lancement de l'AMI 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 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 ressources suffisantes pour le processeur, la mémoire ou l'espace disque disponible.

Optimisé pour Amazon EKS 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.

Outil de collecte de journaux CNI

Le Amazon VPC CNI plugin for Kubernetes possède son propre script de résolution des problèmes 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

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 :

Délai d'expiration de la liaison TLS

Lorsqu'un nœud est incapable d'établir une connexion avec le point de terminaison du serveur d'API public, vous pouvez voir une erreur similaire à l'erreur suivante.

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post  net/http: TLS handshake timeout\""

Le processus kubelet se reproduira continuellement et testera le point de terminaison du serveur d'API. L'erreur peut également se produire temporairement au cours de toute procédure qui effectue une mise à jour continue du cluster dans le plan de contrôle, telle qu'une modification de configuration ou une mise à jour de version.

Pour résoudre le problème, vérifiez la table de routage et les groupes de sécurité pour vous assurer que le trafic provenant des nœuds peut atteindre le point de terminaison public.

InvalidClientTokenId

Si vous utilisez des rôles IAM pour les comptes de service d'un Pod 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. L'API update-cluster-version Amazon EKS rejette les demandes tant que vous n'avez pas mis à niveau tous les nœuds gérés par Amazon EKS vers la version actuelle du cluster. Amazon EKS permet APIs de mettre à niveau les nœuds gérés. Pour plus d'informations sur la mise à niveau 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 Amazon EKS optimisé Linux/Bottlerocket AMI.

Réponse d'erreur HTTP 401 non autorisée sur Kubernetes Demandes du serveur d'API

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

Votre cluster Amazon EKS Kubernetes Le serveur API 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 Si le serveur API ne rejette pas 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 :

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.

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, mais la version de sa 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 le sous-réseau IDs existe dans votre compte.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"

L'exemple qui suit illustre un résultat.

[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]

Si le sous-réseau IDs renvoyé dans la sortie ne correspond pas au sous-réseau spécifié lors de la création du cluster, si vous souhaitez IDs qu'Amazon EKS mette à jour le cluster, vous devez modifier les sous-réseaux utilisés par le cluster. En effet, si vous avez spécifié plus de deux sous-réseaux lors de la création de votre cluster, Amazon EKS sélectionne de manière aléatoire les sous-réseaux que vous avez spécifiés pour y créer de nouvelles interfaces réseau Elastic. Ces interfaces réseau permettent au plan de contrôle de communiquer avec vos nœuds. Amazon EKS ne mettra pas à jour le cluster si le sous-réseau 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' IDs aide de la commande suivante. Remplacez my-cluster par le nom de votre cluster.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds

L'exemple qui suit illustre un résultat.

[
    "sg-EXAMPLE1"
]

Si 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 met pas à jour un cluster si le groupe de sécurité IDs spécifié lors de la création du cluster n'existe pas.

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

Codes d'erreur FAQs et d'intégrité du cluster avec chemins de résolution

Amazon EKS détecte les problèmes liés à vos clusters EKS et à l'infrastructure du cluster 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 se peut qu'il vous soit impossible de passer à des versions plus récentes de Kubernetes ou pour qu'Amazon EKS 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 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 seront également disponibles en appelant l'DescribeClusteraction dans l'API EKS, par exemple depuis l'interface de ligne de AWS commande.

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 est resourceIds, dont le retour dépend du type de problème.