

 **Aidez à améliorer cette page** 

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.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.

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.

# Dépannage des problèmes liés à Amazon EKS Connector
<a name="troubleshooting-connector"></a>

Cette rubrique couvre certaines des erreurs les plus courantes que vous pouvez rencontrer lors de l'utilisation d'Amazon EKS Connector, y compris des instructions sur la façon de les résoudre et des solutions de contournement.

## Dépannage de base
<a name="tsc-steps"></a>

Cette section décrit les étapes à suivre pour diagnostiquer les problèmes liés à Amazon EKS Connector.

### Vérifier le statut d'Amazon EKS Connector
<a name="tsc-check"></a>

Pour vérifier le contrôle de statut d’Amazon EKS Connector, veuillez saisir :

```
kubectl get pods -n eks-connector
```

### Inspecter les journaux d'Amazon EKS Connector
<a name="tsc-logs"></a>

Le pod Amazon EKS Connector se compose de trois conteneurs. Pour récupérer les journaux complets de tous ces conteneurs afin que vous puissiez les inspecter, exécutez les commandes suivantes :
+  `connector-init` 

  ```
  kubectl logs eks-connector-0 --container connector-init -n eks-connector
  kubectl logs eks-connector-1 --container connector-init -n eks-connector
  ```
+  `connector-proxy` 

  ```
  kubectl logs eks-connector-0 --container connector-proxy -n eks-connector
  kubectl logs eks-connector-1 --container connector-proxy -n eks-connector
  ```
+  `connector-agent` 

  ```
  kubectl exec eks-connector-0 --container connector-agent -n eks-connector -- cat /var/log/amazon/ssm/amazon-ssm-agent.log
  kubectl exec eks-connector-1 --container connector-agent -n eks-connector -- cat /var/log/amazon/ssm/amazon-ssm-agent.log
  ```

### Obtenir le nom effectif du cluster
<a name="tsc-name"></a>

Les clusters Amazon EKS sont identifiés de manière unique au `clusterName` sein d'un seul AWS compte et d'une seule AWS région. Si vous disposez de plusieurs clusters connectés dans Amazon EKS, vous pouvez vérifier à quel cluster Amazon EKS le cluster Kubernetes actuel est associé. Pour ce faire, saisissez la commande suivante pour connaître le `clusterName` du cluster actuel.

```
kubectl exec eks-connector-0 --container connector-agent -n eks-connector \
  -- cat /var/log/amazon/ssm/amazon-ssm-agent.log | grep -m1 -oE "eks_c:[a-zA-Z0-9_-]+" | sed -E "s/^.*eks_c:([a-zA-Z0-9_-]+)_[a-zA-Z0-9]+.*$/\1/"
kubectl exec eks-connector-1 --container connector-agent -n eks-connector \
  -- cat /var/log/amazon/ssm/amazon-ssm-agent.log | grep -m1 -oE "eks_c:[a-zA-Z0-9_-]+" | sed -E "s/^.*eks_c:([a-zA-Z0-9_-]+)_[a-zA-Z0-9]+.*$/\1/"
```

### Commandes diverses
<a name="tsc-misc"></a>

Les commandes suivantes sont utiles pour récupérer les informations dont vous avez besoin pour résoudre les problèmes.
+ Utilisez la commande suivante pour collecter les images utilisées par les pods dans Amazon EKS Connector.

  ```
  kubectl get pods -n eks-connector -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' '\n'
  ```
+ Utilisez la commande suivante pour rassembler les noms des nœuds sur lesquels Amazon EKS Connector est exécuté.

  ```
  kubectl get pods -n eks-connector -o jsonpath="{.items[*].spec.nodeName}" | tr -s '[[:space:]]' '\n'
  ```
+ Exécutez la commande suivante pour obtenir les versions de votre client et serveur Kubernetes.

  ```
  kubectl version
  ```
+ Exécutez la commande suivante pour obtenir des informations sur vos nœuds.

  ```
  kubectl get nodes -o wide --show-labels
  ```

## Problème Helm : 403 Forbidden
<a name="w662aac60c33b9"></a>

Si vous avez reçu le message d'erreur suivant lors de l'exécution des commandes d'installation de Helm :

```
Error: INSTALLATION FAILED: unexpected status from HEAD request to https://public.ecr.aws/v2/eks-connector/eks-connector-chart/manifests/0.0.6: 403 Forbidden
```

Vous pouvez exécuter la ligne suivante pour y remédier :

```
docker logout public.ecr.aws
```

## Erreur de console : le cluster est bloqué dans l'état En attente
<a name="symp-pending"></a>

Si le cluster reste bloqué dans son `Pending` état sur la console Amazon EKS une fois que vous l'avez enregistré, cela peut être dû au fait que le connecteur Amazon EKS n'a pas AWS encore réussi à connecter le cluster au cluster. Pour un cluster enregistré, l’état `Pending` signifie que la connexion n’a pas été établie avec succès. Pour résoudre ce problème, assurez-vous d'avoir appliqué le manifeste au cluster Kubernetes cible. Si vous l'avez appliqué au cluster mais que celui-ci est toujours à l'état `Pending`, il est fort probable que le statefulset `eks-connector` ne soit pas sain. Pour résoudre ce problème, consultez [Les pods du connecteur Amazon EKS sont en boucle de crash](#symp-loop) dans cette rubrique.

## Erreur de console : l’utilisateur system:serviceaccount:eks-connector:eks-connector ne peut pas usurper l’identité des utilisateurs de ressources dans le groupe d’API à portée du cluster
<a name="symp-imp"></a>

Amazon EKS Connector utilise l’[emprunt d’identité des utilisateurs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) Kubernetes pour agir au nom des [principaux IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) à partir de la AWS Management Console. Chaque principal qui accède à l'API Kubernetes depuis le compte de AWS `eks-connector` service doit être autorisé à se faire passer pour l'utilisateur Kubernetes correspondant avec un ARN IAM comme nom d'utilisateur Kubernetes. Dans les exemples suivants, l'ARN IAM est mappé à un utilisateur Kubernetes.
+ L'utilisateur IAM {{john}} du AWS compte {{111122223333}} est mappé à un utilisateur Kubernetes. Les [bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recommandent d'accorder des autorisations à des rôles plutôt qu'à des utilisateurs.

  ```
   arn:aws: iam::111122223333:user/john
  ```
+ Le rôle IAM {{admin}} du AWS compte {{111122223333}} est mappé à un utilisateur Kubernetes :

  ```
   arn:aws: iam::111122223333:role/admin
  ```

  Le résultat est un ARN de rôle IAM, au lieu de l'ARN de session AWS STS.

Pour savoir comment configurer `ClusterRole` et `ClusterRoleBinding` afin d'accorder au compte de service `eks-connector` le privilège de compte de service pour usurper l'identité de l'utilisateur mappé, consultez [Autoriser l’accès à l’affichage des ressources du cluster Kubernetes sur une console Amazon EKS](connector-grant-access.md). Assurez-vous qu'il `%IAM_ARN%` est remplacé dans le modèle par l'ARN IAM du principal AWS Management Console IAM.

## Erreur de console : […​] est interdit : l’utilisateur […​] ne peut pas répertorier la ressource […​] dans le groupe API à portée du cluster
<a name="symp-rbac"></a>

Considérons le problème suivant. Le connecteur Amazon EKS s'est fait passer pour le principal AWS Management Console IAM demandeur dans le cluster Kubernetes cible. Cependant, le principal usurpé ne dispose pas de l’autorisation RBAC pour les opérations API Kubernetes.

Pour résoudre ce problème, il existe deux méthodes pour accorder des autorisations à des utilisateurs supplémentaires. Si vous avez déjà installé eks-connector via les charts de Helm, vous pouvez facilement accorder l'accès aux utilisateurs en exécutant la commande suivante. Remplacez le `userARN1` et `userARN2` par une liste ARNs des rôles IAM permettant d'accéder aux ressources Kubernetes :

```
helm upgrade eks-connector oci://public.ecr.aws/eks-connector/eks-connector-chart \
    --reuse-values \
    --set 'authentication.allowedUserARNs={userARN1,userARN2}'
```

Ou, en tant qu’administrateur du cluster, accordez le niveau approprié de privilèges RBAC aux utilisateurs Kubernetes individuels. Pour plus d’informations et d’exemples, consultez [Autoriser l’accès à l’affichage des ressources du cluster Kubernetes sur une console Amazon EKS](connector-grant-access.md).

## Erreur de console : Amazon EKS ne peut pas communiquer avec le serveur API de votre cluster Kubernetes. Le cluster doit être dans un état ACTIF pour que la connexion soit réussie. Veuillez réessayer dans quelques minutes.
<a name="symp-con"></a>

Si le service Amazon EKS ne parvient pas à communiquer avec le connecteur Amazon EKS dans le cluster cible, cela peut être dû à l’une des raisons suivantes :
+ Amazon EKS Connector dans le cluster cible n'est pas sain.
+ Mauvaise connectivité ou interruption de la connexion entre le cluster cible et la AWS région.

Pour résoudre ce problème, consultez les [journaux d’Amazon EKS Connector](#tsc-logs). Si vous ne voyez pas d’erreur pour le connecteur Amazon EKS, réessayez la connexion après quelques minutes. Si vous rencontrez régulièrement une latence élevée ou une connectivité intermittente pour le cluster cible, envisagez de réenregistrer le cluster AWS dans une région située plus près de chez vous.

## Les pods du connecteur Amazon EKS sont en boucle de crash
<a name="symp-loop"></a>

De nombreuses raisons peuvent expliquer pourquoi un pod du connecteur Amazon EKS passe à l’état `CrashLoopBackOff`. Ce problème concerne probablement le conteneur `connector-init`. Vérifiez l’état du pod du connecteur Amazon EKS.

```
kubectl get pods -n eks-connector
```

L'exemple qui suit illustre un résultat.

```
NAME              READY   STATUS                  RESTARTS   AGE
eks-connector-0   0/2     Init:CrashLoopBackOff   1          7s
```

Si votre sortie est similaire à la sortie précédente, consultez la section [Inspecter les journaux d'Amazon EKS Connector](#tsc-logs) pour résoudre le problème.

## Impossible de lancer le connecteur EKS : InvalidActivation
<a name="symp-regis"></a>

Lorsque vous démarrez Amazon EKS Connector pour la première fois, il enregistre un `activationId` et `activationCode` avec Amazon Web Services. L'enregistrement peut échouer, ce qui peut provoquer le crash du conteneur `connector-init` avec une erreur similaire à la suivante.

```
F1116 20:30:47.261469       1 init.go:43] failed to initiate eks-connector: InvalidActivation:
```

Pour résoudre ce problème, tenez compte des causes suivantes et des correctifs recommandés :
+ L’enregistrement a peut-être échoué, car les éléments `activationId` et `activationCode` ne figurent pas dans votre fichier manifeste. Si c'est le cas, assurez-vous qu'il s'agit des valeurs correctes renvoyées par l'opération d'API `RegisterCluster` et que `activationCode` se trouve dans le fichier manifeste. Le `activationCode` est ajouté aux secrets Kubernetes, il doit donc être encodé en `base64`. Pour de plus amples informations, veuillez consulter [Étape 1 : Enregistrement du cluster](connecting-cluster.md#connector-connecting).
+ L'enregistrement a peut-être échoué car votre activation a expiré. En effet, pour des raisons de sécurité, vous devez activer Amazon EKS Connector dans les trois jours suivant l'enregistrement du cluster. Pour résoudre ce problème, assurez-vous que le manifeste du connecteur Amazon EKS est appliqué au cluster Kubernetes cible avant la date et l’heure d’expiration. Pour confirmer la date d'expiration de votre activation, exécutez un appel à l'opération API `DescribeCluster`.

  ```
  aws eks describe-cluster --name my-cluster
  ```

  Dans l'exemple de réponse suivant, la date et l'heure d'expiration sont enregistrées sous la forme `2021-11-12T22:28:51.101000-08:00`.

  ```
  {
      "cluster": {
          "name": "my-cluster",
          "arn": "arn:aws: eks:region:111122223333:cluster/my-cluster",
          "createdAt": "2021-11-09T22:28:51.449000-08:00",
          "status": "FAILED",
          "tags": {
          },
          "connectorConfig": {
              "activationId": "00000000-0000-0000-0000-000000000000",
              "activationExpiry": "2021-11-12T22:28:51.101000-08:00",
              "provider": "OTHER",
              "roleArn": "arn:aws: iam::111122223333:role/my-connector-role"
          }
      }
  }
  ```

  Si l'`activationExpiry` est passée, désenregistrez le cluster et enregistrez-le à nouveau. Cela génère une nouvelle activation.

## Le nœud du cluster manque de connectivité sortante
<a name="symp-out"></a>

Pour fonctionner correctement, le connecteur Amazon EKS nécessite une connectivité sortante vers plusieurs points de AWS terminaison. Vous ne pouvez pas connecter un cluster privé sans connectivité sortante à une AWS région cible. Pour résoudre ce problème, vous devez ajouter la connectivité sortante nécessaire. Pour plus d'informations sur les exigences de connecteur, consultez [Considérations relatives à Amazon EKS Connector](eks-connector.md#connect-cluster-reqts).

## Les pods du connecteur Amazon EKS sont dans l’état `ImagePullBackOff`
<a name="symp-img"></a>

Si vous exécutez la commande `get pods` et que les pods sont dans l’état `ImagePullBackOff`, ils ne peuvent pas fonctionner correctement. Si les pods Amazon EKS Connector sont dans l’état `ImagePullBackOff`, ils ne peuvent pas fonctionner correctement. Vérifiez l’état de vos pods Amazon EKS Connector.

```
kubectl get pods -n eks-connector
```

L'exemple qui suit illustre un résultat.

```
NAME              READY   STATUS                  RESTARTS   AGE
eks-connector-0   0/2     Init:ImagePullBackOff   0          4s
```

Le fichier manifeste Amazon EKS Connector par défaut fait référence aux images de la [galerie publique Amazon ECR](https://gallery.ecr.aws/). Il est possible que le cluster Kubernetes cible ne puisse pas extraire d’images de la galerie publique Amazon ECR. Veuillez soit résoudre le problème d'extraction d'images de la galerie publique Amazon ECR, soit envisager la mise en miroir des images dans le registre de conteneurs privé de votre choix.