Fehlerbehebung bei App Mesh Kubernetes - AWS App Mesh

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung bei App Mesh Kubernetes

In diesem Thema werden häufig auftretende Probleme beschrieben, die bei der Verwendung von App Mesh mit Kubernetes auftreten können.

In Kubernetes erstellte App Mesh-Ressourcen können in App Mesh nicht gefunden werden

Symptome

Sie haben die App Mesh-Ressourcen mithilfe der benutzerdefinierten Ressourcendefinition (CRD) von Kubernetes erstellt, aber die Ressourcen, die Sie erstellt haben, sind in App Mesh nicht sichtbar, wenn Sie die AWS Management Console APIs oder verwenden.

Auflösung

Die wahrscheinliche Ursache ist ein Fehler im Kubernetes-Controller für App Mesh. Weitere Informationen finden Sie unter Problembehandlung unter. GitHub Überprüfen Sie die Controller-Protokolle auf Fehler oder Warnungen, die darauf hinweisen, dass der Controller keine Ressourcen erstellen konnte.

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

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.

Nach dem Einspritzen des Envoy-Sidecar-Wagens bestehen die Prüfungen der Bereitschaft und Lebendigkeit der Pods nicht

Symptome

Die Pods für Ihre Anwendung wurden zuvor erfolgreich ausgeführt, aber nachdem der Envoy-Sidecar in einen Pod eingefügt wurde, schlagen die Bereitschafts- und Lebendigkeitsprüfungen allmählich fehl.

Auflösung

Stellen Sie sicher, dass der Envoy-Container, der in den Pod eingefügt wurde, über den Envoy-Verwaltungsdienst von App Mesh gestartet wurde. Sie können alle Fehler überprüfen, indem Sie auf die Fehlercodes unter verweisen. Envoy wurde mit Fehlertext vom App Mesh Envoy-Verwaltungsdienst getrennt Sie können den folgenden Befehl verwenden, um die Envoy-Protokolle für den entsprechenden Pod zu überprüfen.

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

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.

Pods registrieren sich nicht als Instances oder werden nicht deregistriert AWS Cloud Map

Symptome

Ihre Kubernetes-Pods werden im Rahmen ihres Lebenszyklus nicht für sie registriert oder deren Registrierung AWS Cloud Map aufgehoben. Ein Pod kann erfolgreich gestartet werden und bereit sein, Datenverkehr zu verarbeiten, empfängt aber keinen. Wenn ein Pod beendet wird, behalten Clients möglicherweise immer noch seine IP-Adresse und versuchen, Traffic an ihn zu senden, was fehlschlägt.

Auflösung

Dies ist ein bekanntes Problem. Weitere Informationen finden Sie unter Probleme mit dem Problem, dass die Pods in Kubernetes nicht auto registriert/deregistriert werden. AWS Cloud Map GitHub Aufgrund der Beziehung zwischen Pods, virtuellen App Mesh-Knoten und AWS Cloud Map Ressourcen kann der App Mesh Mesh-Controller für Kubernetes desynchronisiert werden und Ressourcen verlieren. Dies kann beispielsweise passieren, wenn eine virtuelle Knotenressource aus Kubernetes gelöscht wird, bevor die zugehörigen Pods beendet werden.

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

  • Stellen Sie sicher, dass Sie die neueste Version des App Mesh Mesh-Controllers für Kubernetes ausführen.

  • Stellen Sie sicher, dass die AWS Cloud Map namespaceName und in Ihrer Definition des virtuellen Knotens korrekt serviceName sind.

  • Stellen Sie sicher, dass Sie alle zugehörigen Pods löschen, bevor Sie Ihre virtuelle Knotendefinition löschen. Wenn Sie Hilfe bei der Identifizierung der Pods benötigen, die einem virtuellen Knoten zugeordnet sind, finden Sie weitere Informationen unterEs kann nicht festgestellt werden, wo ein Pod für eine App Mesh Mesh-Ressource ausgeführt wird.

  • Wenn das Problem weiterhin besteht, führen Sie den folgenden Befehl aus, um Ihre Controller-Protokolle auf Fehler zu überprüfen, die Ihnen helfen könnten, das zugrundeliegende Problem aufzudecken.

    kubectl logs -n appmesh-system \ $(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
  • Erwägen Sie, den folgenden Befehl zu verwenden, um Ihre Controller-Pods neu zu starten. Dadurch können Synchronisierungsprobleme behoben werden.

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

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.

Es kann nicht festgestellt werden, wo ein Pod für eine App Mesh Mesh-Ressource ausgeführt wird

Symptome

Wenn Sie App Mesh auf einem Kubernetes-Cluster ausführen, kann ein Operator nicht feststellen, wo ein Workload oder Pod für eine bestimmte App Mesh Mesh-Ressource ausgeführt wird.

Auflösung

Kubernetes-Pod-Ressourcen werden mit dem Mesh und dem virtuellen Knoten annotiert, denen sie zugeordnet sind. Mit dem folgenden Befehl können Sie abfragen, welche Pods für einen bestimmten virtuellen Knotennamen ausgeführt werden.

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

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.

Es kann nicht festgestellt werden, als welche App Mesh Mesh-Ressource ein Pod ausgeführt wird

Symptome

Wenn App Mesh auf einem Kubernetes-Cluster ausgeführt wird, kann ein Operator nicht feststellen, als welche App Mesh Mesh-Ressource ein bestimmter Pod ausgeführt wird.

Auflösung

Kubernetes-Pod-Ressourcen werden mit dem Mesh und dem virtuellen Knoten annotiert, denen sie zugeordnet sind. Sie können die Namen des Meshs und der virtuellen Knoten ausgeben, indem Sie den Pod mit dem folgenden Befehl direkt abfragen.

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

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.

Client Envoys können nicht mit App Mesh Envoy Management Service kommunizieren, wenn IMDSv1 deaktiviert ist

Symptome

Wenn deaktiviert IMDSv1 ist, können Client-Envoys nicht mit der App Mesh-Steuerebene (Envoy Management Service) kommunizieren. IMDSv2Die Unterstützung war in der App Mesh Envoy-Version zuvor v1.24.0.0-prod nicht verfügbar.

Auflösung

Um dieses Problem zu beheben, können Sie eines der drei folgenden Dinge tun.

  • Führen Sie ein Upgrade auf die App Mesh Envoy-Version v1.24.0.0-prod oder höher durch, die IMDSv2 Unterstützung bietet.

  • Aktivieren Sie es erneut IMDSv1 auf der Instanz, auf der Envoy ausgeführt wird. Anweisungen zur Wiederherstellung IMDSv1 finden Sie unter Konfiguration der Optionen für Instanz-Metadaten.

  • Wenn Ihre Dienste auf Amazon EKS ausgeführt werden, wird empfohlen, IAM-Rollen für Dienstkonten (IRSA) zum Abrufen von Anmeldeinformationen zu verwenden. Anweisungen zur Aktivierung von IRSA finden Sie unter IAM-Rollen für Dienstkonten.

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.

IRSA funktioniert nicht auf Anwendungscontainern, wenn App Mesh aktiviert ist und Envoy injiziert wird

Symptome

Wenn App Mesh auf einem Amazon EKS-Cluster mithilfe des App Mesh Mesh-Controllers für Amazon EKS aktiviert wird, werden Envoy und proxyinit Container in den Anwendungs-Pod eingefügt. Die Anwendung kann nicht davon ausgehen IRSA und nimmt stattdessen das node role an. Wenn wir die Pod-Details beschreiben, stellen wir fest, dass entweder die AWS_ROLE_ARN Umgebungsvariable AWS_WEB_IDENTITY_TOKEN_FILE oder nicht im Anwendungscontainer enthalten ist.

Auflösung

Wenn eine AWS_WEB_IDENTITY_TOKEN_FILE oder AWS_ROLE_ARN mehrere Umgebungsvariablen definiert sind, überspringt der Webhook den Pod. Geben Sie keine dieser Variablen an und der Webhook kümmert sich darum, sie für Sie einzufügen.

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 }

Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein GitHub Problem zu öffnen, oder wenden Sie sich an den AWS Support.