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 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 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 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 :

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

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

Si vous installez et configurez le AWS CLI, vous pouvez configurer les IAM informations d'identification 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 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 Connexion kubectl à un EKS cluster en créant un kubeconfig dans le fichier.

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

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 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 votre Windows groupe de nœuds géré. 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 Correctifs, mises à jour de sécurité et AMI IDs le 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 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 Réserver des ressources de calcul pour les démons du système dans le Kubernetes documentation et paramètres de configuration du script Bootstrap dans ce guide de l'utilisateur.

CNIoutil de collecte de journaux

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 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 :

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 ou DaemonSet déployé sur un cluster en Chine Région AWS, et 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'AWS_DEFAULT_REGIONenvironnement à votre Pod ou DaemonSet spec, 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 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 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 de plus amples informations, veuillez consulter Fournissez des données utilisateur pour transmettre des arguments au bootstrap.sh fichier inclus dans unLinux/EKSoptimisé pour Amazon Bottlerocket AMI.

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

Ces erreurs s'affichent si un Podle 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 APIle serveur ne rejettera pas votre demande en raison d'un jeton non valide, Kubernetes SDKla version du client 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 plus d’informations, consultez .Kubernetes comptes 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 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 IAMrôle 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 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 IAMrôle de 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 [] 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 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.

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 le AWS Command Line Interface.

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.