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.
# Problembehebung bei App Mesh
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
In diesem Kapitel werden bewährte Methoden zur Fehlerbehebung und allgemeine Probleme beschrieben, die bei der Verwendung von App Mesh auftreten können. Wählen Sie einen der folgenden Bereiche aus, um sich über bewährte Verfahren und häufig auftretende Probleme in diesem Bereich zu informieren.
**Topics**
+ [Bewährte Methoden zur Fehlerbehebung bei App Mesh](troubleshooting-best-practices.md)
+ [Fehlerbehebung bei der Einrichtung von App Mesh](troubleshooting-setup.md)
+ [Fehlerbehebung bei App Mesh Mesh-Konnektivität](troubleshooting-connectivity.md)
+ [Fehlerbehebung bei App Mesh-Skalierung](troubleshooting-scaling.md)
+ [Fehlerbehebung bei App Mesh Observability](troubleshooting-observability.md)
+ [Fehlerbehebung bei App Mesh-Sicherheit](troubleshooting-security.md)
+ [Fehlerbehebung bei App Mesh Kubernetes](troubleshooting-kubernetes.md)
# Bewährte Methoden zur Fehlerbehebung bei App Mesh
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
Wir empfehlen Ihnen, die bewährten Methoden in diesem Thema zu befolgen, um Probleme bei der Verwendung von App Mesh zu beheben.
## Aktivieren Sie die Envoy-Proxy-Administrationsoberfläche
Der Envoy-Proxy wird mit einer Administrationsoberfläche geliefert, mit der Sie Konfigurationen und Statistiken ermitteln und andere Verwaltungsfunktionen wie den Verbindungsabbau ausführen können. Weitere Informationen finden Sie in der [Envoy-Dokumentation unter Administrationsoberfläche](https://www.envoyproxy.io/docs/envoy/latest/operations/admin).
Wenn Sie die verwaltete Version verwenden[Bild des Gesandten](envoy.md), ist der Administrationsendpunkt standardmäßig auf Port 9901 aktiviert. Die unter angegebenen Beispiele [Fehlerbehebung bei der Einrichtung von App Mesh](troubleshooting-setup.md) zeigen die Beispiel-URL für den Administrationsendpunkt als `http://my-app.default.svc.cluster.local:9901/` an.
**Anmerkung**
Der Administrationsendpunkt sollte niemals dem öffentlichen Internet zugänglich sein. Darüber hinaus empfehlen wir, die Protokolle des Administrationsendpunkts zu überwachen, die in der `ENVOY_ADMIN_ACCESS_LOG_FILE` Umgebungsvariablen `/tmp/envoy_admin_access.log` standardmäßig auf festgelegt sind.
## Aktivieren Sie die Envoy DogStats D-Integration für das Offload von Metriken
Der Envoy-Proxy kann so konfiguriert werden, dass er Statistiken für den OSI Layer 4- und Layer-7-Verkehr sowie für den internen Prozessstatus auslagert. In diesem Thema wird zwar gezeigt, wie Sie diese Statistiken verwenden können, ohne die Metriken auf Senken wie CloudWatch Metrics und Prometheus auszulagern, aber wenn Sie diese Statistiken an einem zentralen Ort für alle Ihre Anwendungen haben, können Sie Probleme schneller diagnostizieren und Verhalten bestätigen. Weitere Informationen finden Sie unter [Using Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) und in der [Prometheus-Dokumentation](https://prometheus.io/docs/introduction/overview/).
Sie können DogStats D-Metriken konfigurieren, indem Sie die in definierten Parameter festlegen. [DogStatsD-Variablen](envoy-config.md#envoy-dogstatsd-config) Weitere Informationen zu DogStats D finden Sie in der [DogStatsD-Dokumentation](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent). Eine Demonstration der Übertragung von Metriken in AWS CloudWatch Metriken finden Sie in der Anleitung zu den [Grundlagen von App Mesh mit Amazon ECS.](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics) GitHub
## Aktivieren der Zugriffsprotokolle
Wir empfehlen, die Zugriffsprotokolle auf Ihrem [Virtuelle Knoten](virtual_nodes.md) PC zu aktivieren[Virtuelle Gateways](virtual_gateways.md), um Details zum Datenverkehr zwischen Ihren Anwendungen zu ermitteln. Weitere Informationen finden Sie unter [Zugriffsprotokollierung](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging) in der Envoy-Dokumentation. Die Protokolle enthalten detaillierte Informationen zum Verkehrsverhalten auf OSI Layer 4 und Layer 7. Wenn Sie das Standardformat von Envoy verwenden, können Sie die [CloudWatch Zugriffsprotokolle mit Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) mithilfe der folgenden Parse-Anweisung analysieren.
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## Aktivieren Sie die Envoy-Debug-Protokollierung in Vorproduktionsumgebungen
Wir empfehlen, die Protokollebene des Envoy-Proxys `debug` in einer Vorproduktionsumgebung auf einzustellen. Mithilfe von Debug-Protokollen können Sie Probleme identifizieren, bevor Sie die zugehörige App Mesh Mesh-Konfiguration auf Ihre Produktionsumgebung übertragen.
Wenn Sie das [Envoy-Image](envoy.md) verwenden, können Sie die Protokollebene `debug` über die `ENVOY_LOG_LEVEL` Umgebungsvariable auf einstellen.
**Anmerkung**
Wir empfehlen nicht, das `debug` Level in Produktionsumgebungen zu verwenden. Wenn Sie die Stufe auf festlegen, `debug` wird die Protokollierung erhöht und dies kann sich auf die Leistung und die Gesamtkosten von Protokollen auswirken, die an Lösungen wie [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) ausgelagert werden.
Wenn Sie das Standardformat von Envoy verwenden, können Sie die [CloudWatch Prozessprotokolle mit Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) mithilfe der folgenden Parse-Anweisung analysieren:
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## Überwachen Sie die Envoy-Proxy-Konnektivität mit der App Mesh-Steuerebene
Wir empfehlen Ihnen, die Envoy-Metriken `control_plane.connected_state` zu überwachen, um sicherzustellen, dass der Envoy-Proxy mit der App Mesh-Steuerebene kommuniziert, um die dynamischen Konfigurationsressourcen abzurufen. [Weitere Informationen finden Sie unter Management Server.](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html)
# Fehlerbehebung bei der Einrichtung von App Mesh
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
In diesem Thema werden häufig auftretende Probleme beschrieben, die bei der Einrichtung von App Mesh auftreten können.
## Das Envoy-Container-Image kann nicht abgerufen werden
**Symptome**
Sie erhalten die folgende Fehlermeldung in einer Amazon ECS-Aufgabe. Der Amazon ECR *account ID* und *Region* die folgende Nachricht können unterschiedlich sein, je nachdem, aus welchem Amazon ECR-Repository Sie das Container-Image abgerufen haben.
```
CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'
```
**Auflösung**
Dieser Fehler weist darauf hin, dass die verwendete Aufgabenausführungsrolle nicht berechtigt ist, mit Amazon ECR zu kommunizieren und das Envoy-Container-Image nicht aus dem Repository abrufen kann. Die Ihrer Amazon ECS-Aufgabe zugewiesene Aufgabenausführungsrolle benötigt eine IAM-Richtlinie mit den folgenden Aussagen:
```
{
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
"Effect": "Allow"
},
{
"Action": "ecr:GetAuthorizationToken",
"Resource": "*",
"Effect": "Allow"
}
```
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Es kann keine Verbindung zum App Mesh Envoy-Verwaltungsdienst hergestellt werden
**Symptome**
Ihr Envoy-Proxy kann keine Verbindung zum App Mesh Envoy-Verwaltungsdienst herstellen. Sie sehen:
+ Fehler beim Ablehnen der Verbindung
+ Verbindungs-Timeouts
+ Fehler beim Auflösen des App Mesh Envoy-Verwaltungsdienst-Endpunkts
+ gRPC-Fehler
**Auflösung**
Stellen Sie sicher, dass Ihr Envoy-Proxy Zugriff auf das Internet oder einen privaten [VPC-Endpunkt](vpc-endpoints.md) hat und dass Ihre [Sicherheitsgruppen](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html) ausgehenden Datenverkehr auf Port 443 zulassen. Die öffentlichen Envoy-Verwaltungsdienst-Endpunkte von App Mesh folgen dem FQDN-Format (Fully Qualified Domain Name).
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
Sie können Ihre Verbindung zu EMS mit dem folgenden Befehl debuggen. Dadurch wird eine gültige, aber leere gRPC-Anfrage an den Envoy Management Service gesendet.
```
curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources
```
Wenn Sie diese Nachrichten zurückerhalten, funktioniert Ihre Verbindung zum Envoy Management Service. Informationen zum Debuggen von gRPC-Fehlern finden Sie in den Fehlern in [Envoy, die vom App Mesh Envoy-Verwaltungsdienst getrennt wurden, mit Fehlertext](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes).
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Envoy wurde mit Fehlertext vom App Mesh Envoy-Verwaltungsdienst getrennt
**Symptome**
Ihr Envoy-Proxy kann keine Verbindung zum App Mesh Envoy-Verwaltungsdienst herstellen und dessen Konfiguration nicht empfangen. Ihre Envoy-Proxyprotokolle enthalten einen Protokolleintrag wie den folgenden.
```
gRPC config stream closed: gRPC status code, message
```
**Auflösung**
In den meisten Fällen sollte der Meldungsteil des Protokolls auf das Problem hinweisen. In der folgenden Tabelle sind die häufigsten gRPC-Statuscodes, die Sie möglicherweise sehen, sowie deren Ursachen und Lösungen aufgeführt.
| gRPC-Statuscode | Ursache | Auflösung |
| --- | --- | --- |
| 0 | Trennen Sie die Verbindung zum Envoy-Verwaltungsdienst ordnungsgemäß. | Es gibt kein Problem. App Mesh trennt gelegentlich Envoy-Proxys mit diesem Statuscode. Envoy stellt die Verbindung wieder her und erhält weiterhin Updates. |
| 3 | Der Mesh-Endpunkt (virtueller Knoten oder virtuelles Gateway) oder eine der zugehörigen Ressourcen konnte nicht gefunden werden. | Überprüfen Sie Ihre Envoy-Konfiguration noch einmal, um sicherzustellen, dass sie den entsprechenden Namen der App Mesh Mesh-Ressource hat, die sie darstellt. Wenn Ihre App Mesh Mesh-Ressource in andere AWS Ressourcen wie AWS Cloud Map Namespaces oder ACM-Zertifikate integriert ist, stellen Sie sicher, dass diese Ressourcen vorhanden sind. |
| 7 | Der Envoy-Proxy darf keine Aktion ausführen, z. B. eine Verbindung zum Envoy-Verwaltungsdienst herstellen oder zugehörige Ressourcen abrufen. | Stellen Sie sicher, dass Sie [eine IAM-Richtlinie erstellen, die die entsprechenden Richtlinienerklärungen](proxy-authorization.md#create-iam-policy) für App Mesh und andere Dienste enthält, und fügen Sie diese Richtlinie dem IAM-Benutzer oder der IAM-Rolle hinzu, die Ihr Envoy-Proxy für die Verbindung mit dem Envoy-Verwaltungsdienst verwendet. |
| 8 | Die Anzahl der Envoy-Proxys für eine bestimmte App Mesh Mesh-Ressource überschreitet das Dienstkontingent auf Kontoebene. | Informationen zu Standardkontingenten und [App Mesh Mesh-Dienstkontingente](service-quotas.md) zur Beantragung einer Kontingenterhöhung finden Sie unter. |
| 16 | Der Envoy-Proxy verfügt nicht über gültige Anmeldeinformationen für AWS. | Stellen Sie sicher, dass der Envoy über die entsprechenden Anmeldeinformationen verfügt, um über einen IAM-Benutzer oder eine IAM-Rolle eine Verbindung zu AWS Diensten herzustellen. Ein bekanntes Problem, [\$124136](https://github.com/envoyproxy/envoy/issues/24136), in Envoy für Version v1.24 und früher schlägt fehl, die Anmeldeinformationen abzurufen, wenn der Envoy-Prozess zu viele Dateideskriptoren verwendet. 1024 Dieses Problem tritt auf, wenn Envoy ein hohes Datenvolumen verarbeitet. Sie können dieses Problem überprüfen, indem Sie in den Envoy-Protokollen auf Debug-Ebene nach dem Text "" suchen. A libcurl function was given a bad argument Um dieses Problem zu beheben, führen Sie ein Upgrade auf die Envoy-Version oder höher durch. v1.25.1.0-prod |
Sie können die Statuscodes und Meldungen von Ihrem Envoy-Proxy mit [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) verfolgen, indem Sie die folgende Abfrage verwenden:
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
Wenn die angegebene Fehlermeldung nicht hilfreich war oder Ihr Problem immer noch nicht gelöst ist, sollten Sie erwägen, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen.
## Die Zustandsprüfung des Envoy-Containers, die Bereitschaftsprüfung oder die Lebendigkeitsprüfung sind fehlgeschlagen
**Symptome**
Ihr Envoy-Proxy hat die Integritätsprüfungen in einer Amazon ECS-Aufgabe, einer Amazon EC2 EC2-Instance oder einem Kubernetes-Pod nicht bestanden. Sie fragen beispielsweise die Envoy-Administrationsoberfläche mit dem folgenden Befehl ab und erhalten einen anderen Status als. `LIVE`
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**Auflösung**
Im Folgenden finden Sie eine Liste von Korrekturschritten, die vom vom Envoy-Proxy zurückgegebenen Status abhängen.
+ `PRE_INITIALIZING`oder `INITIALIZING` — Der Envoy-Proxy hat noch keine Konfiguration erhalten oder kann keine Verbindung herstellen und die Konfiguration vom App Mesh Envoy-Verwaltungsdienst abrufen. Der Envoy erhält möglicherweise eine Fehlermeldung vom Envoy-Verwaltungsdienst, wenn er versucht, eine Verbindung herzustellen. Weitere Informationen finden Sie in den Fehlern unter. [Envoy wurde mit Fehlertext vom App Mesh Envoy-Verwaltungsdienst getrennt](#ts-setup-grpc-error-codes)
+ `DRAINING`— Der Envoy-Proxy hat als Reaktion auf eine `/drain_listeners` Oder-Anfrage auf der `/healthcheck/fail` Envoy-Administrationsoberfläche damit begonnen, Verbindungen abzubauen. Es wird nicht empfohlen, diese Pfade auf der Administrationsoberfläche aufzurufen, es sei denn, Sie sind dabei, Ihre Amazon ECS-Aufgabe, Ihre Amazon EC2 EC2-Instance oder Ihren Kubernetes-Pod zu beenden.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Die Integritätsprüfung vom Load Balancer zum Mesh-Endpunkt schlägt fehl
**Symptome**
Ihr Mesh-Endpunkt wird von der Container-Integritätsprüfung oder der Bereitschaftsprüfung als fehlerfrei eingestuft, aber die Integritätsprüfung vom Load Balancer zum Mesh-Endpunkt schlägt fehl.
**Auflösung**
Führen Sie die folgenden Aufgaben aus, um das Problem zu beheben.
+ Stellen Sie sicher, dass die mit Ihrem Mesh-Endpunkt verknüpfte [Sicherheitsgruppe](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) eingehenden Datenverkehr an dem Port akzeptiert, den Sie für Ihre Zustandsprüfung konfiguriert haben.
+ Stellen Sie sicher, dass die Zustandsprüfung konsistent erfolgreich ist, wenn sie manuell angefordert wird, z. B. von einem [Bastion-Host in Ihrer VPC](https://aws.amazon.com/quickstart/architecture/linux-bastion/).
+ Wenn Sie eine Integritätsprüfung für einen virtuellen Knoten konfigurieren, empfehlen wir, in Ihrer Anwendung einen Integritätsprüfungsendpunkt zu implementieren, z. B. /ping für HTTP. Dadurch wird sichergestellt, dass sowohl der Envoy-Proxy als auch Ihre Anwendung vom Load Balancer aus routbar sind.
+ Sie können einen beliebigen Elastic Load Balancer-Typ für den virtuellen Knoten verwenden, je nachdem, welche Funktionen Sie benötigen. Weitere Informationen finden Sie unter [Elastic Load Balancing Balancing-Funktionen](https://aws.amazon.com/elasticloadbalancing/features/#compare).
+ Wenn Sie eine Integritätsprüfung für ein [virtuelles Gateway](virtual_gateways.md) konfigurieren, empfehlen wir die Verwendung eines [Netzwerk-Loadbalancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) mit einer TCP- oder TLS-Zustandsprüfung am Listener-Port des virtuellen Gateways. Dadurch wird sichergestellt, dass der virtuelle Gateway-Listener über ein Bootstrapping verfügt und bereit ist, Verbindungen anzunehmen.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Das virtuelle Gateway akzeptiert keinen Verkehr auf den Ports 1024 oder weniger
**Symptome**
Ihr virtuelles Gateway akzeptiert keinen Verkehr auf Port 1024 oder weniger, akzeptiert aber Verkehr auf einer Portnummer, die größer als 1024 ist. Sie fragen beispielsweise die Envoy-Statistiken mit dem folgenden Befehl ab und erhalten einen anderen Wert als Null.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
Möglicherweise sehen Sie in Ihren Protokollen einen Text, der dem folgenden Text ähnelt, der einen Fehler beim Binden an einen privilegierten Port beschreibt:
```
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_: cannot bind '0.0.0.0:': Permission denied
```
**Auflösung**
Um das Problem zu lösen, muss der für das Gateway angegebene Benutzer über Linux-Funktionen verfügen`CAP_NET_BIND_SERVICE`. Weitere Informationen finden Sie unter [Capabilities](https://www.man7.org/linux/man-pages/man7/capabilities.7.html) im Linux Programmer's Manual, [Linux-Parameter](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters) in ECS-Aufgabendefinitionsparametern und [Funktionen für einen Container festlegen](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) in der Kubernetes-Dokumentation.
**Wichtig**
Fargate muss einen Portwert verwenden, der größer als 1024 ist.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
# Fehlerbehebung bei App Mesh Mesh-Konnektivität
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
In diesem Thema werden häufig auftretende Probleme beschrieben, die bei der App Mesh Mesh-Konnektivität auftreten können.
## Der DNS-Name für einen virtuellen Dienst konnte nicht aufgelöst werden
**Symptome**
Ihre Anwendung kann den DNS-Namen eines virtuellen Dienstes, zu dem sie eine Verbindung herstellen möchte, nicht auflösen.
**Auflösung**
Dies ist ein bekanntes Problem. Weitere Informationen finden Sie unter [Name VirtualServices nach beliebigem Hostnamen oder FQDN](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub . Virtuelle Dienste in App Mesh können beliebig benannt werden. Solange es einen `A` DNS-Eintrag für den Namen des virtuellen Dienstes gibt und die Anwendung den Namen des virtuellen Dienstes auflösen kann, wird die Anfrage von Envoy weitergeleitet und an das entsprechende Ziel weitergeleitet. Um das Problem zu beheben, fügen Sie einer beliebigen IP-Adresse, die kein Loopback ist, einen `A` DNS-Eintrag hinzu, z. B. `10.10.10.10` für den Namen des virtuellen Dienstes. Der `A` DNS-Eintrag kann unter den folgenden Bedingungen hinzugefügt werden:
+ Wenn dem Namen in Amazon Route 53 der Name Ihrer privaten gehosteten Zone angehängt wird
+ In der Datei des Anwendungscontainers `/etc/hosts`
+ Auf einem DNS-Server eines Drittanbieters, den Sie verwalten
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Es konnte keine Verbindung zu einem virtuellen Service-Backend hergestellt werden
**Symptome**
Ihre Anwendung kann keine Verbindung zu einem virtuellen Dienst herstellen, der als Backend auf Ihrem virtuellen Knoten definiert ist. Beim Versuch, eine Verbindung herzustellen, schlägt die Verbindung möglicherweise vollständig fehl, oder die Anfrage schlägt aus Sicht der Anwendung möglicherweise mit einem `HTTP 503` Antwortcode fehl.
**Auflösung**
Wenn die Anwendung überhaupt keine Verbindung herstellen kann (kein `HTTP 503` Antwortcode zurückgegeben), gehen Sie wie folgt vor:
+ Vergewissern Sie sich, dass Ihre Rechenumgebung für die Verwendung mit App Mesh eingerichtet wurde.
+ Stellen Sie für Amazon ECS sicher, dass Sie die entsprechende [Proxykonfiguration](proxy-authorization.md) aktiviert haben. Eine end-to-end exemplarische Vorgehensweise finden Sie unter [Erste Schritte mit App Mesh und Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html).
+ Stellen Sie für Kubernetes, einschließlich Amazon EKS, sicher, dass Sie den neuesten App Mesh Mesh-Controller über Helm installiert haben. Weitere Informationen finden Sie unter [App Mesh Controller](https://hub.helm.sh/charts/aws/appmesh-controller) auf Helm Hub oder [Tutorial: App Mesh Mesh-Integration mit Kubernetes konfigurieren](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html).
+ Stellen Sie für Amazon EC2 sicher, dass Sie Ihre Amazon EC2 EC2-Instance für den Proxy von App Mesh Mesh-Verkehr eingerichtet haben. [Weitere Informationen finden Sie unter Dienste aktualisieren.](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services)
+ Stellen Sie sicher, dass der Envoy-Container, der auf Ihrem Compute-Service ausgeführt wird, erfolgreich eine Verbindung zum App Mesh Envoy-Verwaltungsdienst hergestellt hat. Sie können dies bestätigen, indem Sie die Envoy-Statistiken für das Feld überprüfen. `control_plane.connected_state` Weitere Informationen dazu finden Sie unter [Überwachen der Envoy-Proxykonnektivität](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state) in unseren **Best Practices zur Fehlerbehebung**. `control_plane.connected_state`
Wenn der Envoy die Verbindung zunächst herstellen konnte, aber später unterbrochen und nie wieder verbunden wurde, finden Sie unter [Envoy wurde vom App Mesh Envoy-Verwaltungsdienst getrennt und es wird ein Fehlertext angezeigt, um herauszufinden, warum die Verbindung](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes) unterbrochen wurde.
Wenn die Anwendung eine Verbindung herstellt, die Anfrage aber mit einem `HTTP 503` Antwortcode fehlschlägt, versuchen Sie Folgendes:
+ Stellen Sie sicher, dass der virtuelle Dienst, mit dem Sie eine Verbindung herstellen, im Mesh vorhanden ist.
+ Stellen Sie sicher, dass der virtuelle Dienst einen Anbieter hat (einen virtuellen Router oder virtuellen Knoten).
+ Wenn Sie Envoy als HTTP-Proxy verwenden und anhand der Envoy-Statistiken ausgehender Datenverkehr `cluster.cds_egress_*_mesh-allow-all` anstelle des richtigen Ziels empfangen, leitet Envoy Anfragen höchstwahrscheinlich nicht richtig weiter. `filter_chains` Dies kann auf die Verwendung eines unqualifizierten virtuellen Dienstnamens zurückzuführen sein. Wir empfehlen, den Service Discovery-Namen des tatsächlichen Dienstes als virtuellen Dienstnamen zu verwenden, da der Envoy-Proxy über deren Namen mit anderen virtuellen Diensten kommuniziert.
Weitere Informationen finden Sie unter [Virtuelle](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html) Dienste.
+ Untersuchen Sie die Envoy-Proxyprotokolle auf eine der folgenden Fehlermeldungen:
+ `No healthy upstream`— Der virtuelle Knoten, zu dem der Envoy-Proxy zu routen versucht, hat keine aufgelösten Endpunkte oder er hat keine fehlerfreien Endpunkte. Stellen Sie sicher, dass der virtuelle Zielknoten über die richtigen Einstellungen für die Diensterkennung und Zustandsprüfung verfügt.
Wenn Anfragen an den Dienst während der Bereitstellung oder Skalierung des virtuellen Back-End-Dienstes fehlschlagen, folgen Sie den Anweisungen unter[Manche Anfragen schlagen mit dem HTTP-Statuscode fehl`503`, wenn ein virtueller Dienst über einen Anbieter für virtuelle Knoten verfügt](#ts-connectivity-virtual-node-provider).
+ `No cluster match for URL`— Dies wird höchstwahrscheinlich dadurch verursacht, dass eine Anfrage an einen virtuellen Dienst gesendet wird, die nicht den Kriterien entspricht, die auf einer der von einem Anbieter für virtuelle Router definierten Routen definiert wurden. Stellen Sie sicher, dass die Anfragen der Anwendung an eine unterstützte Route gesendet werden, indem Sie sicherstellen, dass der Pfad und die HTTP-Anforderungsheader korrekt sind.
+ `No matching filter chain found`— Dies wird höchstwahrscheinlich verursacht, wenn eine Anfrage an einen virtuellen Dienst an einem ungültigen Port gesendet wird. Stellen Sie sicher, dass die Anfragen von der Anwendung denselben Port verwenden, der auf dem virtuellen Router angegeben ist.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Es konnte keine Verbindung zu einem externen Dienst hergestellt werden
**Symptome**
Ihre Anwendung kann keine Verbindung zu einem Dienst außerhalb des Mesh herstellen, `amazon.com` z.
**Auflösung**
Standardmäßig lässt App Mesh keinen ausgehenden Datenverkehr von Anwendungen innerhalb des Meshs zu Zielen außerhalb des Meshs zu. Um die Kommunikation mit einem externen Dienst zu ermöglichen, gibt es zwei Möglichkeiten:
+ Stellen Sie den [Ausgangsfilter](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) für die Mesh-Ressource auf ein`ALLOW_ALL`. Diese Einstellung ermöglicht es jeder Anwendung innerhalb des Meshs, mit jeder Ziel-IP-Adresse innerhalb oder außerhalb des Meshs zu kommunizieren.
+ Modellieren Sie den externen Dienst im Mesh mithilfe eines virtuellen Dienstes, eines virtuellen Routers, einer Route und eines virtuellen Knotens. Um beispielsweise den externen Dienst zu modellieren`example.com`, können Sie einen virtuellen Dienst `example.com` mit einem virtuellen Router und einer Route erstellen, der den gesamten Datenverkehr an einen virtuellen Knoten mit dem Hostnamen für die DNS-Diensterkennung sendet. `example.com`
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Es konnte keine Verbindung zu einem MySQL- oder SMTP-Server hergestellt werden
**Symptome**
Wenn Sie ausgehenden Datenverkehr zu allen Zielen zulassen (Mesh `EgressFilter type` =`ALLOW_ALL`), z. B. zu einem SMTP-Server oder einer MySQL-Datenbank, die eine virtuelle Knotendefinition verwendet, schlägt die Verbindung von Ihrer Anwendung fehl. Im Folgenden finden Sie beispielsweise eine Fehlermeldung beim Versuch, eine Verbindung zu einem MySQL-Server herzustellen.
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**Auflösung**
Dies ist ein bekanntes Problem, das mithilfe der App Mesh Mesh-Image-Version 1.15.0 oder höher behoben wird. Weitere Informationen finden Sie unter dem GitHub Problem [Unable to connect to MySQL with App Mesh](https://github.com/aws/aws-app-mesh-roadmap/issues/62). Dieser Fehler tritt auf, weil der von App Mesh konfigurierte Outbound-Listener in Envoy den Envoy TLS Inspector Listener-Filter hinzufügt. Weitere Informationen finden Sie unter [TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector) in der Envoy-Dokumentation. Dieser Filter bewertet, ob eine Verbindung TLS verwendet oder nicht, indem er das erste vom Client gesendete Paket überprüft. Bei MySQL und SMTP sendet der Server jedoch das erste Paket nach der Verbindung. Weitere Informationen zu MySQL finden Sie unter [Initial Handshake](https://dev.mysql.com/doc/internals/en/initial-handshake.html) in der MySQL-Dokumentation. Da der Server das erste Paket sendet, schlägt die Überprüfung am Filter fehl.
**Gehen Sie je nach Ihrer Version von Envoy wie folgt vor, um dieses Problem zu umgehen:**
+ Wenn Ihre App Mesh Mesh-Image Envoy-Version 1.15.0 oder höher ist, modellieren Sie keine externen Dienste wie **MySQL**, **SMTP**, **MSSQL** usw. als Backend für den virtuellen Knoten Ihrer Anwendung.
+ **Wenn die Envoy-Version Ihres App Mesh Mesh-Images älter als 1.15.0 ist, fügen Sie Port `3306` zur Werteliste für `APPMESH_EGRESS_IGNORED_PORTS` in Ihren Diensten für **MySQL** und als Port hinzu, den Sie für STMP verwenden.**
**Wichtig**
Die Standard-SMTP-Ports sind zwar, und `25` `587``465`, aber Sie sollten nur den Port hinzufügen, den Sie verwenden, und nicht alle drei. `APPMESH_EGRESS_IGNORED_PORTS`
Weitere Informationen finden Sie unter [Update Services](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services) für Kubernetes, [Update Services](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services) für Amazon ECS oder [Update Services](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services) für Amazon EC2.
Wenn Ihr Problem immer noch nicht gelöst ist, können Sie uns anhand des bestehenden [GitHub Problems](https://github.com/aws/aws-app-mesh-roadmap/issues/62) Einzelheiten darüber mitteilen, was bei Ihnen aufgetreten ist, oder sich an den [AWS Support](https://aws.amazon.com/premiumsupport/) wenden.
## Es konnte keine Verbindung zu einem Dienst hergestellt werden, der als virtueller TCP-Knoten oder virtueller Router in App Mesh modelliert ist
**Symptome**
Ihre Anwendung kann keine Verbindung zu einem Backend herstellen, das die TCP-Protokolleinstellung in der App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html)Mesh-Definition verwendet.
**Auflösung**
Dies ist ein bekanntes Problem. Weitere Informationen finden Sie unter [Routing zu mehreren TCP-Zielen am selben Port](https://github.com/aws/aws-app-mesh-roadmap/issues/195) am GitHub. App Mesh erlaubt derzeit nicht, dass mehrere als TCP modellierte Backend-Ziele denselben Port gemeinsam nutzen, da die Informationen, die dem Envoy-Proxy auf OSI Layer 4 zur Verfügung gestellt werden, eingeschränkt sind. Gehen Sie wie folgt vor, um sicherzustellen, dass der TCP-Verkehr für alle Backend-Ziele angemessen weitergeleitet werden kann:
+ Stellen Sie sicher, dass alle Ziele einen eindeutigen Port verwenden. Wenn Sie einen virtuellen Router-Anbieter für den virtuellen Back-End-Dienst verwenden, können Sie den Port des virtuellen Routers ändern, ohne den Port auf den virtuellen Knoten zu ändern, zu denen er weiterleitet. Auf diese Weise können die Anwendungen Verbindungen auf dem virtuellen Router-Port öffnen, während der Envoy-Proxy weiterhin den im virtuellen Knoten definierten Port verwendet.
+ Wenn das als TCP modellierte Ziel ein MySQL-Server oder ein anderes TCP-basiertes Protokoll ist, bei dem der Server die ersten Pakete nach der Verbindung sendet, finden Sie weitere Informationen unter. [Es konnte keine Verbindung zu einem MySQL- oder SMTP-Server hergestellt werden](#ts-connectivity-troubleshooting-mysql-and-smtp)
Wenn Ihr Problem immer noch nicht gelöst ist, können Sie uns anhand des bestehenden [GitHub Problems](https://github.com/aws/aws-app-mesh-roadmap/issues/195) Einzelheiten darüber mitteilen, was bei Ihnen aufgetreten ist, oder sich an den [AWS Support](https://aws.amazon.com/premiumsupport/) wenden.
## Die Konnektivität zu einem Dienst, der nicht als virtuelles Service-Backend für einen virtuellen Knoten aufgeführt ist, ist erfolgreich
**Symptome**
Ihre Anwendung ist in der Lage, eine Verbindung herzustellen und Datenverkehr an ein Ziel zu senden, das nicht als virtuelles Service-Backend auf Ihrem virtuellen Knoten angegeben ist.
**Auflösung**
Wenn Anfragen an ein Ziel weitergeleitet werden, das nicht im App Mesh modelliert wurde APIs, liegt die wahrscheinlichste Ursache darin, dass der [ausgehende Filtertyp](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html) des Meshs auf eingestellt wurde. `ALLOW_ALL` Wenn der Ausgangsfilter auf eingestellt ist`ALLOW_ALL`, wird eine ausgehende Anfrage von Ihrer Anwendung, die keinem modellierten Ziel (Backend) entspricht, an die von der Anwendung festgelegte Ziel-IP-Adresse gesendet.
Wenn Sie den Datenverkehr zu Zielen verbieten möchten, die nicht im Mesh modelliert sind, sollten Sie den Wert für den Ausgangsfilter auf festlegen. `DROP_ALL`
**Anmerkung**
Die Einstellung des Werts für den ausgehenden Netzfilter wirkt sich auf alle virtuellen Knoten innerhalb des Meshs aus.
Die Konfiguration `egress_filter` als `DROP_ALL` und die Aktivierung von TLS sind für ausgehenden Datenverkehr, der nicht an eine AWS Domain gerichtet ist, nicht verfügbar.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Manche Anfragen schlagen mit dem HTTP-Statuscode fehl`503`, wenn ein virtueller Dienst über einen Anbieter für virtuelle Knoten verfügt
**Symptome**
Ein Teil der Anfragen Ihrer Anwendung schlägt an ein virtuelles Service-Backend fehl, das einen Anbieter für virtuelle Knoten anstelle eines Anbieters für virtuelle Router verwendet. Wenn Sie einen virtuellen Router-Anbieter für den virtuellen Dienst verwenden, schlagen Anfragen nicht fehl.
**Auflösung**
Dies ist ein bekanntes Problem. Weitere Informationen finden Sie unter [Wiederholungsrichtlinie für den Anbieter virtueller Knoten für einen virtuellen Dienst](https://github.com/aws/aws-app-mesh-roadmap/issues/194) auf GitHub. Wenn Sie einen virtuellen Knoten als Anbieter für einen virtuellen Dienst verwenden, können Sie nicht die Standard-Wiederholungsrichtlinie angeben, die die Clients Ihres virtuellen Dienstes verwenden sollen. Im Vergleich dazu ermöglichen Anbieter virtueller Router die Angabe von Wiederholungsrichtlinien, da sie eine Eigenschaft der untergeordneten Routenressourcen sind.
Um Fehler bei Anfragen an Anbieter virtueller Knoten zu reduzieren, sollten Sie stattdessen einen Anbieter für virtuelle Router verwenden und für dessen Routen eine Wiederholungsrichtlinie angeben. Weitere Möglichkeiten zur Reduzierung von Anforderungsfehlern bei Ihren Anwendungen finden Sie unter[Bewährte Methoden für App Mesh](best-practices.md).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Es konnte keine Verbindung zu einem Amazon EFS-Dateisystem hergestellt werden
**Symptome**
Wenn Sie eine Amazon ECS-Aufgabe mit einem Amazon EFS-Dateisystem als Volume konfigurieren, kann die Aufgabe mit dem folgenden Fehler nicht gestartet werden.
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**Auflösung**
Dies ist ein bekanntes Problem. Dieser Fehler tritt auf, weil die NFS-Verbindung zu Amazon EFS hergestellt wird, bevor irgendwelche Container in Ihrer Aufgabe gestartet werden. Dieser Datenverkehr wird von der Proxykonfiguration an Envoy weitergeleitet, das zu diesem Zeitpunkt nicht ausgeführt wird. Aufgrund der Reihenfolge beim Start kann der NFS-Client keine Verbindung zum Amazon EFS-Dateisystem herstellen und die Aufgabe kann nicht gestartet werden. Um das Problem zu beheben, fügen Sie Port `2049` zur Werteliste für die `EgressIgnoredPorts` Einstellung in der Proxykonfiguration Ihrer Amazon ECS-Aufgabendefinition hinzu. Weitere Informationen finden Sie unter [Proxy-Konfiguration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Die Konnektivität wurde erfolgreich ausgeführt, aber die eingehende Anfrage erscheint nicht in den Zugriffsprotokollen, Traces oder Metriken für Envoy
**Symptome**
Obwohl Ihre Anwendung eine Verbindung herstellen und Anfragen an eine andere Anwendung senden kann, können Sie eingehende Anfragen entweder nicht in den Zugriffsprotokollen oder in den Ablaufverfolgungsinformationen für den Envoy-Proxy sehen.
**Auflösung**
Dies ist ein bekanntes Problem. Weitere Informationen finden Sie unter Problem beim [Einrichten der iptables-Regeln](https://github.com/aws/aws-app-mesh-roadmap/issues/166) auf Github. Der Envoy-Proxy fängt nur eingehenden Datenverkehr zu dem Port ab, auf dem der entsprechende virtuelle Knoten lauscht. Anfragen an einen anderen Port umgehen den Envoy-Proxy und erreichen direkt den dahinter stehenden Dienst. Damit der Envoy-Proxy den eingehenden Datenverkehr für Ihren Dienst abfangen kann, müssen Sie Ihren virtuellen Knoten und Dienst so einrichten, dass sie auf demselben Port lauschen.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Das Setzen der `HTTPS_PROXY` Umgebungsvariablen`HTTP_PROXY`/auf Containerebene funktioniert nicht wie erwartet.
**Symptome**
Wenn HTTP\$1PROXY/HTTPS\$1PROXY als Umgebungsvariable gesetzt ist unter:
+ App-Container in der Aufgabendefinition mit aktiviertem App Mesh. Anfragen, die an den Namespace der App Mesh Mesh-Dienste gesendet werden, erhalten `HTTP 500` Fehlerantworten vom Envoy-Sidecar.
+ Envoy-Container in der Aufgabendefinition mit aktiviertem App Mesh, Anfragen, die aus dem Envoy-Sidecar kommen, werden nicht über den `HTTPS` Proxy-Server`HTTP`/geleitet und die Umgebungsvariable funktioniert nicht.
**Auflösung**
Für den App-Container:
App Mesh funktioniert, indem der Datenverkehr innerhalb Ihrer Aufgabe über den Envoy-Proxy geleitet wird. `HTTP_PROXY`/Die `HTTPS_PROXY` Konfiguration überschreibt dieses Verhalten, indem der Containerverkehr so konfiguriert wird, dass er über einen anderen externen Proxy geleitet wird. Der Datenverkehr wird weiterhin von Envoy abgefangen, unterstützt jedoch nicht die Weiterleitung des Mesh-Datenverkehrs über einen externen Proxy.
Wenn Sie den gesamten Nicht-Mesh-Verkehr per Proxy weiterleiten möchten, stellen Sie bitte ein, `NO_PROXY` dass der CIDR/Namespace, der Localhost und die Endpunkte der Anmeldeinformationen Ihres Meshs wie im folgenden Beispiel enthalten sind.
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
Für den Envoy-Container:
Envoy unterstützt keinen generischen Proxy. Wir empfehlen nicht, diese Variablen festzulegen.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Timeouts bei Upstream-Anfragen, auch wenn das Timeout für Routen festgelegt wurde.
**Symptome**
Sie haben das Timeout definiert für:
+ Die Routen, aber Sie erhalten immer noch einen Timeout-Fehler für Upstream-Anfragen.
+ Der Listener für virtuelle Knoten und das Timeout und das Wiederholungs-Timeout für die Routen, aber Sie erhalten immer noch einen Timeout-Fehler bei Upstream-Anfragen.
**Auflösung**
Damit Anfragen mit hoher Latenz von mehr als 15 Sekunden erfolgreich abgeschlossen werden können, müssen Sie sowohl auf der Route- als auch auf der Listener-Ebene des virtuellen Knotens ein Timeout angeben.
Wenn Sie ein Route-Timeout angeben, das größer als die standardmäßigen 15 Sekunden ist, stellen Sie sicher, dass das Timeout auch für den Listener für alle beteiligten virtuellen Knoten angegeben ist. Wenn Sie das Timeout jedoch auf einen Wert reduzieren, der unter dem Standardwert liegt, ist es optional, die Timeouts an virtuellen Knoten zu aktualisieren. [Weitere Informationen zu den Optionen beim Einrichten virtueller Knoten und Routen finden Sie unter [Virtuelle Knoten](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html) und Routen.](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html)
**Wenn Sie eine **Wiederholungsrichtlinie** angegeben haben, sollte die Dauer, die Sie für das Anforderungstimeout angeben, immer größer oder gleich dem *Wiederholungstimeout sein, multipliziert mit den maximalen Wiederholungsversuchen**, die Sie in der Wiederholungsrichtlinie* definiert haben.** Dadurch kann Ihre Anfrage mit allen Wiederholungsversuchen erfolgreich abgeschlossen werden. Weitere Informationen finden Sie unter [Routen](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Envoy antwortet mit einer HTTP Bad-Anfrage.
**Symptome**
Envoy antwortet mit einer **HTTP 400 Bad Request** für alle Anfragen, die über den Network Load Balancer (NLB) gesendet werden. Wenn wir die Envoy-Protokolle überprüfen, sehen wir:
+ Debug-Protokolle:
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ Zugriffs-Logs:
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**Auflösung**
Die Lösung besteht darin, das Proxy-Protokoll Version 2 (PPv2) für die [Zielgruppenattribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes) Ihrer NLB zu deaktivieren.
Derzeit PPv2 wird der von Virtual Gateway und Virtual Node Envoy, die über die App Mesh-Steuerebene ausgeführt werden, nicht unterstützt. Wenn Sie NLB mithilfe des AWS Load Balancer-Controllers auf Kubernetes bereitstellen, deaktivieren Sie es, PPv2 indem Sie das folgende Attribut auf setzen: `false`
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
Weitere Informationen zu NLB-Ressourcenattributen finden Sie unter [Anmerkungen zum AWS Load Balancer-Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Das Timeout konnte nicht richtig konfiguriert werden.
**Symptome**
Das Timeout für Ihre Anfrage wird innerhalb von 15 Sekunden überschritten, auch wenn Sie das Timeout auf dem Listener für virtuelle Knoten und das Timeout auf der Route zum Backend für virtuelle Knoten konfiguriert haben.
**Auflösung**
Stellen Sie sicher, dass der richtige virtuelle Dienst in der Backend-Liste enthalten ist.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
# Fehlerbehebung bei App Mesh-Skalierung
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
In diesem Thema werden häufig auftretende Probleme beschrieben, die bei der App Mesh-Skalierung auftreten können.
## Konnektivität schlägt fehl und Container-Integritätsprüfungen schlagen fehl, wenn mehr als 50 Replikate für ein virtuelles node/virtual Gateway skaliert werden
**Symptome**
Wenn Sie die Anzahl der Replikate, z. B. Amazon ECS-Aufgaben, Kubernetes-Pods oder Amazon EC2 EC2-Instances, für ein virtuelles node/virtual Gateway auf über 50 skalieren, schlagen die Integritätsprüfungen des Envoy-Containers für neue und aktuell laufende Envoys fehl. Downstream-Anwendungen, die Datenverkehr an das virtuelle node/virtual Gateway senden, beginnen, Anforderungsfehler mit HTTP-Statuscode zu erkennen. `503`
**Auflösung**
Das Standardkontingent von App Mesh für die Anzahl der Envoys pro virtuellem node/virtual Gateway beträgt 50. Wenn die Anzahl der laufenden Envoys dieses Kontingent überschreitet, können neue und aktuell laufende Envoys mit dem gRPC-Statuscode () keine Verbindung zum Envoy-Verwaltungsdienst von App Mesh herstellen. `8` `RESOURCE_EXHAUSTED` Dieses Kontingent kann erhöht werden. Weitere Informationen finden Sie unter [App Mesh Mesh-Dienstkontingente](service-quotas.md).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Anfragen schlagen fehl`503`, wenn ein virtuelles Service-Backend horizontal nach oben oder unten skaliert wird
**Symptome**
Wenn ein virtueller Back-End-Dienst horizontal nach oben oder unten skaliert wird, schlagen Anfragen von Downstream-Anwendungen fehl und es wird ein `HTTP 503` Statuscode angezeigt.
**Auflösung**
App Mesh empfiehlt mehrere Ansätze, um Fehlerfälle zu minimieren und gleichzeitig Anwendungen horizontal zu skalieren. Ausführliche Informationen darüber, wie Sie diese Fehler verhindern können, finden Sie unter[Bewährte Methoden für App Mesh](best-practices.md).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Der Envoy-Container stürzt bei erhöhter Last mit Segfault ab
**Symptome**
Bei hoher Verkehrslast stürzt der Envoy-Proxy aufgrund eines Segmentierungsfehlers (Linux-Exit-Code) ab. `139` Die Envoy-Prozessprotokolle enthalten eine Aussage wie die folgende.
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**Auflösung**
Der Envoy-Proxy hat wahrscheinlich das standardmäßige Nofile-Ulimit des Betriebssystems überschritten, das Limit für die Anzahl der Dateien, die ein Prozess gleichzeitig geöffnet haben kann. Dieser Verstoß ist darauf zurückzuführen, dass der Datenverkehr mehr Verbindungen verursacht, die zusätzliche Betriebssystem-Sockets verbrauchen. Um dieses Problem zu beheben, erhöhen Sie den Wert ulimit nofile auf dem Host-Betriebssystem. Wenn Sie Amazon ECS verwenden, kann dieses Limit über die [Ulimit-Einstellungen](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html) in den [Ressourcenlimiteinstellungen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits) der Aufgabendefinition geändert werden.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Die Erhöhung der Standardressourcen spiegelt sich nicht in den Service-Limits wider
**Symptome**
Nachdem Sie das Standardlimit für App Mesh Mesh-Ressourcen erhöht haben, wird der neue Wert nicht berücksichtigt, wenn Sie sich Ihre Dienstlimits ansehen.
**Auflösung**
Die neuen Limits werden derzeit zwar nicht angezeigt, Kunden können sie aber trotzdem nutzen.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Die Anwendung stürzt aufgrund einer großen Anzahl von Aufrufen von Health Checks ab.
**Symptome**
Nach der Aktivierung aktiver Integritätsprüfungen für einen virtuellen Knoten nimmt die Anzahl der Health Check-Aufrufe zu. Die Anwendung stürzt ab, weil die Anzahl der an die Anwendung gesendeten Health-Check-Aufrufe stark angestiegen ist.
**Auflösung**
Wenn die aktive Integritätsprüfung aktiviert ist, sendet jeder Envoy-Endpunkt des Downstreams (Client) Integritätsanfragen an jeden Endpunkt des Upstream-Clusters (Server), um Routing-Entscheidungen zu treffen. Folglich würde die Gesamtzahl der Anfragen zur Zustandsprüfung `number of client Envoys` \$1 `number of server Envoys` \$1 `active health check frequency` betragen.
Um dieses Problem zu beheben, ändern Sie die Häufigkeit der Zustandsprüfungen, wodurch sich das Gesamtvolumen der Zustandsprüfungen verringern würde. Zusätzlich zu aktiven Zustandsprüfungen ermöglicht App Mesh die Konfiguration der [Erkennung von Ausreißern](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html) als Mittel zur passiven Zustandsprüfung. Verwenden Sie die Ausreißererkennung, um anhand aufeinanderfolgender `5xx` Antworten zu konfigurieren, wann ein bestimmter Host entfernt werden soll.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
# Fehlerbehebung bei App Mesh Observability
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
In diesem Thema werden häufig auftretende Probleme beschrieben, die bei der App Mesh Mesh-Observability auftreten können.
## Es können keine AWS X-Ray Spuren für meine Anwendungen gefunden werden
**Symptome**
Ihre Anwendung in App Mesh zeigt keine X-Ray-Tracing-Informationen in der X-Ray-Konsole an oder APIs.
**Auflösung**
Um X-Ray in App Mesh verwenden zu können, müssen Sie die Komponenten korrekt konfigurieren, um die Kommunikation zwischen Ihrer Anwendung, den Sidecar-Containern und dem X-Ray-Dienst zu ermöglichen. Gehen Sie wie folgt vor, um sicherzustellen, dass X-Ray korrekt eingerichtet wurde:
+ Stellen Sie sicher, dass das App Mesh Virtual Node Listener-Protokoll nicht als `TCP` festgelegt ist.
+ Stellen Sie sicher, dass der X-Ray-Container, der mit Ihrer Anwendung bereitgestellt wird, den UDP-Port verfügbar macht `2000` und als Benutzer `1337` ausgeführt wird. Weitere Informationen finden Sie im [Amazon ECS X-Ray-Beispiel](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386) unter GitHub.
+ Vergewissern Sie sich, dass für den Envoy-Container die Ablaufverfolgung aktiviert ist. Wenn Sie das [App Mesh Envoy-Image](envoy.md) verwenden, können Sie X-Ray aktivieren, indem Sie die `ENABLE_ENVOY_XRAY_TRACING` Umgebungsvariable auf den Wert `1` und die `XRAY_DAEMON_PORT` Umgebungsvariable auf `2000` setzen.
+ Wenn Sie X-Ray in Ihrem Anwendungscode mit einem der [sprachspezifischen](https://docs.aws.amazon.com/xray/index.html) Instrumente ausgestattet haben, stellen Sie sicher SDKs , dass es korrekt konfiguriert ist, indem Sie den Anleitungen für Ihre Sprache folgen.
+ Wenn alle vorherigen Elemente korrekt konfiguriert sind, überprüfen Sie die X-Ray-Container-Protokolle auf Fehler und folgen Sie den Anweisungen unter [Problembehandlung AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html). Eine detailliertere Erklärung der X-Ray-Integration in App Mesh finden Sie unter [X-Ray mit App Mesh integrieren](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Die Envoy-Metriken für meine Anwendungen können in den CloudWatch Amazon-Metriken nicht angezeigt werden
**Symptome**
Ihre Anwendung in App Mesh gibt keine vom Envoy-Proxy generierten Metriken an CloudWatch Metriken aus.
**Auflösung**
Wenn Sie CloudWatch Metriken in App Mesh verwenden, müssen Sie mehrere Komponenten korrekt konfigurieren, um die Kommunikation zwischen Ihrem Envoy-Proxy, dem CloudWatch Agent-Sidecar und dem CloudWatch Metrik-Service zu ermöglichen. Gehen Sie wie folgt vor, um sicherzustellen, dass die CloudWatch Metriken für den Envoy-Proxy korrekt eingerichtet wurden:
+ Stellen Sie sicher, dass Sie das CloudWatch Agent-Image für App Mesh verwenden. Weitere Informationen finden Sie unter [App Mesh CloudWatch Agent](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent) on GitHub.
+ Stellen Sie sicher, dass Sie den CloudWatch Agenten für App Mesh entsprechend konfiguriert haben, indem Sie die plattformspezifischen Nutzungsanweisungen befolgen. Weitere Informationen finden Sie unter [App Mesh CloudWatch Agent](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage) on GitHub.
+ Wenn alle vorherigen Elemente korrekt konfiguriert sind, überprüfen Sie die CloudWatch Agent-Container-Protokolle auf Fehler und folgen Sie den Anweisungen unter [Fehlerbehebung beim CloudWatch Agenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Benutzerdefinierte Sampling-Regeln für AWS X-Ray Traces konnten nicht konfiguriert werden
**Symptome**
Ihre Anwendung verwendet X-Ray Tracing, aber Sie können keine Sampling-Regeln für Ihre Traces konfigurieren.
**Auflösung**
Da App Mesh Envoy derzeit keine **dynamische X-Ray-Sampling-Konfiguration** unterstützt, sind die folgenden Problemumgehungen verfügbar.
Wenn Ihre Envoy-Version `1.19.1` oder höher ist, haben Sie die folgenden Optionen.
+ Um nur die Sampling-Rate festzulegen, verwenden Sie die `XRAY_SAMPLING_RATE` Umgebungsvariable im Envoy-Container. Der Wert sollte als Dezimalzahl zwischen `0` und `1.00` (100%) angegeben werden. Weitere Informationen finden Sie unter [AWS X-Ray Variablen](envoy-config.md#envoy-xray-config).
+ Um die lokalisierten benutzerdefinierten Sampling-Regeln für den X-Ray Tracer zu konfigurieren, verwenden Sie die `XRAY_SAMPLING_RULE_MANIFEST` Umgebungsvariable, um einen Dateipfad im Envoy-Container-Dateisystem anzugeben. Weitere Informationen finden Sie unter [Sampling-Regeln](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling) im *AWS X-Ray Developer* Guide.
Wenn Ihre Envoy-Version älter ist`1.19.1`, gehen Sie wie folgt vor.
+ Verwenden Sie die `ENVOY_TRACING_CFG_FILE` Umgebungsvariable, um Ihre Sampling-Rate zu ändern. Weitere Informationen finden Sie unter [Envoy-Konfigurationsvariablen](envoy-config.md). Geben Sie eine benutzerdefinierte Tracing-Konfiguration an und definieren Sie lokale Sampling-Regeln. Weitere Informationen finden Sie unter [Envoy X-Ray-Konfiguration](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig).
+ Beispiel für eine benutzerdefinierte Ablaufverfolgungskonfiguration für die `ENVOY_TRACING_CFG_FILE` Umgebungsvariable:
```
tracing:
http:
name: envoy.tracers.xray
typedConfig:
"@type": type.googleapis.com/envoy.config.trace.v3.XRayConfig
segmentName: foo/bar
segmentFields:
origin: AWS::AppMesh::Proxy
aws:
app_mesh:
mesh_name: foo
virtual_node_name: bar
daemonEndpoint:
protocol: UDP
address: 127.0.0.1
portValue: 2000
samplingRuleManifest:
filename: /tmp/sampling-rules.json
```
+ Einzelheiten zur Konfiguration des Sampling-Regel-Manifests in der `samplingRuleManifest` Eigenschaft finden Sie unter [X-Ray SDK for Go konfigurieren](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
# Fehlerbehebung bei App Mesh-Sicherheit
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
In diesem Thema werden häufig auftretende Probleme im Zusammenhang mit der App Mesh-Sicherheit beschrieben.
## Es konnte keine Verbindung zu einem virtuellen Back-End-Dienst mit einer TLS-Client-Richtlinie hergestellt werden
**Symptome**
Beim Hinzufügen einer TLS-Client-Richtlinie zu einem virtuellen Dienst-Backend in einem virtuellen Knoten schlägt die Konnektivität zu diesem Backend fehl. Beim Versuch, Datenverkehr an den Back-End-Dienst zu senden, schlagen die Anfragen fehl und es wird ein `HTTP 503` Antwortcode und die folgende Fehlermeldung angezeigt:. `upstream connect error or disconnect/reset before headers. reset reason: connection failure`
**Auflösung**
Um die Ursache des Problems zu ermitteln, empfehlen wir, die Envoy-Proxy-Prozessprotokolle zu verwenden, um Ihnen bei der Diagnose des Problems zu helfen. Weitere Informationen finden Sie unter [Aktivieren Sie die Envoy-Debug-Protokollierung in Vorproduktionsumgebungen](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Ermitteln Sie anhand der folgenden Liste die Ursache des Verbindungsfehlers:
+ Stellen Sie sicher, dass die Konnektivität zum Back-End erfolgreich ist, indem Sie die unter genannten Fehler ausschließen. [Es konnte keine Verbindung zu einem virtuellen Service-Backend hergestellt werden](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend)
+ Suchen Sie in den Envoy-Prozessprotokollen nach den folgenden Fehlern (protokolliert auf Debug-Ebene).
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
Dieser Fehler wird durch einen oder mehrere der folgenden Gründe verursacht:
+ Das Zertifikat wurde nicht von einer der Zertifizierungsstellen signiert, die im Vertrauenspaket für TLS-Clientrichtlinien definiert sind.
+ Das Zertifikat ist nicht mehr gültig (abgelaufen).
+ Der alternative Subject Name (SAN) stimmt nicht mit dem angeforderten DNS-Hostnamen überein.
+ Stellen Sie sicher, dass das vom Back-End-Dienst angebotene Zertifikat gültig ist, dass es von einer der Zertifizierungsstellen in Ihrem Vertrauenspaket für TLS-Client-Richtlinien signiert ist und dass es die unter definierten Kriterien erfüllt. [Transport Layer Security (TLS)](tls.md)
+ Wenn der Fehler, den Sie erhalten, dem folgenden entspricht, bedeutet das, dass die Anfrage den Envoy-Proxy umgeht und die Anwendung direkt erreicht. Beim Senden von Datenverkehr ändern sich die Statistiken auf Envoy nicht, was darauf hindeutet, dass Envoy nicht auf dem Weg ist, den Verkehr zu entschlüsseln. Stellen Sie in der Proxykonfiguration des virtuellen Knotens sicher, dass der den richtigen Wert `AppPorts` enthält, auf den die Anwendung wartet.
```
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
```
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/). Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die [Richtlinien zur Meldung von AWS Sicherheitslücken](https://aws.amazon.com/security/vulnerability-reporting/).
## Es kann keine Verbindung zu einem virtuellen Back-End-Dienst hergestellt werden, wenn die Anwendung von TLS stammt
**Symptome**
Wenn eine TLS-Sitzung von einer Anwendung statt vom Envoy-Proxy aus gestartet wird, schlägt die Konnektivität zu einem virtuellen Back-End-Dienst fehl.
**Auflösung**
Dies ist ein bekanntes Problem. Weitere Informationen finden Sie unter [Funktionsanfrage: Problem mit der TLS-Aushandlung zwischen der Downstream-Anwendung und dem Upstream-Proxy](https://github.com/aws/aws-app-mesh-roadmap/issues/162) GitHub . In App Mesh wird die TLS-Herkunft derzeit vom Envoy-Proxy unterstützt, jedoch nicht von der Anwendung. Um die TLS-Origin-Unterstützung auf dem Envoy zu verwenden, deaktivieren Sie die TLS-Origination in der Anwendung. Dadurch kann der Envoy die Header der ausgehenden Anfragen lesen und die Anfrage über eine TLS-Sitzung an das entsprechende Ziel weiterleiten. Weitere Informationen finden Sie unter [Transport Layer Security (TLS)](tls.md).
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/). Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die [Richtlinien zur Meldung von AWS Sicherheitslücken](https://aws.amazon.com/security/vulnerability-reporting/).
## Es konnte nicht bestätigt werden, dass die Konnektivität zwischen Envoy-Proxys TLS verwendet
**Symptome**
Ihre Anwendung hat die TLS-Terminierung auf dem virtuellen Knoten oder dem virtuellen Gateway-Listener oder die TLS-Herkunft in der Backend-TLS-Client-Richtlinie aktiviert, aber Sie können nicht bestätigen, dass die Konnektivität zwischen Envoy-Proxys über eine über TLS ausgehandelte Sitzung erfolgt.
**Auflösung**
Die in dieser Lösung definierten Schritte verwenden die Envoy-Administrationsoberfläche und die Envoy-Statistiken. Hilfe bei der Konfiguration dieser Optionen finden Sie unter [Aktivieren Sie die Envoy-Proxy-Administrationsoberfläche](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) und. [Aktivieren Sie die Envoy DogStats D-Integration für das Offload von Metriken](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration) In den folgenden Statistikbeispielen wird der Einfachheit halber die Administrationsoberfläche verwendet.
+ Für den Envoy-Proxy, der die TLS-Terminierung durchführt:
+ Stellen Sie mit dem folgenden Befehl sicher, dass das TLS-Zertifikat in der Envoy-Konfiguration gebootet wurde.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
In der zurückgegebenen Ausgabe sollten Sie unter mindestens einen Eintrag `certificates[].cert_chain` für das Zertifikat sehen, das bei der TLS-Terminierung verwendet wurde.
+ Stellen Sie sicher, dass die Anzahl der erfolgreichen eingehenden Verbindungen zum Listener des Proxys genau der Anzahl der SSL-Handshakes plus der Anzahl der wiederverwendeten SSL-Sitzungen entspricht, wie die folgenden Beispielbefehle und Ausgaben zeigen.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
listener.0.0.0.0_15000.downstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
listener.0.0.0.0_15000.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
listener.0.0.0.0_15000.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
listener.0.0.0.0_15000.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
+ Für den Envoy-Proxy, der die TLS-Origination durchführt:
+ Stellen Sie mit dem folgenden Befehl sicher, dass der TLS Trust Store in der Envoy-Konfiguration gebootet wurde.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Unter sollten Sie mindestens einen Eintrag `certificates[].ca_certs` für die Zertifikate sehen, die bei der Validierung des Backend-Zertifikats bei der TLS-Erstellung verwendet wurden.
+ Stellen Sie sicher, dass die Anzahl der erfolgreichen ausgehenden Verbindungen zum Backend-Cluster genau der Anzahl der SSL-Handshakes plus der Anzahl der wiederverwendeten SSL-Sitzungen entspricht, wie die folgenden Beispielbefehle und Ausgaben zeigen.
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/). Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die [Richtlinien zur Meldung von AWS Sicherheitslücken](https://aws.amazon.com/security/vulnerability-reporting/).
## Fehlerbehebung bei TLS mit Elastic Load Balancing
**Symptome**
Beim Versuch, einen Application Load Balancer oder Network Load Balancer zur Verschlüsselung des Datenverkehrs zu einem virtuellen Knoten zu konfigurieren, können Konnektivitäts- und Load Balancer-Zustandsprüfungen fehlschlagen.
**Auflösung**
Um die Ursache des Problems zu ermitteln, müssen Sie Folgendes überprüfen:
+ Damit der Envoy-Proxy die TLS-Terminierung durchführt, müssen Sie jegliche Fehlkonfiguration ausschließen. Folgen Sie den oben angegebenen Schritten in der. [Es konnte keine Verbindung zu einem virtuellen Back-End-Dienst mit einer TLS-Client-Richtlinie hergestellt werden](#ts-security-tls-client-policy)
+ Für den Load Balancer müssen Sie sich die Konfiguration des ansehen `TargetGroup:`
+ Stellen Sie sicher, dass der `TargetGroup` Port mit dem definierten Listener-Port des virtuellen Knotens übereinstimmt.
+ Stellen Sie bei Application Load Balancers, die TLS-Verbindungen über HTTP zu Ihrem Dienst herstellen, sicher, dass das `TargetGroup` Protokoll auf eingestellt ist. `HTTPS` Wenn Integritätsprüfungen verwendet werden, stellen Sie sicher, dass diese Option auf `HTTPS` eingestellt `HealthCheckProtocol` ist.
+ Stellen Sie bei Network Load Balancers, die TLS-Verbindungen über TCP zu Ihrem Dienst herstellen, sicher, dass das `TargetGroup` Protokoll auf `TLS` eingestellt ist. Wenn Integritätsprüfungen verwendet werden, stellen Sie sicher, dass diese Option auf `TCP` eingestellt `HealthCheckProtocol` ist.
**Anmerkung**
Alle Aktualisierungen, die `TargetGroup` eine Änderung des `TargetGroup` Namens erfordern.
Wenn dies richtig konfiguriert ist, sollte Ihr Load Balancer mithilfe des für den Envoy-Proxy bereitgestellten Zertifikats eine sichere Verbindung zu Ihrem Dienst bereitstellen.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/). Wenn Sie glauben, eine Sicherheitslücke gefunden zu haben, oder Fragen zur Sicherheit von App Mesh haben, lesen Sie die [Richtlinien zur Meldung von AWS Sicherheitslücken](https://aws.amazon.com/security/vulnerability-reporting/).
# Fehlerbehebung bei App Mesh Kubernetes
**Wichtig**
Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag [Migration von AWS App Mesh zu Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect).
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 mit der Kubernetes Custom Resource Definition (CRD) erstellt, aber die Ressourcen, die Sie erstellt haben, sind in App Mesh nicht sichtbar, wenn Sie das oder verwenden. AWS-Managementkonsole APIs
**Auflösung**
Die wahrscheinliche Ursache ist ein Fehler im Kubernetes-Controller für App Mesh. Weitere Informationen finden Sie unter [Problembehandlung](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md) 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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 injiziert wurde, mit dem 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](troubleshooting-setup.md#ts-setup-grpc-error-codes) 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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 AWS Cloud Map GitHub den Pods werden registered/deregistered in Kubernetes nicht auto](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) aktiviert. Aufgrund der Beziehung zwischen Pods, virtuellen App Mesh-Knoten und AWS Cloud Map Ressourcen kann der [App Mesh Mesh-Controller für Kubernetes](https://github.com/aws/aws-app-mesh-controller-for-k8s) 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.
Um dieses Problem zu beheben, gehen Sie wie folgt vor:
+ 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 unter[Es kann nicht festgestellt werden, wo ein Pod für eine App Mesh Mesh-Ressource ausgeführt wird](#ts-kubernetes-where-pod-running).
+ 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## Client Envoys können bei deaktiviertem App Mesh Envoy Management Service nicht mit dem App Mesh Envoy Management Service kommunizieren IMDSv1
**Symptome**
Wenn deaktiviert `IMDSv1` ist, können Client-Envoys nicht mit der App Mesh-Steuerebene (Envoy Management Service) kommunizieren. `IMDSv2`Die 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html).
+ 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](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) für Dienstkonten.
Wenn Ihr Problem immer noch nicht gelöst ist, erwägen Sie, ein [GitHub Problem](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).
## IRSA funktioniert nicht im Anwendungscontainer, 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](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) zu öffnen, oder wenden Sie sich an den [AWS Support](https://aws.amazon.com/premiumsupport/).