View a markdown version of this page

Résolution des problèmes de passerelle Amazon EKS Hybrid Nodes - Amazon EKS

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 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.

Résolution des problèmes de passerelle Amazon EKS Hybrid Nodes

Cette page fournit des conseils pour diagnostiquer et résoudre les problèmes courants liés à la passerelle Amazon EKS Hybrid Nodes. Chaque section décrit un symptôme, les causes possibles, les étapes du diagnostic et les solutions. Pour plus de détails opérationnels, consultezOpérations de la passerelle Amazon EKS Hybrid Nodes.

Pods sur des nœuds hybrides inaccessibles depuis un VPC

Les pods exécutés sur des nœuds hybrides ne sont pas accessibles à partir des ressources du VPC, telles que les instances EC2, les équilibreurs de charge ou le plan de contrôle Kubernetes.

Causes possibles :

  • Les entrées de la table de routage VPC sont manquantes ou pointent vers le mauvais ENI.

  • Le module Gateway Leader n'est pas en cours d'exécution ou sa configuration n'est pas terminée.

  • Cilium VTEP n'est ni activé ni configuré sur les nœuds hybrides.

  • Source/destination la vérification est activée sur l'instance EC2 de la passerelle.

Étapes du diagnostic :

  1. Vérifiez les entrées de la table de routage VPC. Vérifiez que des routes existent pour les CIDR de votre pod hybride et pointez vers l'ENI principal de l'instance de passerelle active :

    aws ec2 describe-route-tables \ --route-table-ids ROUTE_TABLE_ID \ --query "RouteTables[].Routes[?DestinationCidrBlock=='POD_CIDR']"

    Si des itinéraires sont manquants, vérifiez les journaux de la passerelle pour détecter les erreurs de table de routage. Si les itinéraires pointent vers la mauvaise ENI, le basculement n'a peut-être pas été effectué correctement.

  2. Vérifiez l'état du module de passerelle et l'élection du leader. Vérifiez que deux modules de passerelle sont en cours d'exécution et que l'un d'eux détient le bail principal :

    kubectl get pods -n eks-hybrid-nodes-gateway kubectl get lease -n eks-hybrid-nodes-gateway

    Si aucun pod n'est titulaire du bail, consultezProblèmes liés à l'élection des dirigeants.

  3. Vérifiez la configuration de Cilium VTEP sur les nœuds hybrides. Vérifiez que la CiliumVTEPConfig ressource existe et qu'elle contient l'adresse IP du nœud leader :

    kubectl get ciliumvtepconfig hybrid-gateway -o yaml

    Elle spec.endpoints[0].tunnelEndpoint doit correspondre à l'adresse IP du nœud de passerelle leader. Si la ressource est manquante ou possède une adresse IP obsolète, il est possible que la configuration du leader ne soit pas terminée sur la passerelle.

  4. Chèque, source/destination chèque. Vérifiez que source/destination la vérification est désactivée sur les instances EC2 de la passerelle :

    aws ec2 describe-instance-attribute \ --instance-id GATEWAY_INSTANCE_ID \ --attribute sourceDestCheck

    Si sourceDestCheck c'est le castrue, désactivez-le. Consultez Démarrez avec la passerelle EKS Hybrid Nodes.

Les appels Webhook vers des nœuds hybrides échouent

Le serveur d'API Kubernetes ne peut pas atteindre les points de terminaison des webhooks exécutés sur des nœuds hybrides. Les demandes d'admission au Webhook expirent ou renvoient des erreurs de connexion.

Causes possibles :

  • La passerelle n'achemine pas le trafic depuis le plan de contrôle vers les pods hybrides.

  • La CiliumVTEPConfig ressource est manquante ou possède une adresse IP de point de terminaison obsolète.

Étapes du diagnostic :

  1. Vérifiez que le plan de contrôle peut atteindre l'adresse IP du nœud de passerelle. Le plan de contrôle envoie le trafic à la table de routage VPC, qui le transmet à l'ENI de la passerelle. Vérifiez que les entrées de la table de routage VPC sont correctes en suivant les étapes décrites dansPods sur des nœuds hybrides inaccessibles depuis un VPC.

  2. Vérifiez la ressource CiliumVTEPConfig. Vérifiez que la ressource existe et qu'elle tunnelEndpoint correspond à l'adresse IP du nœud du leader actuel :

    kubectl get ciliumvtepconfig hybrid-gateway -o yaml

    Si le point de terminaison du tunnel est obsolète (pointe vers un leader précédent), la passerelle n'a peut-être pas terminé la séquence de configuration du leader. Vérifiez les journaux de la passerelle pour détecter les erreurs lors de la CiliumVTEPConfig mise en service.

Les mises à jour de la table de routage VPC échouent

Les journaux de passerelle indiquent des erreurs liées aux opérations de la table de routage VPC, et les routes pour les CIDR des pods hybrides ne sont ni créées ni mises à jour.

Causes possibles :

  • Le rôle IAM de la passerelle ne dispose pas des autorisations EC2 requises.

  • Les ID de table de routage dans la configuration sont incorrects ou les tables de routage n'existent pas.

  • La passerelle ne peut pas atteindre le point de terminaison de l'API EC2.

Étapes du diagnostic :

  1. Vérifiez les autorisations IAM. La passerelle nécessite les actions IAM suivantes :

    • ec2:DescribeRouteTables

    • ec2:CreateRoute

    • ec2:ReplaceRoute

    • ec2:DescribeInstances

      Vérifiez le rôle IAM associé au profil d'instance du nœud de passerelle ou à la configuration de l'identité du pod.

  2. Vérifiez les ID des tables de routage dans la configuration. Vérifiez que la variable d'ROUTE_TABLE_IDSenvironnement contient des ID de table de routage valides lors du déploiement de la passerelle :

    kubectl get deployment eks-hybrid-nodes-gateway -n eks-hybrid-nodes-gateway -o jsonpath='{.spec.template.spec.containers[0].env}' | jq .

    Vérifiez que les ID de table de routage existent dans votre VPC :

    aws ec2 describe-route-tables --route-table-ids ROUTE_TABLE_ID
  3. Vérifiez les journaux de passerelle pour détecter les erreurs de table de routage. Recherchez les messages d'erreur liés aux opérations de la table de routage :

    kubectl logs -n eks-hybrid-nodes-gateway LEADER_POD | grep -i "route table"

    Les messages d'erreur courants sont les suivants :

    • Failed to verify route table access— La passerelle ne peut pas décrire la table de routage. Vérifiez les autorisations IAM et les identifiants des tables de routage.

    • Failed to update route tables— La passerelle ne peut pas créer ni remplacer d'itinéraires. Vérifiez les autorisations IAM.

    • failed to access route table— L'ID de la table de routage est peut-être incorrect ou le rôle IAM est absent. ec2:DescribeRouteTables

Les modules Gateway ne démarrent pas ou ne sont pas sains

Les pods Gateway sont dans CrashLoopBackOffError, ou sont en Pending état, ou le terminal d'intégrité renvoie une erreur.

Causes possibles :

  • Les variables d'environnement requises (VPC_CIDRPOD_CIDRS,ROUTE_TABLE_IDS) ne sont pas définies.

  • Le transfert IP n'est pas activé sur le nœud de passerelle.

  • L'étiquette des nœuds ou les contraintes d'anti-affinité empêchent la planification.

Étapes du diagnostic :

  1. Consultez les journaux des pods. Consultez les journaux du pod défaillant pour identifier l'erreur :

    kubectl logs -n eks-hybrid-nodes-gateway LEADER_POD
  2. Vérifiez les variables d'environnement requises. La passerelle nécessite NODE_IPVPC_CIDR, etPOD_CIDRS. S'il en manque, la passerelle se ferme immédiatement. Vérifiez les spécifications du pod :

    kubectl get pod -n eks-hybrid-nodes-gateway LEADER_POD -o jsonpath='{.spec.containers[0].env}' | jq .
    • NODE_IPest défini automatiquement à partir status.hostIP de la spécification du pod. S'il est vide, il se peut que le pod n'ait pas encore été planifié sur un nœud.

    • VPC_CIDRet POD_CIDRS sont issus des valeurs de Helm. Vérifiez qu'ils sont correctement configurés.

  3. Vérifiez le transfert IP. La passerelle vérifie que le transfert IP est activé au démarrage et se ferme si ce n'est pas le cas. Recherchez le message d'erreur IP forwarding is not enabled dans les journaux du pod. Activez le transfert IP sur le nœud :

    # Check current setting cat /proc/sys/net/ipv4/ip_forward # Enable if not set sudo sysctl -w net.ipv4.ip_forward=1

    Pour un paramètre persistant, configurez le transfert IP via le kubelet ou ajoutez-le à. net.ipv4.ip_forward=1 /etc/sysctl.d/

  4. Vérifiez l'étiquette du nœud et les contraintes de planification. Les pods de passerelle nécessitent des nœuds portant l'hybrid-gateway-node=trueétiquette. L'anti-affinité des pods garantit que chaque pod fonctionne sur un nœud distinct. Si des pods le sontPending, vérifiez s'il y a des problèmes de planification :

    kubectl describe pod -n eks-hybrid-nodes-gateway LEADER_POD

    Recherchez les événements indiquant des nœuds insuffisants, des étiquettes manquantes ou des conflits d'anti-affinité.

Problèmes liés à l'élection des dirigeants

Les modules de passerelle fonctionnent mais aucun module n'acquiert le bail de leader, ou les transitions de direction se produisent fréquemment.

Causes possibles :

  • Les autorisations RBAC pour les objets Lease sont manquantes.

  • La connectivité réseau entre les pods de passerelle et le serveur d'API Kubernetes n'est pas fiable.

  • Les paramètres d'élection du chef sont mal configurés.

Étapes du diagnostic :

  1. Vérifiez l'objet Lease. Vérifiez que le contrat de location existe et inspectez son titulaire actuel :

    kubectl get lease -n eks-hybrid-nodes-gateway hybrid-gateway-leader -o yaml

    Le spec.holderIdentity champ indique le leader actuel. spec.renewTimeIndique la date de renouvellement du bail pour la dernière fois. S'renewTimeil est obsolète, le leader a peut-être perdu la connectivité au serveur API.

  2. Vérifiez les autorisations RBAC. Le compte de service de passerelle a besoin d'autorisations pour obtenir, créer et mettre à jour des objets Lease dans l'espace de noms de la passerelle. Vérifiez le rôle et RoleBinding :

    kubectl get role -n eks-hybrid-nodes-gateway kubectl get rolebinding -n eks-hybrid-nodes-gateway

    Le rôle doit inclure getcreate, et les update verbes pour la leases ressource dans le groupe coordination.k8s.io d'API.

  3. Vérifiez les journaux des pods pour détecter les erreurs de location. Recherchez les erreurs liées à l'élection du chef dans les journaux des modules :

    kubectl logs -n eks-hybrid-nodes-gateway LEADER_POD | grep -i "leader\|lease"

    Les problèmes courants comprennent :

    • Failed to acquire lease— Le pod ne peut pas créer ni mettre à jour l'objet Lease. Vérifiez les autorisations RBAC.

    • Leadership endedFréquent suivi de Leader setup complete messages — Le leader perd et rachète le bail. Cela peut indiquer une instabilité du réseau entre le pod et le serveur API. Envisagez d'augmenter--leader-election-lease-duration.

  4. Vérifiez les paramètres de l'élection du chef. Vérifiez les valeurs configurées :

    kubectl get deployment eks-hybrid-nodes-gateway -n eks-hybrid-nodes-gateway -o jsonpath='{.spec.template.spec.containers[0].args}'

    Assurez-vous qu'--leader-election-renew-deadlineil est inférieur à--leader-election-lease-duration. Si la date limite de renouvellement dépasse la durée du bail, le leader perd le bail avant qu'il ne puisse être renouvelé. Pour de plus amples informations, veuillez consulter Réglage de l'élection des leaders.

Messages d'erreur courants

Le tableau suivant répertorie les messages d'erreur que vous pouvez voir dans les journaux du module de passerelle et leur résolution.

Message d’erreur Cause Résolution

IP forwarding is not enabled

Le paramètre du noyau n'net.ipv4.ip_forwardest pas défini 1 sur le nœud de passerelle.

Activez le transfert IP via la configuration Kubelet ou en exécutant. sysctl -w net.ipv4.ip_forward=1

Failed to setup VXLAN

La passerelle ne peut pas créer l'interface réseau VXLAN. Cela se produit généralement lorsque la NET_ADMIN capacité du pod n'est pas suffisante.

Vérifiez que les spécifications de déploiement sont incluses NET_ADMIN danssecurityContext.capabilities.add. Vérifiez que la carte Helm est correctement déployée.

Failed to verify route table access

La passerelle ne peut pas décrire une ou plusieurs tables de routage VPC au démarrage.

Vérifiez que le rôle IAM est ec2:DescribeRouteTables autorisé et que les ID de table de routage dans la configuration sont corrects.

Failed to update route tables

La passerelle ne peut pas créer ni remplacer de routes dans les tables de routage VPC.

Vérifiez que le rôle IAM possède ec2:CreateRoute et les ec2:ReplaceRoute autorisations nécessaires.

Failed to create route table manager

La passerelle ne peut pas initialiser le client AWS EC2 ni récupérer l'ENI principal de l'instance.

Vérifiez que le rôle IAM est ec2:DescribeInstances autorisé et que le service de métadonnées de l'instance (IMDS) est accessible.

NODE_IP is required

La variable ou l'--node-ipindicateur d'NODE_IPenvironnement n'est pas défini.

Vérifiez les spécifications NODE_IP du pod en status.hostIP utilisant unfieldRef. Vérifiez que la carte Helm est correctement déployée.

Invalid NODE_IP

La valeur fournie n'NODE_IPest pas une adresse IP valide.

Vérifiez la valeur de la variable d'NODE_IPenvironnement dans la spécification du pod.

pod-cidrs and vpc-cidr are required

La variable POD_CIDRS d'VPC_CIDRenvironnement or est vide.

Définissez les valeurs podCIDRs et vpcCIDR Helm lors de l'installation.

No valid route table IDs provided

La ROUTE_TABLE_IDS valeur a été définie mais ne contient aucun ID de table de routage valide après l'analyse.

Vérifiez que la valeur routeTableIDs Helm ne contient pas d'erreurs de formatage. Les ID des tables de routage doivent être séparés par des virgules (par exemple,rtb-abc123,rtb-def456).

Failed to auto-detect AWS region

La passerelle ne peut pas récupérer la AWS région à partir des métadonnées de l'instance EC2.

Vérifiez que le service de métadonnées d'instance (IMDS) est accessible. Vous pouvez également définir explicitement l'--aws-regionindicateur ou la variable d'AWS_REGIONenvironnement.

Failed to auto-detect AWS instance ID

La passerelle ne peut pas récupérer l'ID d'instance à partir des métadonnées de l'instance EC2.

Vérifiez que le service de métadonnées d'instance (IMDS) est accessible. Vous pouvez également définir explicitement l'--aws-instance-idindicateur ou la variable d'AWS_INSTANCE_IDenvironnement.

CiliumNode has no internal IP

L'CiliumNodeobjet d'un nœud hybride ne possède pas d'adresse IP interne dans ses spécifications.

Vérifiez que le nœud hybride est correctement enregistré et que l'agent Cilium est en cours d'exécution. Vérifiez la CiliumNode ressource du nœud.

CiliumNode <name> has no pod CIDRs allocated

L'CiliumNodeobjet d'un nœud hybride ne possède pas de CIDR de pod alloués par Cilium IPAM.

Vérifiez que Cilium IPAM est correctement configuré sur le nœud hybride. Vérifiez l'état IPAM du nœud sur la CiliumNode ressource.

Failed to upsert CiliumVTEPConfig

La passerelle ne peut pas créer ni mettre à jour la ressource CiliumVTEPConfig personnalisée.

Vérifiez que le CRD est installé dans le cluster et que le compte de service de passerelle est autorisé à gérer les CiliumVTEPConfig ressources.

Unable to create manager

Le gestionnaire d'exécution du contrôleur n'a pas pu s'initialiser.

Consultez les journaux du pod pour plus de contexte. Les causes courantes incluent une configuration kubeconfig non valide ou l'impossibilité d'accéder au serveur API Kubernetes.

Failed to add gateway setup

Le runnable élu par le leader n'a pas pu être enregistré auprès du responsable du contrôleur.

Il s'agit généralement d'une erreur interne. Consultez les journaux complets du pod pour plus de contexte et signalez le problème dans le GitHub référentiel.

Unable to create Node controller

Le CiliumNode réconciliateur n'a pas pu être enregistré auprès du responsable du contrôleur.

Consultez les journaux du pod pour plus de contexte. Vérifiez que le CiliumNode CRD est installé dans le cluster.

Problem running manager

Le gestionnaire du contrôleur s'est retiré de façon inattendue.

Vérifiez les journaux du pod pour détecter l'erreur sous-jacente. Parmi les causes courantes, citons la perte de connectivité au serveur API Kubernetes ou un conflit de port sur les métriques ou les adresses de liaison de la sonde de santé.

failed to access route table <id>

La passerelle ne peut pas décrire une table de routage VPC spécifique lors de la vérification de démarrage.

Vérifiez que le rôle IAM est ec2:DescribeRouteTables autorisé et que l'ID de la table de routage est correct. La table de routage doit exister dans la même région que l'instance de passerelle.