Résoudre les problèmes liés aux clusters Amazon EKS locaux sur AWS Outposts configurés avec le magasin d'instances EC2

Cette rubrique décrit les erreurs courantes que vous pouvez rencontrer lors de l'utilisation de clusters Amazon EKS locaux sur des AWS Outposts configurés avec le magasin d'instances EC2 et explique comment les résoudre.

kubectl ne fonctionne pas après avoir configuré kubeconfig

Si le message d'erreur suivant s'affiche après l'exécution aws eks update-kubeconfig :

Either parameter --cluster-name or --cluster-id must be specified.

Ou:

couldn't get current server API group list: getting credentials: exec: executable aws failed with exit code 1

Vérifiez que votre kubeconfig (~/.kube/config) spécifie --cluster-name dans les exec arguments, et non --cluster-id :

      args:
        - --region
        - region-code
        - eks
        - get-token
        - --cluster-name
        - my-cluster
        - --output
        - json
      command: aws

Nœuds ne rejoignant pas le cluster

Si vos nœuds n'apparaissent pas lorsque vous exécutez kubectl get nodes :

1. Vérifiez kubelet les journaux sur le nœud. Accédez au nœud avec SSM ou SSH et exécutez :

   systemctl status kubelet -l

2. Vérifiez l'absence d'erreurs non autorisées. Des erreurs non autorisées peuvent indiquer des autorisations de rôle de nœud manquantes ou aws-auth ConfigMap des problèmes. Vérifiez que le rôle d'instance du nœud est correctement mappé dans le aws-auth ConfigMap.

3. Vérifiez le statut de la CSR. Vérifiez que la demande de signature du certificat du nœud a été approuvée :

   kubectl get csr

   Si le CSR est en Pending vigueur, approuvez-le :

   kubectl certificate approve node-csr-EXAMPLE

Cluster bloqué dans l'état CREATING

Si votre cluster passe au statut ÉCHEC :

• Capacité insuffisante : vérifiez que votre avant-poste dispose d'une capacité virtualisée suffisante pour 6 instances de plan de contrôle (3 etcd +3 serveurs d'API) des types d'instances spécifiés. Les types d'instances doivent être placés sur votre Outpost.

• La topologie de propagation ne peut pas être respectée : si vous avez spécifié un spreadLevel dehost, vérifiez qu'au moins 3 hôtes sont configurés avec le type d'instance choisi. Si vous l'avez spécifiérack, vérifiez qu'au moins 3 racks possèdent des hôtes avec le type d'instance choisi.

• Problèmes de sous-réseau : vérifiez que les sous-réseaux que vous avez spécifiés se trouvent dans la zone de disponibilité à laquelle l'avant-poste est hébergé, et que chaque sous-réseau possède au moins 3 adresses IP disponibles. Consultez Créez un VPC et des sous-réseaux pour les clusters locaux Amazon EKS sur AWS Outposts configurés avec le magasin d'instances EC2.

Cluster bloqué dans l'état de mise à jour

Si votre cluster reste dans UPDATING cet état lors d'une mise à jour de la version de Kubernetes ou de la version de plate-forme :

• Capacité insuffisante : lors des mises à jour, les instances du plan de contrôle sont supprimées avant la réinstanciation. Si la capacité libérée est consommée par une autre charge de travail avant que l'instance de remplacement ne puisse être provisionnée, la mise à jour est bloquée. Vérifiez que votre Outpost dispose de la capacité disponible pour les types d'instances du plan de contrôle.

perte de quorum, etc.

Si vous n'êtes plus en mesure d'effectuer des opérations sur l'API Kubernetes et que votre Outpost est déconnecté :

• etcdpeut avoir perdu le quorum. Cela se produit si plusieurs etcd instances deviennent indisponibles lors d'une déconnexion.

• Les charges de travail déjà en cours d'exécution continuent de fonctionner, mais les opérations de l'API Kubernetes ne sont pas disponibles.

• Lorsque la connectivité est rétablie, Amazon EKS récupère l'état de votre cluster à partir de l'etcdinstantané le plus récent.

Contactez le centre de AWS support.