Fehlerbehebung bei der Einrichtung von App Mesh

In diesem Thema werden häufige Probleme beschrieben, die bei der Einrichtung von App Mesh auftreten können.

Envoy-Container-Image kann nicht abgerufen werden

Symptome

Sie erhalten die folgende Fehlermeldung in einer Amazon-ECS-Aufgabe. Die Amazon-ECR-Konto-ID und -Region in der folgenden 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 über die Berechtigung zur Kommunikation mit Amazon ECR verfügt 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 Anweisungen:

{
  "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 behoben ist, sollten Sie ein GitHub Problem öffnen oder sich an AWS den -Support wenden.

Es kann keine Verbindung zum App Mesh Envoy Management Service hergestellt werden

Symptome

Ihr Envoy-Proxy kann keine Verbindung zum App Mesh Envoy-Verwaltungsservice herstellen. Sie sehen:

• Verbindung zurückgewiesene Fehler

• Verbindungs-Timeouts

• Fehler beim Beheben des Verwaltungsservice-Endpunkts von App Mesh Envoy

• gRPC-Fehler

Auflösung

Stellen Sie sicher, dass Ihr Envoy-Proxy Zugriff auf das Internet oder einen privaten VPC-Endpunkt hat und dass Ihre Sicherheitsgruppen ausgehenden Datenverkehr auf Port 443 zulassen. Die öffentlichen Endpunkte des Envoy Management Service 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

Mit dem folgenden Befehl können Sie Ihre Verbindung zu debuggen. Dadurch wird eine gültige, aber leere gRPC-Anforderung 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-bezogenen Fehlern finden Sie unter Fehler in Envoy vom App Mesh Envoy Management Service getrennt mit Fehlertext.

grpc-status: 16
grpc-message: Missing Authentication Token

Wenn Ihr Problem immer noch nicht behoben ist, sollten Sie ein GitHub Problem öffnen oder sich an AWS den -Support wenden.

Envoy wurde mit Fehlertext vom App Mesh Envoy Management Service getrennt

Symptome

Ihr Envoy-Proxy kann keine Verbindung zum App Mesh Envoy-Verwaltungsservice herstellen und seine Konfiguration empfangen. Ihre Envoy-Proxy-Protokolle enthalten einen Protokolleintrag wie den folgenden.

gRPC config stream closed: gRPC status code, message

Auflösung

In den meisten Fällen sollte der Nachrichtenteil des Protokolls auf das Problem hinweisen. In der folgenden Tabelle sind die gängigsten gRPC-Statuscodes aufgeführt, die Sie möglicherweise sehen, ihre Ursachen und ihre Lösungen.

gRPC-Statuscode	Ursache	Auflösung
0	Korrekte Trennung vom Envoy-Verwaltungsservice.	Es gibt kein Problem. App Mesh trennt gelegentlich Envoy-Proxys mit diesem Statuscode. Envoy stellt erneut eine Verbindung 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 erneut, um sicherzustellen, dass sie den entsprechenden Namen der App Mesh-Ressource hat, für die sie steht. Wenn Ihre App-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 ist nicht autorisiert, eine Aktion auszuführen, z. B. eine Verbindung zum Envoy-Verwaltungsservice herzustellen oder zugehörige Ressourcen abzurufen.	Stellen Sie sicher, dass Sie eine IAM-Richtlinie mit den entsprechenden Richtlinienanweisungen für App Mesh und andere -Services erstellen und diese Richtlinie an den IAM-Benutzer oder die IAM-Rolle anfügen, die Ihr Envoy-Proxy verwendet, um eine Verbindung zum Envoy-Verwaltungsservice herzustellen.
8	Die Anzahl der Envoy-Proxys für eine bestimmte App-Mesh-Ressource überschreitet das Servicekontingent auf Kontoebene.	App Mesh service quotas Informationen zu Standard-Kontokontingenten und zum Anfordern einer Kontingenterhöhung finden Sie unter .
16	Der Envoy-Proxy hat keine gültigen Authentifizierungsanmeldeinformationen für AWS.	Stellen Sie sicher, dass Envoy über die entsprechenden Anmeldeinformationen verfügt, um über einen IAM-Benutzer oder eine IAM-Rolle eine Verbindung zu -AWSServices herzustellen. Ein bekanntes Problem, #24136, in Envoy für Version v1.24 und früher kann die Anmeldeinformationen nicht abrufen, wenn der Envoy-Prozess über 1024 Dateideskriptoren verwendet. Dies geschieht, wenn Envoy ein hohes Datenverkehrsvolumen bedient. Sie können dieses Problem bestätigen, indem Sie Envoy-Protokolle auf Debug-Ebene auf den Text „“ überprüfenA libcurl function was given a bad argument. Um dieses Problem zu beheben, aktualisieren Sie auf Envoy Version v1.25.1.0-prod oder höher.

Sie können die Statuscodes und Nachrichten von Ihrem Envoy-Proxy mit Amazon CloudWatch Insights mithilfe der folgenden Abfrage beobachten:

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 behoben ist, sollten Sie ein GitHub Problem öffnen.

Fehler bei der Zustandsprüfung des Envoy-Containers, der Bereitschafts-Sonde oder der Liveliness-Sonde

Symptome

Ihr Envoy-Proxy schlägt Zustandsprüfungen in einer Amazon-ECS-Aufgabe, einer Amazon EC2-Instance oder einem Kubernetes-Pod fehl. Sie fragen beispielsweise die Envoy-Verwaltungsschnittstelle 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 der Korrekturmaßnahmen, abhängig vom Status, der vom Envoy-Proxy zurückgegeben wird.

• PRE_INITIALIZING oder INITIALIZING – Der Envoy-Proxy muss noch eine Konfiguration empfangen oder kann keine Verbindung zum App Mesh Envoy Management Service herstellen und abrufen. Der Envoy erhält möglicherweise einen Fehler vom Envoy-Verwaltungsservice, wenn er versucht, eine Verbindung herzustellen. Weitere Informationen finden Sie unter Fehler in Envoy wurde mit Fehlertext vom App Mesh Envoy Management Service getrennt.

• DRAINING – Der Envoy-Proxy hat damit begonnen, Verbindungen als Reaktion auf eine - /healthcheck/fail oder -/drain_listenersAnforderung auf der Envoy-Verwaltungsschnittstelle zu leeren. Wir empfehlen nicht, diese Pfade auf der Verwaltungsschnittstelle aufzurufen, es sei denn, Sie beenden Ihre Amazon-ECS-Aufgabe, Ihre Amazon EC2-Instance oder Ihren Kubernetes-Pod.

Wenn Ihr Problem immer noch nicht behoben ist, sollten Sie ein GitHub Problem öffnen oder sich an AWS den -Support wenden.

Zustandsprüfung vom Load Balancer zum Mesh-Endpunkt schlägt fehl

Symptome

Ihr Mesh-Endpunkt wird durch die Container-Zustandsprüfung oder Bereitschafts-Sonde als fehlerfrei angesehen, aber die Zustandsprüfung vom Load Balancer zum Mesh-Endpunkt schlägt fehl.

Auflösung

Führen Sie die folgenden Schritte aus, um das Problem zu beheben.

• Stellen Sie sicher, dass die Sicherheitsgruppe, die Ihrem Mesh-Endpunkt zugeordnet ist, eingehenden Datenverkehr auf dem Port akzeptiert, den Sie für Ihre Zustandsprüfung konfiguriert haben.

• Stellen Sie sicher, dass die Zustandsprüfung bei manueller Anforderung konsistent erfolgreich ist, z. B. von einem Bastion-Host innerhalb Ihrer VPC.

• Wenn Sie eine Zustandsprüfung für einen virtuellen Knoten konfigurieren, empfehlen wir, einen Endpunkt für die Zustandsprüfung in Ihrer Anwendung zu implementieren, z. B. /ping für HTTP. Dadurch wird sichergestellt, dass sowohl der Envoy-Proxy als auch Ihre Anwendung vom Load Balancer aus weitergeleitet werden können.

• Sie können je nach den benötigten Funktionen jeden Elastic Load Balancer-Typ für den virtuellen Knoten verwenden. Weitere Informationen finden Sie unter Elastic Load Balancing-Funktionen.

• Wenn Sie eine Zustandsprüfung für ein virtuelles Gateway konfigurieren, empfehlen wir, einen Network Load Balancer mit einer TCP- oder TLS-Zustandsprüfung am Listener-Port des virtuellen Gateways zu verwenden. Dadurch wird sichergestellt, dass der virtuelle Gateway-Listener gestartet wird und Verbindungen akzeptieren kann.

Wenn Ihr Problem immer noch nicht behoben ist, sollten Sie ein GitHub Problem öffnen oder sich an denAWS Support wenden.

Das virtuelle Gateway akzeptiert keinen Datenverkehr über Ports 1024 oder weniger

Symptome

Ihr virtuelles Gateway akzeptiert keinen Datenverkehr auf Port 1024 oder weniger, akzeptiert jedoch Datenverkehr 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 wird in Ihren Protokollen Text ähnlich dem folgenden Text angezeigt, in dem ein Fehler beim Binden an einen privilegierten Port beschrieben wird:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_<port num>: cannot bind '0.0.0.0:<port num>': Permission denied

Auflösung

Um das Problem zu beheben, muss der für das Gateway angegebene Benutzer über die Linux-Funktion verfügenCAP_NET_BIND_SERVICE. Weitere Informationen finden Sie unter Funktionen im Linux-Programmierhandbuch, unter Linux-Parameter in ECS-Aufgabendefinitionsparametern und unter Festlegen von Funktionen für einen Container in der Kubernetes-Dokumentation.

Wichtig

Fargate muss einen Portwert größer als 1024 verwenden.

Wenn Ihr Problem immer noch nicht behoben ist, sollten Sie ein GitHub Problem öffnen oder sich an AWS den -Support wenden.