Comment résoudre les échecs de création de groupes de nœuds gérés par Amazon EKS ?

Dernière mise à jour : 03/06/2022

La création de mon groupe de nœuds gérés par Amazon Elastic Kubernetes Service (Amazon EKS) a échoué. Les nœuds ne peuvent pas rejoindre le cluster et j'ai reçu une erreur similaire à la suivante :

« Instances failed to join the kubernetes cluster » (Les instances n'ont pas réussi à rejoindre le cluster kubernetes).

Brève description

Pour résoudre les échecs de création de groupes de nœuds gérés par Amazon EKS, procédez comme suit :

  • Utilisez le runbook AWS Systems Manager Automation pour identifier les problèmes courants.
  • Vérifiez les exigences de trafic du groupe de sécurité du composant master.
  • Vérifiez les autorisations IAM (Identity and Access Management) du composant master.
  • Vérifiez que l'Amazon Virtual Private Cloud (Amazon VPC) de votre cluster prend en charge un nom d'hôte et une résolution DNS.
  • Mettez à jour le ConfigMap aws-auth avec le rôle NodeInstanceRole associé de vos composants master.
  • Définissez les identifications de vos composants master.
  • Vérifiez que les sous-réseaux Amazon VPC pour le composant master ont des adresses IP disponibles.
  • Vérifiez que les composants master peuvent atteindre le point de terminaison du serveur d'API de votre cluster.
  • Vérifiez que les points de terminaison d'API Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR) et Amazon Simple Storage Service (Amazon S3) peuvent atteindre votre région AWS.

Solution

Remarque : si vous recevez des erreurs lors de l'exécution de commandes de l'interface de la ligne de commande AWS (AWS CLI), assurez-vous que vous utilisez la version la plus récente d'AWS CLI.

Utiliser le runbook Systems Manager Automation pour identifier les problèmes courants

Utilisez le runbook AWSSupport-TroubleshootEKSWorkerNode pour trouver les problèmes courants qui empêchent les composants master de rejoindre votre cluster.

Important : pour que l'automatisation fonctionne, vos composants master doivent avoir l'autorisation d'accéder à Systems Manager et avoir Systems Manager en cours d'exécution. Pour accorder l'autorisation, attachez la politique gérée par AWS AmazonSSMManagedInstanceCore au rôle IAM qui correspond à votre profil d'instance EC2. Il s'agit de la configuration par défaut pour les groupes de nœuds gérés par EKS qui sont créés via eksctl.

  1. Ouvrez le runbook.
  2. Vérifiez que la région AWS dans la console de gestion AWS est définie sur la même région que votre cluster.
    Remarque : consultez la section Document details (Détails du document) du runbook pour plus d'informations sur le runbook.
  3. Dans la section Input parameters (Paramètres d'entrée), spécifiez le nom de votre cluster dans le champ ClusterName et l'ID de l'instance dans le champ WorkerID.
  4. (Facultatif) Dans le champ AutomationAssumeRole, spécifiez le rôle IAM permettant à Systems Manager d'effectuer des actions. S'il n'est pas spécifié, les autorisations IAM de votre entité IAM actuelle sont utilisées pour exécuter les actions du runbook.
  5. Choisissez Execute (Exécuter).
  6. Consultez la section Outputs (Sorties) pour savoir pourquoi votre composant master ne rejoint pas votre cluster et les étapes que vous pouvez suivre pour résoudre ce problème.

Vérifier les exigences de trafic du groupe de sécurité du composant master

Vérifiez que le groupe de sécurité de votre plan de contrôle et le groupe de sécurité du composant master sont configurés avec les paramètres recommandés pour le trafic entrant et sortant. Par défaut, Amazon EKS applique le groupe de sécurité du cluster aux instances de votre groupe de nœuds pour faciliter la communication entre les nœuds et le plan de contrôle. Si vous spécifiez des groupes de sécurité personnalisés dans le modèle de lancement pour votre groupe de nœuds gérés, Amazon EKS n'ajoute pas le groupe de sécurité du cluster.

Vérifier les autorisations IAM du composant master

Assurez-vous que le rôle d'instance IAM associé au composant master dispose des politiques AmazonEKSWorkerNodePolicy et AmazonEC2ContainerRegistryReadOnly.

Remarque : vous devez attacher la politique gérée AmazonEKS_CNI_Policy à un rôle IAM. Vous pouvez l'attacher au rôle d'instance de nœud. Cependant, une bonne pratique consiste à attacher la politique à un rôle associé au compte de service Kubernetes aws-node dans l'espace de noms kube-system. Pour plus d'informations, consultez Configuration du plugin Amazon VPC CNI pour utiliser les rôles IAM pour les comptes de service.

Vérifier que l'Amazon VPC de votre cluster prend en charge un nom d'hôte et une résolution DNS

Après avoir configuré l'accès privé pour votre point de terminaison de cluster EKS, vous devez activer un nom d'hôte DNS et une résolution DNS pour votre Amazon VPC. Lorsque vous activez l'accès privé au point de terminaison, Amazon EKS crée une zone hébergée privée Amazon Route 53 pour vous. Amazon EKS l'associe ensuite à Amazon VPC de votre cluster. Pour plus d'informations, consultez Contrôle d'accès aux points de terminaison de cluster Amazon EKS.

Mettre à jour le ConfigMap aws-auth avec NodeInstanceRole associé à vos composants master

Vérifiez que le ConfigMap aws-auth est configuré correctement, avec le rôle IAM de vos composants master et non le profil d'instance.

Définir les identifications pour vos composants master

Pour la propriété Tag (Identification) de vos composants master, définissez la valeur key (clé) sur kubernetes.io/cluster/clusterName et la valeur value (valeur) sur owned (détenu).

Vérifier que les sous-réseaux Amazon VPC pour le composant master ont des adresses IP disponibles

Si votre Amazon VPC est à court d'adresses IP, vous pouvez associer une adresse CIDR secondaire à votre Amazon VPC existant. Pour plus d'informations, consultez Augmentation des adresses IP disponibles pour votre Amazon VPC.

Vérifier que vos composants master Amazon EKS peuvent atteindre le point de terminaison du serveur d'API de votre cluster

Vous pouvez lancer des composants master dans n'importe quel sous-réseau de votre VPC de cluster ou de votre sous-réseau appairé s'il existe un acheminement Internet via les passerelles suivantes :

  • NAT
  • Internet
  • Transit

Si vos composants master sont lancés dans un réseau privé restreint, vérifiez que ceux-ci peuvent atteindre le point de terminaison du serveur d'API Amazon EKS. Pour plus d'informations, consultez les conditions requises pour exécuter Amazon EKS dans un cluster privé sans accès Internet sortant.

Remarque : pour les nœuds qui se trouvent dans un sous-réseau privé soutenu par une passerelle NAT, une bonne pratique consiste à créer la passerelle NAT dans un sous-réseau public.

Si vous n'utilisez pas les points de terminaison AWS PrivateLink, vérifiez l'accès aux points de terminaison d'API via un serveur proxy pour les services AWS suivants :

  • Amazon EC2
  • Amazon ECR
  • Amazon S3

Pour vérifier que le composant master a accès au serveur d'API, connectez-vous à votre composant master en utilisant SSH et exécutez la commande netcat suivante :

nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443

Remarque : remplacez 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com par votre point de terminaison de serveur d'API.

Vérifiez les journaux kubelet tout en restant connecté à votre instance :

journalctl -f -u kubelet

Si les journaux kubelet ne vous fournissent pas d'informations sur la source du problème, vérifiez l'état du kubelet sur le composant master :

sudo systemctl status kubelet

Collectez les journaux Amazon EKS et les journaux du système d'exploitation pour un dépannage plus approfondi.

Vérifier que les points de terminaison d'API Amazon EC2, Amazon ECR et Amazon S3 peuvent atteindre votre région AWS

Utilisez SSH pour vous connecter à l'un des composants master, puis exécutez les commandes suivantes pour chaque service :

$ nc -vz ec2.region.amazonaws.com 443
$ nc -vz ecr.region.amazonaws.com 443
$ nc -vz s3.region.amazonaws.com 443

Remarque : remplacez region (région) par la région AWS de votre composant master.

Configurer les données utilisateur pour votre composant master

Pour les modèles de lancement de groupe de nœuds gérés avec une AMI spécifiée, vous devez fournir des commandes d'amorçage pour que les composants master rejoignent votre cluster. Amazon EKS ne fusionne pas les commandes d'amorçage par défaut dans vos données utilisateur. Pour plus d'informations, consultez Introduction de la prise en charge des modèles de lancement et des AMI personnalisées dans les groupes de nœuds gérés par Amazon EKS et Spécification d'une AMI.

Exemple de modèle de lancement avec commandes d'amorçage :

#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh ${ClusterName} ${BootstrapArguments}

Remarque : remplacez ${ClusterName} par le nom de votre cluster Amazon EKS. Remplacez ${BootstrapArguments} par des valeurs d'amorçage supplémentaires, si nécessaire.