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.
# Bewährte Methoden für 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).
Um das Ziel zu erreichen, dass bei geplanten Bereitstellungen und beim ungeplanten Ausfall einiger Hosts keine fehlgeschlagenen Anfragen mehr gestellt werden, wird in den Best Practices in diesem Thema die folgende Strategie implementiert:
+ Erhöhen Sie die Wahrscheinlichkeit, dass eine Anfrage aus Sicht der Anwendung erfolgreich sein wird, indem Sie eine sichere Standard-Wiederholungsstrategie verwenden. Weitere Informationen finden Sie unter [Instrumentieren Sie alle Routen mit Wiederholungsversuchen](#route-retries).
+ Erhöhen Sie die Wahrscheinlichkeit, dass eine erneut versuchte Anfrage erfolgreich ist, indem Sie die Wahrscheinlichkeit maximieren, dass die wiederholte Anfrage an ein echtes Ziel gesendet wird. Weitere Informationen finden Sie unter [Passen Sie die Bereitstellungsgeschwindigkeit an](#reduce-deployment-velocity), [Skalieren Sie vor der Skalierung](#scale-out) und [Implementieren Sie Integritätsprüfungen für Container](#health-checks).
Um Fehler deutlich zu reduzieren oder zu vermeiden, empfehlen wir Ihnen, die Empfehlungen in allen folgenden Verfahren zu implementieren.
## Instrumentieren Sie alle Routen mit Wiederholungsversuchen
Konfigurieren Sie alle virtuellen Dienste so, dass sie einen virtuellen Router verwenden, und legen Sie eine Standardrichtlinie für Wiederholungsversuche für alle Routen fest. Dadurch werden fehlgeschlagene Anfragen vermieden, indem ein Host erneut ausgewählt und eine neue Anfrage gesendet wird. Für Wiederholungsrichtlinien empfehlen wir einen Wert von mindestens zwei für und die Angabe der folgenden Optionen für `maxRetries` jeden Typ von Wiederholungsereignis in jedem Routentyp, der den Wiederholungsereignistyp unterstützt:
+ **TCP —** `connection-error`
+ **HTTP und HTTP/2** — `stream-error` und `gateway-error`
+ **gRPC** — `cancelled` und `unavailable`
Andere Wiederholungsereignisse müssen auf einer bestimmten case-by-case Grundlage betrachtet werden, da sie möglicherweise nicht sicher sind, z. B. wenn die Anfrage nicht idempotent ist. Sie müssen Werte berücksichtigen und testen`perRetryTimeout`, die einen angemessenen Kompromiss zwischen der maximalen Latenz einer Anfrage (`maxRetries`\$1`perRetryTimeout`) `maxRetries` und der höheren Erfolgsquote bei mehreren Wiederholungen eingehen. Wenn Envoy versucht, eine Verbindung zu einem Endpunkt herzustellen, der nicht mehr vorhanden ist, sollten Sie außerdem damit rechnen, dass diese Anfrage die gesamte Menge verbraucht. `perRetryTimeout` Informationen zur Konfiguration einer Wiederholungsrichtlinie finden Sie unter dem Protokoll, das Sie weiterleiten möchten, [Eine Route erstellen](routes.md#create-route) und wählen Sie es dann aus.
**Anmerkung**
Wenn Sie am oder nach dem 29. Juli 2020 eine Route implementiert und keine Wiederholungsrichtlinie angegeben haben, hat App Mesh möglicherweise automatisch eine Standard-Wiederholungsrichtlinie erstellt, die der vorherigen Richtlinie für jede Route ähnelt, die Sie am oder nach dem 29. Juli 2020 erstellt haben. Weitere Informationen finden Sie unter [Standardrichtlinie für die Wiederholung von Routen](envoy-defaults.md#default-retry-policy).
## Passen Sie die Bereitstellungsgeschwindigkeit an
Reduzieren Sie bei fortlaufenden Bereitstellungen die allgemeine Bereitstellungsgeschwindigkeit. Standardmäßig konfiguriert Amazon ECS eine Bereitstellungsstrategie mit mindestens 100 Prozent fehlerfreien Aufgaben und 200 Prozent Gesamtaufgaben. Bei der Bereitstellung führt dies zu zwei Punkten mit hoher Abweichung:
+ Die 100-prozentige Flottengröße neuer Aufgaben kann für die Beauftragten sichtbar sein, bevor sie bereit sind, Anfragen zu bearbeiten (Informationen zu Abhilfemaßnahmen finden Sie unter[Implementieren Sie Integritätsprüfungen für Container](#health-checks)).
+ Die 100-prozentige Flottengröße alter Aufgaben kann für Envoys sichtbar sein, während die Aufgaben abgeschlossen werden.
Bei der Konfiguration mit diesen Einsatzbeschränkungen können Container-Orchestratoren in einen Zustand übergehen, in dem sie gleichzeitig alle alten Ziele verbergen und alle neuen Ziele sichtbar machen. Da Ihre Envoy-Datenebene letztendlich konsistent ist, kann dies zu Perioden führen, in denen die in Ihrer Datenebene sichtbaren Ziele aus Sicht des Orchestrators voneinander abweichen. Um dem entgegenzuwirken, empfehlen wir, mindestens 100 Prozent fehlerfreie Aufgaben beizubehalten, die Gesamtzahl der Aufgaben jedoch auf 125 Prozent zu reduzieren. Dadurch werden Abweichungen verringert und die Zuverlässigkeit von Wiederholungsversuchen verbessert. Wir empfehlen die folgenden Einstellungen für verschiedene Container-Laufzeiten:
**Amazon ECS**
Wenn Ihr Service eine gewünschte Anzahl von zwei oder drei hat, legen Sie `maximumPercent` diese auf 150 Prozent fest. Andernfalls legen Sie `maximumPercent` den Wert auf 125 Prozent fest.
**Kubernetes**
Konfigurieren Sie Ihre Bereitstellungen und setzen Sie `maxUnavailable` sie auf 0 Prozent und `maxSurge` auf 25 Prozent. `update strategy` [Weitere Informationen zu Bereitstellungen finden Sie in der Dokumentation zu Kubernetes-Bereitstellungen.](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
## Skalieren Sie vor der Skalierung
Sowohl die horizontale Skalierung als auch die Skalierung können zu einer gewissen Wahrscheinlichkeit führen, dass Anfragen bei Wiederholungsversuchen fehlschlagen. Es gibt zwar Aufgabenempfehlungen, die das Scale-Out verringern, aber die einzige Empfehlung für die Skalierung besteht darin, den Prozentsatz skalierter Aufgaben zu einem beliebigen Zeitpunkt zu minimieren. Wir empfehlen Ihnen, eine Bereitstellungsstrategie zu verwenden, die neue Amazon ECS-Aufgaben oder Kubernetes-Bereitstellungen skaliert, bevor alte Aufgaben oder Bereitstellungen skaliert werden. Durch diese Skalierungsstrategie wird Ihr prozentualer Anteil an skalierten Aufgaben oder Bereitstellungen niedriger gehalten, während die Geschwindigkeit beibehalten wird. Diese Vorgehensweise gilt sowohl für Amazon ECS-Aufgaben als auch für Kubernetes-Bereitstellungen.
## Implementieren Sie Integritätsprüfungen für Container
Im Scale-Up-Szenario sind Container in einer Amazon ECS-Aufgabe möglicherweise nicht in der richtigen Reihenfolge und reagieren zunächst möglicherweise nicht. Wir empfehlen die folgenden Vorschläge für verschiedene Container-Laufzeiten:
**Amazon ECS**
Um dies zu vermeiden, empfehlen wir, Container-Integritätsprüfungen und die Reihenfolge der Container-Abhängigkeiten zu verwenden, um sicherzustellen, dass Envoy läuft und fehlerfrei ist, bevor Container, für die eine ausgehende Netzwerkverbindung erforderlich ist, gestartet werden. [Informationen zur korrekten Konfiguration eines Anwendungscontainers und eines Envoy-Containers in einer Aufgabendefinition finden Sie unter Container-Abhängigkeit.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html#example_task_definition-containerdependency)
**Kubernetes**
Keine, da die [Verfügbarkeits- und Bereitschaftstests](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) von Kubernetes bei der Registrierung und Deregistrierung von AWS Cloud Map Instanzen im [App](https://github.com/aws/aws-app-mesh-controller-for-k8s) Mesh Mesh-Controller für Kubernetes nicht berücksichtigt werden. [Weitere Informationen finden Sie in Ausgabe \$1132. GitHub ](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/132)
## Optimieren Sie die DNS-Auflösung
Wenn Sie DNS für die Diensterkennung verwenden, müssen Sie bei der Konfiguration Ihrer Meshes unbedingt das entsprechende IP-Protokoll auswählen, um die DNS-Auflösung zu optimieren. App Mesh unterstützt sowohl als auch`IPv6`, `IPv4` und Ihre Wahl kann sich auf die Leistung und Kompatibilität Ihres Dienstes auswirken. Wenn Ihre Infrastruktur dies nicht unterstützt`IPv6`, empfehlen wir Ihnen, eine IP-Einstellung anzugeben, die auf Ihre Infrastruktur abgestimmt ist, anstatt sich auf das `IPv6_PREFERRED` Standardverhalten zu verlassen. Das `IPv6_PREFERRED` Standardverhalten kann die Serviceleistung beeinträchtigen.
+ **IPv6\$1PREFERRED** — Dies ist die Standardeinstellung. Envoy führt zuerst eine DNS-Suche nach IPv6 Adressen durch und greift darauf zurück, `IPv4` wenn keine `IPv6` Adressen gefunden werden. Dies ist von Vorteil, wenn Ihre Infrastruktur in erster Linie Unterstützung bietet`IPv6`, aber `IPv4` Kompatibilität benötigt.
+ **IPv4\$1PREFERRED** — Envoy sucht zuerst nach `IPv4` Adressen und greift auf Adressen zurück, `IPv6` wenn keine `IPv4` Adressen verfügbar sind. Verwenden Sie diese Einstellung, wenn Ihre Infrastruktur hauptsächlich unterstützt, `IPv4` aber über eine gewisse `IPv6` Kompatibilität verfügt.
+ **IPv6\$1ONLY** — Wählen Sie diese Option, wenn Ihre Dienste ausschließlich `IPv6` Datenverkehr unterstützen. Envoy führt nur DNS-Suchen nach `IPv6` Adressen durch und stellt so sicher, dass der gesamte Datenverkehr weitergeleitet wird. `IPv6`
+ **IPv4\$1ONLY** — Wählen Sie diese Einstellung, wenn Ihre Dienste ausschließlich Traffic unterstützen. `IPv4` Envoy führt nur DNS-Suchen nach `IPv4` Adressen durch und stellt so sicher, dass der gesamte Datenverkehr weitergeleitet wird. `IPv4`
Sie können IP-Versionspräferenzen sowohl auf Mesh-Ebene als auch auf Ebene virtueller Knoten festlegen, wobei die Einstellungen für virtuelle Knoten die Einstellungen auf Mesh-Ebene überschreiben.
Weitere Informationen finden Sie unter [Service Meshes](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html) und [virtuelle](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html) Knoten.