Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# FAQ Eksctl
<a name="faq"></a>

## Général
<a name="_general"></a>

 **Puis-je utiliser `eksctl` pour gérer des clusters qui n'ont pas été créés par `eksctl` ?** 

Oui \! À partir de la version, `0.40.0` vous `eksctl` pouvez exécuter sur n'importe quel cluster, qu'il ait été créé par `eksctl` ou non. Pour de plus amples informations, veuillez consulter [Clusters non créés par eksctl](unowned-clusters.md).

## Groupes de nœuds
<a name="nodegroup-faq"></a>

 **Comment puis-je modifier le type d'instance de mon groupe de nœuds ?** 

Du point de vue de`eksctl`, les groupes de nœuds sont immuables. Cela signifie qu'une fois créé, la seule chose que `eksctl` vous pouvez faire est de redimensionner le groupe de nœuds vers le haut ou vers le bas.

Pour modifier le type d'instance, créez un nouveau groupe de nœuds avec le type d'instance souhaité, puis videz-le afin que les charges de travail soient déplacées vers le nouveau. Une fois cette étape terminée, vous pouvez supprimer l'ancien groupe de nœuds.

 **Comment puis-je voir les données utilisateur générées pour un groupe de nœuds ?** 

Vous aurez d'abord besoin du nom de la pile Cloudformation qui gère le groupe de nœuds :

```
eksctl utils describe-stacks --region=us-west-2 --cluster NAME
```

Vous verrez un nom similaire à`eksctl-CLUSTER_NAME-nodegroup-NODEGROUP_NAME`.

Vous pouvez exécuter ce qui suit pour obtenir les données utilisateur. Notez la dernière ligne qui décode à partir de base64 et décompresse les données compressées.

```
NG_STACK=eksctl-scrumptious-monster-1595247364-nodegroup-ng-29b8862f # your stack here
LAUNCH_TEMPLATE_ID=$(aws cloudformation describe-stack-resources --stack-name $NG_STACK \
| jq -r '.StackResources | map(select(.LogicalResourceId == "NodeGroupLaunchTemplate") \
| .PhysicalResourceId)[0]')
aws ec2 describe-launch-template-versions --launch-template-id $LAUNCH_TEMPLATE_ID \
| jq -r '.LaunchTemplateVersions[0].LaunchTemplateData.UserData' \
| base64 -d | gunzip
```

## Ingress
<a name="_ingress"></a>

 **Comment configurer l'entrée avec `eksctl` ?** 

Nous vous recommandons d'utiliser le [contrôleur AWS Load Balancer](https://github.com/kubernetes-sigs/aws-load-balancer-controller). [La documentation sur le déploiement du contrôleur sur votre cluster, ainsi que sur la migration depuis l'ancien contrôleur d'entrée ALB, est disponible ici.](https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html)

Pour le Nginx Ingress Controller, la configuration serait la même que celle des [autres clusters Kubernetes](https://kubernetes.github.io/ingress-nginx/deploy/#aws).

## Kubectl
<a name="_kubectl"></a>

 **J'utilise un proxy HTTPS et la validation du certificat de cluster échoue. Comment puis-je utiliser les autorités de certification du système ?** 

Définissez la variable `KUBECONFIG_USE_SYSTEM_CA` d'environnement pour `kubeconfig` respecter les autorités de certification du système.