Résolution des problèmes liés aux nœuds hybrides

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.

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.

Cette rubrique décrit certaines erreurs courantes que vous pouvez rencontrer lors de l'utilisation des nœuds hybrides Amazon EKS et explique comment les corriger. Pour d'autres informations de dépannage, consultez le Résoudre les problèmes liés aux clusters et nœuds Amazon EKS tag Knowledge Center pour Amazon EKS sur AWS Re:Post. Si vous ne parvenez pas à résoudre le problème, contactez AWS le Support.

Vous pouvez exécuter la nodeadm debug commande depuis vos nœuds hybrides pour vérifier que les exigences en matière de mise en réseau et d'identification sont satisfaites. Pour plus d'informations sur la nodeadm debug commande, consulteznodeadmRéférence des nœuds hybrides.

Dépannage de l'installation de nœuds hybrides

Les rubriques de résolution des problèmes de cette section concernent l'installation des dépendances des nœuds hybrides sur les hôtes à l'aide de la nodeadm install commande.

échec de la commande nodeadm must run as root

La nodeadm install commande doit être exécutée avec un utilisateur disposant des privilèges root/sudo sur votre hôte. Si vous exécutez nodeadm install avec un utilisateur qui n'a pas les privilèges root/sudo, vous verrez l'erreur suivante dans la sortie de nodeadm.

"msg":"Command failed","error":"must run as root"

Impossible de se connecter aux dépendances

La nodeadm install commande installe les dépendances requises pour les nœuds hybrides. Les dépendances des nœuds hybrides incluentcontainerd, kubeletkubectl, et les composants AWS SSM ou AWS IAM Roles Anywhere. Vous devez avoir accès à partir de l'endroit où vous exécutez nodeadm install pour télécharger ces dépendances. Pour plus d'informations sur la liste des emplacements auxquels vous devez être en mesure d'accéder, consultezPréparer le réseau pour les nœuds hybrides. Si vous n'y avez pas accès, vous verrez des erreurs similaires aux suivantes dans le nodeadm install résultat.

"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"

Impossible de mettre à jour le gestionnaire de packages

La nodeadm install commande exécute apt update ou yum/dnf update before installing the hybrid nodes dependencies. If this step does not succeed you may see errors similar to the following. To remediate, you can run apt update or yum/dnf update avant de l'exécuter nodeadm install ou vous pouvez essayer de la réexécuternodeadm install.

failed to run update using package manager

Délai d'expiration ou délai de mise en contexte dépassé

Lors de l'exécutionnodeadm install, si vous rencontrez des problèmes à différentes étapes du processus d'installation avec des erreurs indiquant un délai d'expiration ou un délai contextuel dépassé, il se peut que votre connexion soit lente et empêche l'installation des dépendances des nœuds hybrides avant que les délais ne soient atteints. Pour contourner ces problèmes, vous pouvez essayer d'utiliser l'--timeoutindicateur nodeadm pour prolonger la durée des délais de téléchargement des dépendances.

nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
      

Dépannage des problèmes liés à la connexion

Les rubriques de résolution des problèmes de cette section concernent le processus de connexion des nœuds hybrides aux clusters EKS à l'aide de la nodeadm init commande.

Erreurs de fonctionnement ou schéma non pris en charge

Lors de l'exécutionnodeadm init, si vous constatez des erreurs liées nodeConfig.yaml à operation error ouunsupported scheme, vérifiez que le format et la transmission sont corrects. nodeadm Pour plus d'informations sur le format et les options pournodeConfig.yaml, voirnodeadmRéférence des nœuds hybrides.

"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"

Nœuds hybrides (rôle IAM) : autorisations manquantes pour l'action eks:DescribeCluster

Lors de l'exécutionnodeadm init, nodeadm tente de recueillir des informations sur votre cluster EKS en appelant Describe Cluster. Si votre rôle Hybrid Nodes IAM n'est pas autorisé à effectuer cette eks:DescribeCluster action. Pour plus d'informations sur les autorisations requises pour le rôle IAM des nœuds hybrides, consultezPréparer les informations d'identification pour les nœuds hybrides.

"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"

Les nœuds hybrides n'apparaissent pas dans le cluster EKS

Si vous l'avez exécuté nodeadm init et que vous l'avez terminé, mais que vos nœuds hybrides n'apparaissent pas dans votre cluster, il se peut que des problèmes se produisent au niveau de la connexion réseau entre vos nœuds hybrides et le plan de contrôle EKS, que vous n'ayez pas configuré les autorisations de groupe de sécurité requises ou que vous n'ayez pas le mappage requis entre votre rôle IAM de nœuds hybrides et le contrôle d'accès basé sur les rôles (RBAC) de Kubernetes. Vous pouvez démarrer le processus de débogage en vérifiant l'état de kubelet et des journaux de kubelet à l'aide des commandes suivantes. Exécutez les commandes suivantes à partir des nœuds hybrides qui n'ont pas réussi à rejoindre votre cluster.

systemctl status kubelet

journalctl -u kubelet -f

Impossible de communiquer avec le cluster

Si votre nœud hybride n'a pas pu communiquer avec le plan de contrôle du cluster, des journaux similaires aux suivants peuvent s'afficher.

"Failed to ensure lease exists, will retry" err="Get ..."

"Unable to register node with API server" err="Post ..."

Failed to contact API server when waiting for CSINode publishing ... dial tcp <ip address>: i/o timeout

Si vous voyez ces messages, vérifiez les points suivants pour vous assurer qu'ils répondent aux exigences relatives aux nœuds hybrides détaillées dansPréparer le réseau pour les nœuds hybrides.

Non autorisé

Si votre nœud hybride a pu communiquer avec le plan de contrôle EKS mais n'a pas pu s'enregistrer, des journaux similaires aux suivants peuvent s'afficher. Notez que la principale différence entre les messages du journal ci-dessous est l'Unauthorizederreur. Cela indique que le nœud n'a pas été en mesure d'effectuer ses tâches car il ne dispose pas des autorisations requises.

"Failed to ensure lease exists, will retry" err="Unauthorized"

"Unable to register node with API server" err="Unauthorized"

Failed to contact API server when waiting for CSINode publishing: Unauthorized

Si vous voyez ces messages, vérifiez les points suivants pour vous assurer qu'ils répondent aux exigences relatives aux nœuds hybrides détaillées dans Préparer les informations d'identification pour les nœuds hybrides etPréparer l'accès au cluster pour les nœuds hybrides.

Nœuds hybrides enregistrés auprès du cluster EKS mais affichant leur statut Not Ready

Si vos nœuds hybrides se sont enregistrés avec succès auprès de votre cluster EKS, mais que le statut des nœuds hybrides s'Not Readyaffiche, la première chose à vérifier est le statut de votre interface réseau de conteneurs (CNI). Si vous n'avez pas installé de CNI, vos nœuds hybrides devraient avoir un statutNot Ready. Une fois qu'un CNI est installé et fonctionne correctement, les nœuds passent à l'état Prêt. Si vous avez essayé d'installer un CNI mais qu'il ne fonctionne pas correctement, consultez cette Dépannage des nœuds hybrides CNI page.

Les demandes de signature de certificat (CSRs) sont bloquées en attente

Après avoir connecté des nœuds hybrides à votre cluster EKS, si vous constatez que CSRs des nœuds hybrides sont en attente, cela signifie que ceux-ci ne répondent pas aux exigences d'approbation automatique. CSRs pour les nœuds hybrides sont automatiquement approuvés et émis si les CSRs nœuds hybrides ont été créés par un nœud portant une eks.amazonaws.com/compute-type: hybrid étiquette, et que le CSR possède les noms alternatifs de sujet suivants (SANs) : au moins un SAN DNS égal au nom du nœud et l'adresse IP SANs appartient au réseau de nœuds distants CIDRs.

Le profil hybride existe déjà

Si vous avez modifié votre nodeadm configuration et que vous tentez de réenregistrer le nœud avec la nouvelle configuration, un message d'erreur indiquant que le profil hybride existe déjà mais que son contenu a changé peut s'afficher. Au lieu de l'exécuter nodeadm init entre les modifications de configuration, exécutez nodeadm uninstall suivi d'un nodeadm install etnodeadm init. Cela garantit un nettoyage approprié en fonction des modifications de configuration.

"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"

Le nœud hybride n'a pas réussi à résoudre l'API privée

Après l'exécutionnodeadm init, si vous voyez une erreur dans les kubelet journaux indiquant que vous n'avez pas réussi à contacter le serveur d'API EKS Kubernetes parce que c'est le casno such host, vous devrez peut-être modifier votre entrée DNS pour le point de terminaison de l'API EKS Kubernetes sur votre réseau local ou au niveau de l'hôte. Consultez la section Transfert de requêtes DNS entrantes vers votre VPC dans AWS la documentation de Route53.

Failed to contact API server when waiting for CSINode publishing: Get ... no such host

Impossible d'afficher les nœuds hybrides dans la console EKS

Si vous avez enregistré vos nœuds hybrides mais que vous ne parvenez pas à les afficher dans la console EKS, vérifiez les autorisations du principal IAM que vous utilisez pour consulter la console. Le principal IAM que vous utilisez doit disposer d'autorisations IAM et Kubernetes minimales spécifiques pour afficher les ressources dans la console. Pour de plus amples informations, veuillez consulter Consultez les ressources Kubernetes dans AWS Management Console.

Résolution des problèmes d'exécution de nœuds hybrides

Si vos nœuds hybrides étaient enregistrés auprès de votre cluster EKS, avaient un statut Ready puis sont passés au statutNot Ready, de nombreux problèmes peuvent avoir contribué à ce mauvais état, tels que le fait que le nœud ne dispose pas de ressources suffisantes pour le processeur, la mémoire ou l'espace disque disponible, ou que le nœud est déconnecté du plan de contrôle EKS. Vous pouvez suivre les étapes ci-dessous pour dépanner vos nœuds, et si vous ne parvenez pas à résoudre le problème, contactez le AWS Support.

Exécutez nodeadm debug à partir de vos nœuds hybrides pour vérifier que les exigences en matière de réseau et d'identification sont satisfaites. Pour plus d'informations sur la nodeadm debug commande, consulteznodeadmRéférence des nœuds hybrides.

Obtenir le statut du nœud

kubectl get nodes -o wide

Vérifiez les conditions et les événements du nœud

kubectl describe node NODE_NAME
      

Obtenir le statut du pod

kubectl get pods -A -o wide

Vérifiez l'état et les événements du pod

kubectl describe pod POD_NAME
      

Vérifiez les journaux du pod

kubectl logs POD_NAME
      

Vérifiez les journaux kubectl

systemctl status kubelet

journalctl -u kubelet -f

Les sondes de durée de vie du pod échouent ou les webhooks ne fonctionnent pas

Si les applications, les modules complémentaires ou les webhooks exécutés sur vos nœuds hybrides ne démarrent pas correctement, il est possible que vous rencontriez des problèmes de réseau qui bloquent la communication avec les modules. Pour que le plan de contrôle EKS puisse contacter les webhooks exécutés sur des nœuds hybrides, vous devez configurer votre cluster EKS avec un réseau de modules distants et disposer de routes pour le CIDR de votre pod local dans la table de routage de votre VPC avec comme cible votre Transit Gateway (TGW), votre passerelle privée virtuelle (VPW) ou toute autre passerelle que vous utilisez pour connecter votre VPC à votre réseau local. Pour plus d'informations sur les exigences de mise en réseau pour les nœuds hybrides, consultezPréparer le réseau pour les nœuds hybrides. Vous devez également autoriser ce trafic dans votre pare-feu local et vous assurer que votre routeur peut être correctement acheminé vers vos pods.

Un message de log du pod courant pour ce scénario est affiché ci-dessous, où l'adresse IP est l'adresse IP du cluster pour le service Kubernetes.

dial tcp <ip-address>:443: connect: no route to host

Dépannage des nœuds hybrides CNI

Si vous rencontrez des problèmes lors du démarrage initial de Cilium ou Calico avec des nœuds hybrides, cela est le plus souvent dû à des problèmes de réseau entre les nœuds hybrides ou les pods CNI exécutés sur des nœuds hybrides et le plan de contrôle EKS. Assurez-vous que votre environnement répond aux exigences de la section Préparer le réseau pour les nœuds hybrides. Il est utile de décomposer le problème en plusieurs parties.

Le nœud hybride a un statut Ready sans CNI installé

Si vos nœuds hybrides affichent un étatReady, mais que vous n'avez pas installé de CNI sur votre cluster, il est possible que d'anciens artefacts CNI soient présents sur vos nœuds hybrides. Par défaut, lorsque vous désinstallez Cilium et Calico à l'aide d'outils tels que Helm, les ressources sur disque ne sont pas supprimées de vos machines physiques ou virtuelles. En outre, les définitions de ressources personnalisées (CRDs) CNIs correspondantes peuvent toujours être présentes sur votre cluster depuis une ancienne installation. Pour plus d'informations, consultez les sections Supprimer le cilium et Supprimer le calico de. Configuration d'un CNI pour les nœuds hybrides

Résolution des problèmes liés à Cilium

Si vous rencontrez des problèmes pour exécuter Cilium sur des nœuds hybrides, consultez les étapes de résolution des problèmes dans la documentation de Cilium. Les sections ci-dessous abordent les problèmes qui peuvent être propres au déploiement de Cilium sur des nœuds hybrides.

Cilium ne démarre pas

Si les agents Cilium qui s'exécutent sur chaque nœud hybride ne démarrent pas, vérifiez la présence d'erreurs dans les journaux des pods d'agents Cilium. L'agent Cilium doit être connecté au point de terminaison de l'API EKS Kubernetes pour démarrer. Le démarrage de l'agent Cilium échouera si cette connectivité n'est pas correctement configurée. Dans ce cas, vous verrez des messages de journal similaires aux suivants dans les journaux du module de l'agent Cilium.

msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout"

L'agent Cilium s'exécute sur le réseau hôte. Votre cluster EKS doit être configuré RemoteNodeNetwork pour la connectivité Cilium. Vérifiez que vous disposez d'un groupe de sécurité supplémentaire pour votre cluster EKS avec une règle entrante pour vousRemoteNodeNetwork, que vous avez des itinéraires dans votre VPC pour vous et que RemodeNodeNetwork votre réseau sur site est correctement configuré pour permettre la connectivité au plan de contrôle EKS.

Si l'opérateur Cilium est en cours d'exécution et que certains de vos agents Cilium sont en cours d'exécution, mais pas tous, vérifiez que vous disposez d'un pod disponible IPs à allouer pour tous les nœuds de votre cluster. Vous configurez la taille de votre pod allouable CIDRs lorsque vous utilisez le pool de clusters IPAM clusterPoolIPv4PodCIDRList dans votre configuration Cilium. La taille CIDR par nœud est configurée selon le clusterPoolIPv4MaskSize paramètre de votre configuration Cilium. Voir Extension du pool de clusters dans la documentation de Cilium pour plus d'informations.

Cilium BGP ne fonctionne pas

Si vous utilisez le plan de contrôle BGP de Cilium pour publier les adresses de vos pods ou de vos services sur votre réseau local, vous pouvez utiliser les commandes Cilium CLI suivantes pour vérifier si BGP annonce les itinéraires vers vos ressources. Pour connaître les étapes d'installation de la CLI Cilium, consultez la section Installer la CLI Cilium dans la documentation de Cilium.

Si BGP fonctionne correctement, vous devez indiquer l'état de session de vos nœuds hybrides established dans la sortie. Vous devrez peut-être travailler avec votre équipe réseau pour identifier les valeurs correctes pour l'AS local, l'AS homologue et l'adresse homologue de votre environnement.

cilium bgp peers

cilium bgp routes

Si vous utilisez Cilium BGP pour faire IPs de la publicité pour des Services par typeLoadBalancer, vous devez avoir la même étiquette sur votre produit CiliumLoadBalancerIPPool et sur le Service, qui doit être utilisée dans le sélecteur de votre. CiliumBGPAdvertisement Un exemple est illustré ci-dessous. Notez que si vous utilisez Cilium BGP pour promouvoir les services avec type LoadBalancer, les IPs routes BGP peuvent être perturbées lors du redémarrage de l'agent Cilium. Pour plus d'informations, consultez la section Scénarios de défaillance dans la documentation de Cilium.

Service

kind: Service
apiVersion: v1
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  ports:
  - port: 3000
    targetPort: http-server
  selector:
    app: guestbook
  type: LoadBalancer

CiliumLoadBalancerIPPool

apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: guestbook-pool
  labels:
    app: guestbook
spec:
  blocks:
  - cidr: <CIDR to advertise>
  serviceSelector:
    matchExpressions:
      - { key: app, operator: In, values: [ guestbook ] }

CiliumBGPAdvertisement

apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
  name: bgp-advertisements-guestbook
  labels:
    advertise: bgp
spec:
  advertisements:
    - advertisementType: "Service"
      service:
        addresses:
          - ExternalIP
          - LoadBalancerIP
      selector:
        matchExpressions:
          - { key: app, operator: In, values: [ guestbook ] }

Résolution des problèmes liés à Calico

Si vous rencontrez des problèmes pour exécuter Calico sur des nœuds hybrides, consultez les étapes de résolution des problèmes décrites dans la documentation de Calico. Les sections ci-dessous abordent les problèmes qui peuvent être propres au déploiement de Calico sur des nœuds hybrides.

Le tableau ci-dessous récapitule les composants Calico et indique s'ils s'exécutent par défaut sur le réseau de nœuds ou de pods. Si vous avez configuré Calico pour utiliser le NAT pour le trafic de pods sortant, votre réseau local doit être configuré pour acheminer le trafic vers le CIDR de votre nœud local et vos tables de routage VPC doivent être configurées avec une route pour le CIDR de votre nœud local avec votre passerelle de transit (TGW) ou votre passerelle privée virtuelle (VGW) comme cible. Si vous ne configurez pas Calico pour utiliser le NAT pour le trafic de pod sortant, votre réseau local doit être configuré pour acheminer le trafic vers le CIDR de votre pod local et vos tables de routage VPC doivent être configurées avec une route pour le CIDR de votre pod local avec votre passerelle de transit (TGW) ou votre passerelle privée virtuelle (VGW) comme cible.

Les ressources Calico sont planifiées ou exécutées sur des nœuds cordonés

Les ressources Calico qui ne s'exécutent pas en tant que telles DaemonSet sont soumises à des tolérances flexibles par défaut qui leur permettent d'être planifiées sur des nœuds cordonés qui ne sont pas prêts à être planifiés ou à exécuter des pods. Vous pouvez renforcer les tolérances pour les ressources autres que DaemonSet Calico en modifiant l'installation de votre opérateur pour inclure les éléments suivants.

installation:
  ...
  controlPlaneTolerations:
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  calicoKubeControllersDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300
  typhaDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300

Résolution des problèmes d'identification

Pour les activations hybrides AWS SSM et pour AWS IAM Roles Anywhere, vous pouvez vérifier que les informations d'identification du rôle Hybrid Nodes IAM sont correctement configurées sur vos nœuds hybrides en exécutant la commande suivante depuis vos nœuds hybrides. Vérifiez que le nom du nœud et le nom du rôle IAM des nœuds hybrides correspondent à vos attentes.

sudo aws sts get-caller-identity

{
    "UserId": "ABCDEFGHIJKLM12345678910:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws:sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}

AWS Résolution des problèmes liés à Systems Manager (SSM)

Si vous utilisez des activations hybrides AWS SSM pour les informations d'identification de vos nœuds hybrides, tenez compte des répertoires et artefacts SSM suivants qui sont installés sur vos nœuds hybrides par nodeadm. Pour plus d'informations sur l'agent SSM, consultez la section Utilisation de l'agent SSM dans le Guide de l'utilisateur de AWS Systems Manager.

Redémarrage de l'agent SSM

Certains problèmes peuvent être résolus en redémarrant l'agent SSM. Vous pouvez utiliser les commandes ci-dessous pour le redémarrer.

AL2023 et autres systèmes d'exploitation

systemctl restart amazon-ssm-agent

Ubuntu

systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent

Vérifiez la connectivité aux points de terminaison SSM

Vérifiez que vous pouvez vous connecter aux points de terminaison SSM à partir de vos nœuds hybrides. Pour obtenir la liste des points de terminaison SSM, consultez la section Points de terminaison AWS et quotas de Systems Manager. Remplacez us-west-2 la commande ci-dessous par la AWS région pour votre activation hybride AWS SSM.

ping ssm.us-west-2.amazonaws.com

Afficher l'état de connexion des instances SSM enregistrées

Vous pouvez vérifier l'état de connexion des instances enregistrées avec les activations hybrides SSM à l'aide de la commande AWS CLI suivante. Remplacez l'ID de machine par l'ID de machine de votre instance.

aws ssm get-connection-status --target mi-012345678abcdefgh
      

Incompatibilité de la somme de contrôle de la CLI de configuration SSM

Lors de l'exécution, nodeadm install si vous constatez un problème lié à l'ssm-setup-cliincompatibilité de la somme de contrôle, vous devez vérifier qu'aucune ancienne installation SSM n'existe sur votre hôte. S'il existe d'anciennes installations SSM sur votre hôte, supprimez-les et réexécutez-les nodeadm install pour résoudre le problème.

Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.

SSM InvalidActivation

Si vous constatez une erreur lors de l'enregistrement de votre instance auprès de AWS SSM, confirmez que le regionactivationCode, et activationId dans votre nom nodeConfig.yaml sont corrects. La AWS région de votre cluster EKS doit correspondre à la région de votre activation hybride SSM. Si ces valeurs sont mal configurées, une erreur similaire à la suivante peut s'afficher.

ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation

SSM ExpiredTokenException : le jeton de sécurité inclus dans la demande a expiré

Si l'agent SSM n'est pas en mesure d'actualiser les informations d'identification, unExpiredTokenException. Dans ce scénario, si vous parvenez à vous connecter aux points de terminaison SSM à partir de vos nœuds hybrides, vous devrez peut-être redémarrer l'agent SSM pour forcer l'actualisation des informations d'identification.

"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"

Erreur SSM lors de l'exécution de la commande register machine

Si une erreur s'affiche lors de l'enregistrement de la machine auprès de SSM, vous devrez peut-être l'exécuter nodeadm install à nouveau pour vous assurer que toutes les dépendances SSM sont correctement installées.

"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"

SSM ActivationExpired

Lors de l'exécutionnodeadm init, si vous constatez une erreur lors de l'enregistrement de l'instance auprès de SSM en raison d'une activation expirée, vous devez créer une nouvelle activation hybride SSM, la mettre à jour nodeConfig.yaml avec le activationCode et activationId de votre nouvelle activation hybride SSM, puis la réexécuter. nodeadm init

"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"

ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired

SSM n'a pas réussi à actualiser les informations d'identification mises en cache

Si vous ne parvenez pas à actualiser les informations d'identification mises en cache, le /root/.aws/credentials fichier a peut-être été supprimé sur votre hôte. Vérifiez d'abord votre activation hybride SSM, assurez-vous qu'elle est active et que vos nœuds hybrides sont correctement configurés pour utiliser l'activation. Vérifiez les journaux de l'agent SSM /var/log/amazon/ssm et réexécutez la commande nodeadm init une fois que vous avez résolu le problème côté SSM.

"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"

Nettoyez SSM

Pour supprimer l'agent SSM de votre hôte, vous pouvez exécuter les commandes suivantes.

dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey

AWS Résolution des problèmes liés à IAM Roles Anywhere

Si vous utilisez AWS IAM Roles Anywhere pour les informations d'identification de vos nœuds hybrides, tenez compte des répertoires et artefacts suivants qui sont installés sur vos nœuds hybrides par nodeadm. Pour plus d'informations sur la résolution des problèmes liés à IAM Roles Anywhere, consultez la section Résolution des problèmes d'identité et d'accès à AWS IAM Roles Anywhere dans le guide de l'utilisateur d' AWS IAM Roles Anywhere.

IAM Roles Anywhere n'a pas pu actualiser les informations d'identification mises en cache

Si vous ne parvenez pas à actualiser les informations d'identification mises en cache, passez en revue le contenu d'IAM Roles Anywhere /etc/aws/hybrid/config et confirmez qu'il a été correctement configuré dans votre nodeadm configuration. Confirmez que cela /etc/iam/pki existe. Chaque nœud doit disposer d'un certificat et d'une clé uniques. Par défaut, lorsque vous utilisez IAM Roles Anywhere comme fournisseur d'informations d'identification, utilisez cette option nodeadm /etc/iam/pki/server.pem pour l'emplacement et le nom du certificat, ainsi que /etc/iam/pki/server.key pour la clé privée. Vous devrez peut-être créer les répertoires avant de placer les certificats et les clés dans les répertoires avecsudo mkdir -p /etc/iam/pki. Vous pouvez vérifier le contenu de votre certificat à l'aide de la commande ci-dessous.

openssl x509 -text -noout -in server.pem

open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}

IAM Roles Anywhere n'est pas autorisé à exécuter sts:AssumeRole

Dans les kubelet journaux, si vous constatez un problème de refus d'accès lié à l'sts:AssumeRoleopération lorsque vous utilisez IAM Roles Anywhere, vérifiez la politique de confiance de votre rôle IAM Hybrid Nodes pour confirmer que le principal du service IAM Roles Anywhere est autorisé à assumer le rôle IAM Hybrid Nodes. Vérifiez également que l'ARN d'ancrage de confiance est correctement configuré dans la politique de confiance de votre rôle IAM Hybrid Nodes et que votre rôle IAM Hybrid Nodes est ajouté à votre profil IAM Roles Anywhere.

could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...

IAM Roles Anywhere n'est pas autorisé à définir roleSessionName

Dans les kubelet journaux, si vous constatez un problème de refus d'accès lié à la définition deroleSessionName, confirmez que vous avez défini la valeur true acceptRoleSessionName pour votre profil IAM Roles Anywhere.

AccessDeniedException: Not authorized to set roleSessionName

Dépannage du système d'exploitation

RHEL

Échec de l'enregistrement du gestionnaire d'autorisations ou d'abonnements

Si vous exécutez nodeadm install et que vous ne parvenez pas à installer les dépendances des nœuds hybrides en raison de problèmes d'enregistrement des droits, assurez-vous d'avoir correctement défini votre nom d'utilisateur et votre mot de passe Red Hat sur votre hôte.

This system is not registered with an entitlement server

GLIBC introuvable

Si vous utilisez Ubuntu pour votre système d'exploitation et IAM Roles Anywhere pour votre fournisseur d'identifiants avec des nœuds hybrides et que vous constatez qu'un problème avec la GLIBC est introuvable, vous pouvez installer cette dépendance manuellement pour résoudre le problème.

GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)

Exécutez les commandes suivantes pour installer la dépendance :

ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source