Comment résoudre les problèmes eksctl relatifs aux clusters et aux groupes de nœuds Amazon EKS ?

Brève description

Voici les problèmes courants que vous pouvez rencontrer lorsque vous utilisez eksctl pour créer ou gérer un cluster ou un groupe de nœuds Amazon EKS :

• Vous ne savez pas comment créer un cluster avec eksctl. Consultez Premiers pas avec Amazon EKS – eksctl ainsi que la section****eksctl de la rubrique Création d'un cluster Amazon EKS.
• Vous ne savez pas comment spécifier les options d'amorçage kubelet pour les groupes de nœuds gérés. Suivez les étapes de la section de résolution Spécifier les options d'amorçage kubelet.
• Vous ne savez pas comment modifier le type d'instance d'un groupe de nœuds existant. Vous devez créer un groupe de nœuds. Reportez-vous aux sections Migration vers un nouveau groupe de nœuds et Immuabilité du groupe de nœuds (dans le site web eskctl).
• Vous avez atteint le nombre maximum de ressources AWS. Vérifiez vos ressources pour savoir si vous pouvez supprimer celles que vous n'utilisez pas. Si vous avez toujours besoin de plus de capacité, consultez Demande d'augmentation de quota.
• Vous lancez des instances de plan de contrôle dans une zone de disponibilité dont la capacité est limitée. Consultez Comment puis-je remédier aux erreurs de création de clusters dans Amazon EKS ?
• Vos nœuds ne parviennent pas à passer à l'état Prêt. Suivez les étapes de la section de résolution Résoudre les problèmes liés au délai d'expiration de l'opération.
• Les valeurs d'exportation n'existent pas pour le cluster. Suivez les étapes de la section de résolution Créer le groupe de nœuds dans les sous-réseaux privés.
• Vous avez utilisé un type d'instance non pris en charge pour créer un cluster ou un groupe de nœuds. Suivez les étapes de la section de résolution Vérifiez si votre type d'instance est pris en charge.

Résolution

Spécifier les options d'amorçage kubelet

Par défaut, eksctl crée un script d'amorçage et l'ajoute au modèle de lancement que les composants master exécutent pendant le processus d'amorçage. Pour spécifier vos propres options d'amorçage kubelet, utilisez la spécification overrideBootstrapCommand pour remplacer le script d'amorçage eksctl. Utilisez overrideBootstrapCommand pour les groupes de nœuds gérés et autogérés.

Spécification du fichier de configuration :

managedNodeGroups:
  name: custom-ng
  ami: ami-0e124de4755b2734d
  securityGroups:
    attachIDs: ["sg-1234"]
  maxPodsPerNode: 80
  ssh:
    allow: true
  volumeSize: 100
  volumeName: /dev/xvda
  volumeEncrypted: true
  disableIMDSv1: true
  overrideBootstrapCommand: |
  #!/bin/bash
  /etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'

Remarque : vous ne pouvez utiliser overrideBootstrapCommand que lorsque vous utilisez une AMI personnalisée. Si vous ne spécifiez pas d'ID d'AMI, la création du cluster échoue.

Aucun ID d'AMI personnalisé n'a été spécifié

Si vous ne spécifiez pas d'ID d'AMI personnalisé lorsque vous créez des groupes de nœuds gérés, Amazon EKS utilise par défaut une AMI optimisée pour Amazon EKS et un script d'amorçage. Pour utiliser une AMI optimisée pour Amazon EKS avec des données utilisateur personnalisées afin de spécifier les paramètres d'amorçage, spécifiez l'ID d'AMI dans la configuration de votre groupe de nœuds géré.

Pour obtenir l'ID d'AMI le plus récent pour la dernière AMI optimisée pour Amazon EKS, exécutez la commande suivante :

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.21/amazon-linux-2/recommended/image_id --region Region --query "Parameter.Value" --output text

Remarque : remplacez la région par votre région AWS.

Résoudre les problèmes de délai de fonctionnement

Si le message d'erreur suivant s'affiche lors de la création d'un nœud, il se peut que votre groupe de nœuds présente des problèmes de délai d'expiration :

waiting for at least 1 node(s) to become ready in "nodegroup"

Lorsque vous créez un groupe de nœuds EKS avec eksctl, l'interface de ligne de commande eksctl se connecte au serveur d'API pour vérifier en permanence le statut du nœud Kubernetes. L'interface de ligne de commande attend que les nœuds passent au statut Prêt, et finit par expirer si les nœuds ne parviennent pas à changer de statut.

Voici les raisons pour lesquelles les nœuds ne parviennent pas à passer au statut Prêt :

• Le kubelet ne peut pas communiquer avec le point de terminaison du serveur d'API EKS pendant le processus d'amorçage, ni s'authentifier auprès de ce point.
• Les pods aws-node et kube-proxy ne sont pas au statut En cours d'exécution.
• Les données utilisateur du composant master Amazon Elastic Compute Cloud (Amazon EC2) n'ont pas été exécutées correctement.

Le kubelet ne peut pas communiquer avec le point de terminaison du serveur d'API EKS

Si le kubelet ne peut pas communiquer avec le point de terminaison du serveur d'API EKS pendant le processus d'amorçage, récupérez le point de terminaison du serveur d'API EKS.

Exécutez la commande suivante sur votre composant master :

curl -k https://123456DC0A12EC12DE0C12BC312FCC1A.yl4.us-east-1.eks.amazonaws.com
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

La commande précédente doit renvoyer le code de statut HTTP 403. Si la commande expire, il se pourrait que vous rencontriez un problème de connectivité réseau entre le serveur d'API EKS et les composants master.

Pour résoudre le problème de connectivité, effectuez l'une des étapes suivantes en rapport avec votre cas d'utilisation :

• Si les composants master se trouvent dans un sous-réseau privé, vérifiez que le point de terminaison du serveur d'API EKS est en mode d'accès privé et public ou privé.
• Si le point de terminaison du serveur d'API EKS est défini sur Privé, vous devez appliquer certaines règles pour que la zone hébergée privée achemine le trafic vers le serveur d'API. Les attributs Amazon Virtual Private Cloud (Amazon VPC) enableDnsHostnames et enableDnsSupport doivent être définis sur True. En outre, les options DHCP définies pour l'Amazon VPC doivent inclure AmazonProvideDNS dans sa liste de domaines.
• Si vous avez créé le groupe de nœuds dans des sous-réseaux publics, assurez-vous que l'attribut d'adressage public IPv4 des sous-réseaux est défini sur True. Si vous ne définissez pas l'attribut sur True, les composants master ne se voient pas attribuer d'adresse IP publique et ne peuvent pas accéder à Internet.
• Vérifiez si le groupe de sécurité du cluster Amazon EKS autorise les demandes d'entrée sur le port 443 à partir du groupe de sécurité du composant master.

Le kubelet ne peut pas s'authentifier auprès du point de terminaison du serveur d'API EKS

Si le kubelet ne peut pas s'authentifier auprès du point de terminaison du serveur d'API EKS pendant le processus d'amorçage, procédez comme suit.

1.    Exécutez la commande suivante pour vérifier que le composant master a accès au point de terminaison STS :

telnet sts.region.amazonaws.com 443

Remarque : remplacez la région par votre région AWS.

2.    Assurez-vous que le rôle AWS Identity and Access Management (IAM) du nœud de travail a été ajouté au ConfigMap aws-auth.

Par exemple :

apiVersion:v1 kind:ConfigMap metadata:name:aws-auth namespace:kube-system data:mapRoles:|
    - rolearn: ARN of instance role (not instance profile)
      username: system:node:{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Remarque : pour les groupes de nœuds Microsoft Windows, vous devez ajouter un groupe RBAC eks:kube-proxy-windows supplémentaire à la section mapRoles pour le rôle IAM du groupe de nœuds.

Les pods aws-node et kube-proxy ne sont pas à l'état En cours d'exécution

Pour vérifier si les pods aws-node et kube-proxy ont le statut En cours d'exécution, exécutez la commande suivante :

kubectl get pods -n kube-system

Si le pod aws-node a le statut Échec, vérifiez la connexion entre le composant master et le point de terminaison Amazon EC2 :

ec2.region.amazonaws.com

Remarque : remplacez la région par votre région AWS.

Vérifiez que les politiques gérées par AWS AmazonEKSWorkerNodePolicy et AmazonEC2ContainerRegistryReadOnly sont attachées au rôle IAM du groupe de nœuds.

Si les nœuds se trouvent dans un sous-réseau privé, vous devez configurer les points de terminaison d'un VPC Amazon ECR pour autoriser les extractions d'images à partir d'Amazon Elastic Container Registry (Amazon ECR).

Si vous utilisez IRSA pour votre CNI Amazon VPC, attachez la politique gérée par AWS AmazoneEKS_CNI_Policy au rôle IAM utilisé par les pods aws-node. Vous devez également attacher la politique au rôle IAM du groupe de nœuds sans IRSA.

Les données utilisateur du composant master EC2 n'ont pas été exécutées correctement

Pour vérifier si des erreurs se sont produites lors de l'exécution des données utilisateur, consultez les journaux cloud-init aux adresses /var/log/cloud-init.log et /var/log/cloud-init-output.log.

Pour plus d'informations, exécutez le script EKS Logs Collector sur les composants master.

Créer le groupe de nœuds dans des sous-réseaux privés

Si vous recevez l'erreur suivante lors de la création d'un groupe de nœuds, créez le groupe de nœuds dans des sous-réseaux privés :

No export named eksctl--cluster::SubnetsPublic found. Rollack requested by user

Si vous avez créé le cluster Amazon EKS avec les réseaux PrivateOnly, AWS CloudFormation ne peut pas créer de sous-réseaux publics. Cela signifie que les valeurs d'exportation n'existeront pas pour les sous-réseaux publics. Si les valeurs d'exportation n'existent pas pour le cluster, la création du groupe de nœuds échoue.

Pour résoudre ce problème, vous pouvez inclure l'indicateur --node-private-networking lorsque vous utilisez la commande eksctl inline. Vous pouvez également utiliser la spécification privateNetworking: true dans la configuration du groupe de nœuds pour demander la création d'un groupe de nœuds dans des sous-réseaux privés.

Mettre à jour votre version eksctl ou spécifiez la bonne région AWS

Si vous recevez le message d'erreur suivant, vérifiez votre région AWS :

no eksctl-managed CloudFormation stacks found for "cluster-name"

Si vous utilisez une version eksctl antérieure à la version 0.40.0, vous ne pouvez afficher ou gérer que les ressources Amazon EKS que vous avez créées avec eksctl. Pour gérer les ressources qui n'ont pas été créées avec eksctl, mettez à jour eksctl vers la version 0.40.0 ou une version ultérieure. Pour en savoir plus sur les commandes que vous pouvez exécuter pour les clusters qui n'ont pas été créés avec eksctl, consultez Clusters non créés avec eksctl (sur le site web d'eksctl).

En outre, les piles CloudFormation gérées par eksctl sont introuvables si vous spécifiez une région AWS incorrecte. Pour résoudre ce problème, assurez-vous de spécifier la bonne région dans laquelle se trouvent vos ressources Amazon EKS.

Vérifier si votre type d'instance est pris en charge

Si vous avez utilisé un type d'instance non pris en charge pour créer un cluster ou un nœud, le message d'erreur suivant s'affiche :

You must use a valid fully-formed launch template. The requested configuration is currently not supported. Please check the documentation for supported configurations'

Pour vérifier si votre type d'instance ou d'autres configurations sont pris en charge dans une région AWS spécifique, exécutez la commande suivante :

aws ec2 describe-instance-type-offerings --region Region --query 'InstanceTypeOfferings[*].{InstanceType:InstanceType}'

Remarque : remplacez la région par votre région AWS.

---