Aidez à améliorer cette page

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

Dépannage des nœuds hybrides

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

Dépannage des nœuds avec nodeadm debug. Vous pouvez exécuter la commande nodeadm debug à partir de vos nœuds hybrides pour vérifier que les exigences en matière de réseau et d’informations d’identification sont respectées. Pour plus d’informations sur la commande nodeadm debug, voir Référence des nœuds hybrides nodeadm.

Détectez les problèmes liés à vos nœuds hybrides grâce aux informations sur les clusters Les informations sur les clusters Amazon EKS comprennent des vérifications qui détectent les problèmes courants liés à la configuration des nœuds hybrides EKS dans votre cluster. Vous pouvez consulter les résultats de toutes les vérifications d’informations à partir de AWS Management Console, la CLI AWS et des SDK AWS. Pour plus d’informations sur les informations relatives aux clusters, consultez Préparation aux mises à niveau des versions Kubernetes et résolution des erreurs de configuration grâce aux informations sur les clusters.

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

Les rubriques de dépannage suivantes concernent l’installation des dépendances des nœuds hybrides sur les hôtes à l’aide de la commande nodeadm install.

nodeadm échec de la commande must run as root

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

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

Impossible de se connecter aux dépendances

La commande nodeadm install installe les dépendances requises pour les nœuds hybrides. Les dépendances des nœuds hybrides comprennent les composants containerd, kubelet, kubectl, et AWS SSM ou Rôles Anywhere IAM AWS. 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 pouvoir accéder, consultez Préparer la mise en réseau pour les nœuds hybrides. Si vous n’y avez pas accès, vous verrez des erreurs similaires à celles-ci dans la sortie nodeadm install.

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

Impossible de mettre à jour le gestionnaire de paquets

La commande nodeadm install exécute apt update, yum update ou dnf update avant l’installation des dépendances des nœuds hybrides. Si cette étape échoue, vous pourriez voir apparaître des erreurs similaires à celles ci-dessous. Pour remédier à cette situation, vous pouvez exécuter apt update, yum update ou dnf update avant l’exécution de nodeadm install ou essayer de réexécuter nodeadm 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écution de nodeadm install, si vous constatez des problèmes à différentes étapes du processus d’installation avec des erreurs indiquant un délai d’attente ou une limite de contexte dépassée, il se peut que votre connexion soit trop lente et empêche l’installation des dépendances des nœuds hybrides avant l’expiration des délais d’attente. Pour contourner ces problèmes, vous pouvez essayer d’utiliser la balise --timeout dans nodeadm afin de prolonger la durée des délais d’attente pour le 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 commande nodeadm init.

Erreurs de fonctionnement ou schéma non pris en charge

Lors de l’exécution nodeadm init, si vous voyez des erreurs liées à operation error ou unsupported scheme, vérifiez votre nodeConfig.yaml pour vous assurer qu’il est correctement formaté et transmis à nodeadm. Pour plus d’informations sur le format et les options disponibles pour nodeConfig.yaml, consultez Référence des nœuds hybrides nodeadm.

"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écution nodeadm init, nodeadm tente de recueillir des informations sur votre cluster EKS en appelant Describe Cluster. Si votre rôle IAM des nœuds hybrides ne dispose pas des autorisations nécessaires pour l’action eks:DescribeCluster. Pour plus d’informations sur les autorisations requises pour le rôle IAM des nœuds hybrides, consultez Préparer les informations d’identification pour les nœuds hybrides.

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

L’adresse IP du nœud ne figure pas dans le réseau de nœuds distants CIDR

Lors de l’exécution de nodeadm init, vous pouvez rencontrer une erreur si l’adresse IP du nœud ne se trouve pas dans les CIDR du réseau du nœud distant spécifié. L’erreur ressemblera à l’exemple suivant :

node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]

Cet exemple montre un nœud avec l’adresse IP 10.18.0.1 qui tente de rejoindre un cluster avec les CIDR de réseau distant 10.0.0.0/16 et 192.168.0.0/16. L’erreur se produit car 10.18.0.1 ne se situe dans aucune des plages.

Vérifiez que vous avez correctement configuré votre adresse IP RemoteNodeNetworks pour inclure toutes les adresses IP des nœuds. Pour plus d’informations sur la configuration réseau, voir Préparer la mise en réseau pour les nœuds hybrides.

aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks

Si l’adresse IP de votre nœud ne correspond toujours pas à ce que vous attendiez, vérifiez les points suivants :

ip addr show

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

Si vous avez exécuté nodeadm init et qu’il s’est terminé, mais que vos nœuds hybrides n’apparaissent pas dans votre cluster, il se peut qu’il y ait des problèmes avec la connexion réseau entre vos nœuds hybrides et le plan de contrôle EKS, que vous n’ayez pas configuré les autorisations requises pour le groupe de sécurité ou que vous n’ayez pas effectué le mappage requis entre le rôle IAM de vos nœuds hybrides et le contrôle d’accès basé sur les rôles (RBAC) de Kubernetes. Vous pouvez lancer le processus de débogage en vérifiant l’état de kubelet et des journaux 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 dans Préparer la mise en 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, vous pouvez voir des journaux similaires à ceux ci-dessous. Notez que la principale différence dans les messages du journal ci-dessous réside dans l’erreur Unauthorized. Cela indique que le nœud n’a pas pu exécuter 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 éléments 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 et Préparation de l’accès au cluster pour les nœuds hybrides.

Nœuds hybrides enregistrés dans le cluster EKS mais affichant l’état Not Ready

Si vos nœuds hybrides se sont correctement enregistrés auprès de votre cluster EKS, mais qu’ils affichent l’état Not Ready, la première chose à vérifier est l’état de votre interface réseau de conteneur (CNI). Si vous n’avez pas installé de CNI, vos nœuds hybrides devraient avoir le statut Not Ready. Une fois qu’un CNI est installé et fonctionne correctement, les nœuds sont mis à jour vers le statut Ready. Si vous avez essayé d’installer un CNI mais qu’il ne fonctionne pas correctement, consultez Dépannage des nœuds hybrides CNI sur cette page.

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

Après avoir connecté des nœuds hybrides à votre cluster EKS, si vous constatez que des CSR sont en attente pour vos nœuds hybrides, cela signifie que ceux-ci ne répondent pas aux exigences requises pour une approbation automatique. Les CSR pour les nœuds hybrides sont automatiquement approuvées et émises si elles ont été créées par un nœud avec étiquette eks.amazonaws.com/compute-type: hybrid et si elles comportent les noms alternatifs suivants (SAN) : au moins un SAN DNS égal au nom du nœud et les SAN IP appartenant aux CIDR du réseau du nœud distant.

Le profil hybride existe déjà

Si vous avez modifié votre configuration nodeadm et que vous essayez de réenregistrer le nœud avec la nouvelle configuration, vous pouvez obtenir une erreur indiquant que le profil hybride existe déjà, mais que son contenu a été modifié. Au lieu d’exécuter nodeadm init entre les changements de configuration, exécutez nodeadm uninstall suivi d’un nodeadm install et nodeadm init. Cela garantit un nettoyage correct lors des changements 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écution nodeadm init, si vous constatez une erreur dans les journaux kubelet indiquant des échecs de connexion au serveur API EKS Kubernetes en raison de la présence de no such host, vous devrez peut-être modifier votre entrée DNS pour le point de terminaison API EKS Kubernetes dans votre réseau sur site ou au niveau de l’hôte. Consultez la section Transfert des requêtes DNS entrantes vers votre VPC dans la documentation Route53 AWS.

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 afficher 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, consultez Affichage des ressources Kubernetes dans la AWS Management Console.

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

Si vos nœuds hybrides enregistrés dans votre cluster EKS avaient le statut Ready, puis sont passés au statut Not Ready, plusieurs problèmes peuvent avoir contribué à ce statut non fonctionnel, par exemple un manque de ressources CPU, de mémoire ou d’espace disque disponible, ou une déconnexion du nœud du plan de contrôle EKS. Vous pouvez suivre les étapes ci-dessous pour dépanner vos nœuds. Si vous ne parvenez pas à résoudre le problème, contactez le service d’assistance AWS.

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

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, vous rencontrez peut-être des problèmes de réseau qui bloquent la communication avec les pods. 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 pods distant et disposer de routes pour votre CIDR de pod sur site dans votre table de routage 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 sur site. Pour plus d’informations sur les exigences réseau pour les nœuds hybrides, voir Préparer la mise en 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 acheminer correctement le trafic vers vos pods. Pour plus d’informations sur les conditions requises pour exécuter des webhooks sur des nœuds hybrides, consultez Configurer les webhooks pour les nœuds hybrides.

Un message de journal de pod courant pour ce scénario est présenté ci-dessous, où l’adresse IP correspond à l’adresse IP du cluster pour le service Kubernetes.

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

les commandes kubectl logs ou kubectl exec ne fonctionnent pas

Si les commandes kubectl logs ou kubectl exec expirent alors que d’autres commandes kubectl aboutissent, le problème est probablement lié à la configuration du réseau distant. Ces commandes se connectent via le cluster au point de terminaison kubelet sur le nœud. Pour plus d’informations, consultez Point de terminaison kubelet.

Vérifiez que les adresses IP de vos nœuds et pods se trouvent dans les plages CIDR du réseau de nœuds distants et du réseau de pods distants configurées pour votre cluster. Utilisez les commandes ci-dessous pour examiner les attributions d’adresses IP.

kubectl get nodes -o wide

kubectl get pods -A -o wide

Comparez ces adresses IP avec les CIDR de votre réseau distant configuré afin de garantir un routage correct. Pour les exigences de configuration réseau, voir Préparer la mise en réseau pour les nœuds hybrides.

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 s’exécutant sur les 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 le statut Ready, 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. De plus, les définitions de ressources personnalisées (CRD) pour ces CNI peuvent encore être présentes sur votre cluster depuis une ancienne installation. Pour plus d’informations, consultez les sections Supprimer Cilium et Supprimer Calico de Configurer CNI pour les nœuds hybrides.

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

Si vous rencontrez des problèmes lors de l’exécution de Cilium sur des nœuds hybrides, consultez les étapes de dépannage dans la documentation Cilium. Les sections ci-dessous traitent des 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 les journaux des pods de l’agent Cilium pour détecter d’éventuelles erreurs. L’agent Cilium nécessite une connexion au point de terminaison 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 pod 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é avec 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 votre RemoteNodeNetwork, que vous disposez de routes dans votre VPC pour votre RemoteNodeNetwork, et que 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 fonctionnent, mais pas tous, vérifiez que vous disposez d’adresses IP de pod disponibles à attribuer à tous les nœuds de votre cluster. Vous configurez la taille de vos CIDR de pod allouables lorsque vous utilisez l’IPAM de pool de cluster avec clusterPoolIPv4PodCIDRList dans votre configuration Cilium. La taille CIDR par nœud est configurée à l’aide du paramètre clusterPoolIPv4MaskSize dans 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 Cilium BGP pour annoncer les adresses de vos pods ou services à votre réseau sur site, vous pouvez utiliser les commandes CLI Cilium suivantes pour vérifier si BGP annonce les routes 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 collaborer avec votre équipe réseau afin d’identifier les valeurs correctes pour l’AS local, l’AS pair et l’adresse pair de votre environnement.

cilium bgp peers

cilium bgp routes

Si vous utilisez Cilium BGP pour annoncer les adresses IP des services de type LoadBalancer, vous devez avoir la même étiquette sur votre CiliumLoadBalancerIPPool et votre service, qui doit être utilisée dans le sélecteur de votre CiliumBGPAdvertisement. Un exemple est illustré ci-dessous. Remarque : Si vous utilisez Cilium BGP pour annoncer les adresses IP des services de type LoadBalancer, les 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 Cilium.

Service

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

Pool équilibreur de charge IP Cilium

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 ] }

Publicité Cilium BGP

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 lors de l’exécution de Calico sur des nœuds hybrides, consultez les étapes de dépannage dans la documentation Calico. Les sections ci-dessous traitent des 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 du nœud ou du pod. Si vous avez configuré Calico pour utiliser NAT pour le trafic sortant des pods, votre réseau sur site doit être configuré pour acheminer le trafic vers votre CIDR de nœud sur site et vos tables de routage VPC doivent être configurées avec une route pour votre CIDR de nœud sur site avec votre passerelle de transit (TGW) ou votre passerelle privée virtuelle (VGW) comme cible. Si vous ne configurez pas Calico pour utiliser NAT pour le trafic sortant des pods, votre réseau sur site doit être configuré pour acheminer le trafic vers votre CIDR de pod sur site et vos tables de routage VPC doivent être configurées avec une route pour votre CIDR de pod sur site avec votre passerelle de transit (TGW) ou votre passerelle privée virtuelle (VGW) comme cible.

Les ressources Calico sont planifiées ou en cours d’exécution sur des nœuds cordonnés

Les ressources Calico qui ne s’exécutent pas en tant que DaemonSet disposent par défaut de tolérances flexibles qui leur permettent d’être planifiées sur des nœuds isolés qui ne sont pas prêts pour la planification ou l’exécution de pods. Vous pouvez resserrer les tolérances pour les ressources Calico non DaemonSet en modifiant votre installation d’opérateur afin d’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

Dépannage des informations d’identification

Pour les activations hybrides AWS SSM et Rôles Anywhere IAM AWS, vous pouvez vérifier que les informations d’identification pour le rôle IAM des nœuds hybrides sont correctement configurées sur vos nœuds hybrides en exécutant la commande suivante à partir de 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>"
}

Dépannage du gestionnaire de systèmes (SSM) AWS

Si vous utilisez des activations hybrides SSM AWS 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 Systems Manager AWS.

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 et quotas Systems Manager AWS. Remplacez la commande us-west-2 ci-dessous par la région AWS pour votre activation hybride SSMAWS.

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 CLI AWS 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

Si vous constatez un problème de discordance de somme de contrôle ssm-setup-cli lors de l’exécution de nodeadm install, vous devez vérifier qu’il n’existe pas d’anciennes installations SSM sur votre hôte. Si votre hôte contient d’anciennes installations SSM, supprimez-les et relancez 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 SSM AWS, vérifiez que region, activationCode et activationId dans votre nodeConfig.yaml sont corrects. La région AWS de votre cluster EKS doit correspondre à la région de votre activation hybride SSM. Si ces valeurs sont mal configurées, vous pourriez voir une erreur similaire à celle-ci.

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, vous pouvez voir apparaître un ExpiredTokenException. 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 vous constatez une erreur lors de l’enregistrement de la machine auprès de SSM, vous devrez peut-être relancer nodeadm install afin de 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écution de nodeadm 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, mettre à jour votre nodeConfig.yaml avec le activationCode et le activationId de votre nouvelle activation hybride SSM, puis relancer 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 fichier /root/.aws/credentials a peut-être été supprimé sur votre hôte. Vérifiez d’abord l’activation hybride SSM et 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

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

Si vous utilisez Rôles Anywhere IAM AWS pour les informations d’identification de vos nœuds hybrides, prenez connaissance des répertoires et artefacts suivants qui sont installés sur vos nœuds hybrides par nodeadm. Pour plus d’informations sur le dépannage de Rôles Anywhere IAM, consultez la section Dépannage des identités et des accès Rôles Anywhere IAM AWS dans le Guide de l’utilisateur Rôles Anywhere IAM AWS.

Rôles Anywhere IAM n’a pas pu actualiser les informations d’identification mises en cache

Si vous constatez un échec de l’actualisation des informations d’identification mises en cache, vérifiez le contenu de /etc/aws/hybrid/config et assurez-vous que Rôles Anywhere IAM a été correctement configuré dans votre configuration nodeadm. Confirmez que /etc/iam/pki existe. Chaque nœud doit disposer d’un certificat et d’une clé uniques. Par défaut, lorsque vous utilisez Rôles Anywhere IAM comme fournisseur d’informations d’identification, nodeadm utilise /etc/iam/pki/server.pem pour l’emplacement et le nom du certificat, et /etc/iam/pki/server.key pour la clé privée. Vous devrez peut-être créer les répertoires avant d’y placer les certificats et les clés avec sudo 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"}

Rôles Anywhere IAM n’a pas autorisé à exécuter sts:AssumeRole

Dans les journaux kubelet, si vous constatez un problème d’accès refusé pour l’opération sts:AssumeRole lors de l’utilisation de Rôles Anywhere IAM, vérifiez la politique de confiance de votre rôle IAM des nœuds hybrides afin de confirmer que le principal de service Rôles Anywhere IAM est autorisé à assumer le rôle IAM des nœuds hybrides. Vérifiez également que l’ARN de l’ancre d’approbation est correctement configurée dans votre stratégie de confiance du rôle IAM des nœuds hybrides et que votre rôle IAM des nœuds hybrides est ajouté à votre profil Rôles Anywhere IAM.

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

Rôles Anywhere IAM n’est pas autorisé à définir roleSessionName

Dans les journaux kubelet, si vous constatez un problème d’accès refusé pour la configuration du paramètre roleSessionName, vérifiez que vous avez défini la valeur acceptRoleSessionName sur true pour votre profil Rôles Anywhere IAM.

AccessDeniedException: Not authorized to set roleSessionName

Résolution des problèmes de système d’exploitation

RHEL

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

Lorsque vous exécutez nodeadm install, si vous rencontrez un problème lors de l’installation des dépendances des nœuds hybrides en raison d’un problème 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

Ubuntu

GLIBC introuvable

Si vous utilisez Ubuntu comme système d’exploitation et Rôles Anywhere IAM comme fournisseur d’informations d’identification avec des nœuds hybrides et que vous rencontrez un problème lié à l’absence de GLIBC, 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

Bottlerocket

Si vous avez activé le conteneur d’administration Bottlerocket, vous pouvez y accéder via SSH pour effectuer un débogage avancé et un dépannage avec des privilèges élevés. Les sections suivantes contiennent des commandes qui doivent être exécutées dans le contexte de l’hôte Bottlerocket. Une fois que vous êtes dans le conteneur d’administration, vous pouvez exécuter sheltie pour obtenir un shell root complet dans l’hôte Bottlerocket.

sheltie

Vous pouvez également exécuter les commandes des sections suivantes à partir du shell du conteneur admin en préfixant chaque commande avec sudo chroot /.bottlerocket/rootfs.

sudo chroot /.bottlerocket/rootfs <command>

Utilisation de logdog pour la collecte de logs

Bottlerocket fournit l’utilitaire logdog permettant de collecter efficacement les journaux et les informations système à des fins de dépannage.

logdog

L’utilitaire logdog rassemble les journaux provenant de divers emplacements sur un hôte Bottlerocket et les combine dans un fichier tar. Par défaut, l’archive tar sera créée à l’emplacement /var/log/support/bottlerocket-logs.tar.gz et sera accessible depuis les conteneurs hôtes à l’emplacement /.bottlerocket/support/bottlerocket-logs.tar.gz.

Accès aux journaux du système avec journalctl

Vous pouvez vérifier l’état des différents services système tels que kubelet, containerd, etc., et consulter leurs journaux à l’aide des commandes suivantes. La balise -f suivra les bûches en temps réel.

Pour vérifier l’état du service kubelet et récupérer les journaux kubelet, vous pouvez exécuter :

systemctl status kubelet
journalctl -u kubelet -f

Pour vérifier l’état du service containerd et récupérer les journaux containerd de l’instance orchestrée, vous pouvez exécuter :

systemctl status containerd
journalctl -u containerd -f

Pour vérifier l’état du service host-containerd et récupérer les journaux containerd de l’instance hôte, vous pouvez exécuter :

systemctl status host-containerd
journalctl -u host-containerd -f

Pour récupérer les journaux des conteneurs bootstrap et des conteneurs hôtes, vous pouvez exécuter :

journalctl _COMM=host-ctr -f