Comment résoudre les problèmes liés à la création de groupes de nœuds gérés par Amazon EKS ?
Mon groupe de nœuds géré par Amazon Elastic Kubernetes Service (Amazon EKS) n’a pas pu être créé. 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 d’automatisation d’AWS Systems Manager pour identifier les problèmes courants.
- Confirmez les exigences en matière de trafic du groupe de sécurité du composant master.
- Vérifiez les autorisations de gestion des identités et des accès (IAM) 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 la ConfigMap aws-auth avec le NodeInstanceRole de vos composants master.
- Définissez les balises pour vos composants master.
- Vérifiez que les sous-réseaux Amazon VPC du composant master disposent d’adresses IP disponibles.
- Vérifiez que les composants master peuvent atteindre le point de terminaison du serveur d’API pour votre cluster.
- Vérifiez que les points de terminaison des 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.
Résolution
Remarque : Si des erreurs surviennent lors de l’exécution des commandes de l’interface de la ligne de commande AWS (AWS CLI), vérifiez que vous utilisez la version la plus récente de l’AWS CLI.
Utilisez le runbook d’automatisation de Systems Manager pour identifier les problèmes courants
Utilisez le runbook AWSSupport-TroubleshootEKSWorkerNode pour identifier les problèmes courants qui empêchent les composants master de rejoindre votre cluster.
Important : Pour que l’automatisation fonctionne, vos composants master doivent être autorisés à accéder à Systems Manager et à exécuter Systems Manager. Pour accorder l’autorisation, associez la politique gérée Amazon SSMManagedInstanceCore AWS 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.
- Ouvrez le runbook.
- 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. - Dans la section Input parameters (Paramètres d’entrée), spécifiez le nom de votre cluster dans le champ ClusterName (Nom de cluster) et l’ID d’instance dans le champ WorkerID (ID de travailleur).
- (Facultatif) Dans le champ AutomationAssumeRole, spécifiez le rôle IAM pour permettre à Systems Manager d’effectuer des actions. Si elles ne sont pas spécifiées, les autorisations IAM de votre entité IAM actuelle sont utilisées pour effectuer les actions du runbook.
- Choisissez Execute (Exécuter).
- Consultez la section Outputs (Sorties) pour découvrir pourquoi votre composant master ne rejoint pas votre cluster et les étapes à suivre pour y remédier.
Confirmer les exigences relatives au 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 afin de 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é, Amazon EKS n’ajoute pas le groupe de sécurité du cluster.
Vérifier les autorisations IAM du composant master
Assurez-vous que les politiques AmazonEKSWorkerNodePolicy et AmazonEC2ContainerRegistryReadOnly sont associées au rôle d’instance IAM associé au composant master.
Remarque : Vous devez associer la politique gérée par Amazon AmazonEKS_CNI_Policy à un rôle IAM. Vous pouvez l’associer au rôle d’instance de nœud. Toutefois, il est recommandé d’associer 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 plug-in Amazon VPC CNI pour Kubernetes afin d’utiliser des rôles IAM pour les comptes de service.
Vérifiez 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 le point de terminaison de votre 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é aux points 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 la section Contrôle d’accès aux points de terminaison du cluster Amazon EKS.
Mettez à jour l’aws-auth ConfigMap avec le NodeInstanceRole de vos composants master
Vérifiez que la ConfigMap aws-auth est correctement configurée avec le rôle IAM de vos composants master, et non avec le profil d’instance.
Définissez les balises pour vos composants master
Pour la propriété Tag (Balise) de vos composants master, définissez la key (clé) sur kubernetes.io/cluster/clusterName et définissez la value (valeur) sur owned (détenu).
Vérifiez que les sous-réseaux Amazon VPC du composant master disposent d’adresses IP disponibles
Si votre Amazon VPC est à court d’adresses IP, vous pouvez associer un CIDR secondaire à votre Amazon VPC existant. Pour plus d’informations, consultez la section Exigences et considérations relatives au VPC et au sous-réseau Amazon EKS.
Vérifiez que vos composants master Amazon EKS peuvent atteindre le point de terminaison du serveur d’API pour votre cluster
Vous pouvez lancer des composants master dans n’importe quel sous-réseau de votre cluster VPC ou sous-réseau apparenté s’il existe une route Internet via les passerelles suivantes :
- NAT
- Internet
- Transit
Si vos composants master sont lancés sur un réseau privé restreint, vérifiez qu’ils 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, il est recommandé de créer la passerelle NAT dans un sous-réseau public.
Si vous n’utilisez pas de 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 nœud de travail a accès au serveur d’API, connectez-vous à votre composant master via 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 le point de terminaison de votre serveur d'API.
Vérifiez les journaux de kubelet tout en étant connecté à votre instance :
journalctl -f -u kubelet
Si les journaux du kubelet ne fournissent aucune information 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érifiez que les points de terminaison des 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 la région par la région AWS pour votre composant master.
Configurez les données utilisateur pour votre composant master
Pour les modèles de lancement de groupes de nœuds gérés avec une AMI spécifiée, vous devez fournir des commandes d’amorçage permettant aux composants master de rejoindre 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 Présentation du modèle de lancement et de la prise en charge des AMI personnalisées dans les groupes de nœuds gérés Amazon EKS et Spécification d’une AMI.
Exemple de modèle de lancement avec des commandes bootstrap :
#!/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.
Informations connexes
Résolution des problèmes d’Amazon EKS
Comment puis-je faire en sorte que mes composants master rejoignent mon cluster Amazon EKS ?
Contenus pertinents
- demandé il y a 2 anslg...
- demandé il y a un anlg...
- demandé il y a un anlg...
- demandé il y a un anlg...
- demandé il y a 4 moislg...
- AWS OFFICIELA mis à jour il y a 10 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 2 ans