Résolution des problèmes liés à App Mesh Kubernetes

Cette rubrique décrit les problèmes courants que vous pouvez rencontrer lorsque vous utilisez App Mesh avec Kubernetes.

Les ressources App Mesh créées dans Kubernetes sont introuvables dans App Mesh

Symptômes

Vous avez créé les ressources App Mesh à l'aide de la définition de ressource personnalisée (CRD) de Kubernetes, mais les ressources que vous avez créées ne sont pas visibles dans App Mesh lorsque vous utilisez les API or. AWS Management Console

Résolution

La cause probable est une erreur dans le contrôleur Kubernetes pour App Mesh. Pour plus d'informations, consultez la section Résolution des problèmes sur GitHub. Vérifiez les journaux du contrôleur pour détecter toute erreur ou tout avertissement indiquant que le contrôleur n'a pas pu créer de ressources.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller)

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.

Les dosettes échouent aux contrôles de préparation et de vivacité après l'injection du sidecar Envoy

Symptômes

Les modules de votre application fonctionnaient correctement auparavant, mais une fois que le sidecar Envoy a été injecté dans un module, les contrôles de disponibilité et de vivacité commencent à échouer.

Résolution

Assurez-vous que le conteneur Envoy injecté dans le pod a démarré avec le service de gestion Envoy d'App Mesh. Vous pouvez vérifier les erreurs éventuelles en référençant les codes d'erreur dansEnvoy s'est déconnecté du service de gestion App Mesh Envoy avec un texte d'erreur. Vous pouvez utiliser la commande suivante pour inspecter les journaux Envoy pour le pod concerné.

kubectl logs -n appmesh-system -f \
    $(kubectl get pods -n appmesh-system -o name | grep controller) \
    | grep "gRPC config stream closed"

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.

Les pods ne s'enregistrent pas ou ne se désenregistrent pas en tant qu'instances AWS Cloud Map

Symptômes

Vos pods Kubernetes ne sont pas enregistrés ou désenregistrés dans le AWS Cloud Map cadre de leur cycle de vie. Un module peut démarrer correctement et être prêt à recevoir du trafic, mais ne pas en recevoir. Lorsqu'un pod est fermé, les clients peuvent toujours conserver son adresse IP et tenter d'y envoyer du trafic, sans succès.

Résolution

Il s'agit d'un problème connu. Pour plus d'informations, consultez la section Les pods ne sont pas enregistrés/déenregistrés automatiquement dans Kubernetes en cas de problème. AWS Cloud Map GitHub En raison de la relation entre les pods, les nœuds virtuels App Mesh et les AWS Cloud Map ressources, le contrôleur App Mesh pour Kubernetes peut se désynchroniser et perdre des ressources. Par exemple, cela peut se produire si une ressource de nœud virtuel est supprimée de Kubernetes avant de mettre fin à ses pods associés.

Pour pallier ce problème :

• Assurez-vous que vous utilisez la dernière version du contrôleur App Mesh pour Kubernetes.

• Assurez-vous que les AWS Cloud Map namespaceName et serviceName sont corrects dans la définition de votre nœud virtuel.

• Assurez-vous de supprimer tous les pods associés avant de supprimer la définition de votre nœud virtuel. Si vous avez besoin d'aide pour identifier les pods associés à un nœud virtuel, consultezImpossible de déterminer où s'exécute un pod pour une ressource App Mesh.

• Si le problème persiste, exécutez la commande suivante pour inspecter les journaux de votre manette afin de détecter les erreurs susceptibles de révéler le problème sous-jacent.

  kubectl logs -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

• Envisagez d'utiliser la commande suivante pour redémarrer vos modules de manette. Cela peut résoudre les problèmes de synchronisation.

  kubectl delete -n appmesh-system \
      $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.

Impossible de déterminer où s'exécute un pod pour une ressource App Mesh

Symptômes

Lorsque vous exécutez App Mesh sur un cluster Kubernetes, un opérateur ne peut pas déterminer où s'exécute une charge de travail, ou un pod, pour une ressource App Mesh donnée.

Résolution

Les ressources du pod Kubernetes sont annotées avec le maillage et le nœud virtuel auxquels elles sont associées. Vous pouvez demander quels pods sont en cours d'exécution pour un nom de nœud virtuel donné à l'aide de la commande suivante.

kubectl get pods --all-namespaces -o json | \
    jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.

Impossible de déterminer la ressource App Mesh sous laquelle un pod est exécuté

Symptômes

Lors de l'exécution d'App Mesh sur un cluster Kubernetes, un opérateur ne peut pas déterminer la ressource App Mesh utilisée par un pod donné.

Résolution

Les ressources du pod Kubernetes sont annotées avec le maillage et le nœud virtuel auxquels elles sont associées. Vous pouvez générer les noms du maillage et des nœuds virtuels en interrogeant directement le pod à l'aide de la commande suivante.

kubectl get pod pod-name -n namespace -o json | \
    jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.

Les envoyés clients ne sont pas en mesure de communiquer avec le service de gestion App Mesh Envoy lorsque IMDSv1 est désactivé

Symptômes

Lorsqu'elle IMDSv1 est désactivée, le client Envoys ne peut pas communiquer avec le plan de contrôle App Mesh (Envoy Management Service). IMDSv2le support n'est pas disponible sur la version App Mesh Envoy auparavantv1.24.0.0-prod.

Résolution

Pour résoudre ce problème, vous pouvez effectuer l'une des trois opérations suivantes.

• Passez à la version App Mesh Envoy v1.24.0.0-prod ou à une version ultérieure, IMDSv2 compatible.

• Réactivez-le IMDSv1 sur l'instance sur laquelle Envoy est exécuté. Pour obtenir des instructions sur la restaurationIMDSv1, consultez Configurer les options de métadonnées de l'instance.

• Si vos services s'exécutent sur Amazon EKS, il est recommandé d'utiliser les rôles IAM pour les comptes de service (IRSA) pour récupérer les informations d'identification. Pour obtenir des instructions sur l'activation de l'IRSA, consultez la section Rôles IAM pour les comptes de service.

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.

L'IRSA ne fonctionne pas sur le conteneur d'applications lorsque App Mesh est activé et qu'Envoy est injecté

Symptômes

Lorsque App Mesh est activé sur un cluster Amazon EKS à l'aide du contrôleur App Mesh pour Amazon EKS, Envoy et les proxyinit conteneurs sont injectés dans le module d'application. L'application n'est pas en mesure IRSA de supposer quenode role. Lorsque nous décrivons les détails du pod, nous constatons alors que la variable d'AWS_ROLE_ARNenvironnement AWS_WEB_IDENTITY_TOKEN_FILE ou n'est pas incluse dans le conteneur de l'application.

Résolution

Si l'une AWS_WEB_IDENTITY_TOKEN_FILE ou AWS_ROLE_ARN l'autre des variables d'environnement sont définies, le webhook ignorera le pod. Ne fournissez aucune de ces variables et le webhook se chargera de vous les injecter.

reservedKeys := map[string]string{
        "AWS_ROLE_ARN":                "",
        "AWS_WEB_IDENTITY_TOKEN_FILE": "",
    }
    ...
    for _, env := range container.Env {
        if _, ok := reservedKeys[env.Name]; ok {
            reservedKeysDefined = true
        }

Si votre problème n'est toujours pas résolu, pensez à en ouvrir un GitHub ou à contacter le AWS Support.