Service-Drosselungslogik - Amazon Elastic Container Service

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.

Service-Drosselungslogik

Der Amazon-ECS-Service-Scheduler enthält eine Logik, die eine Begrenzung einführt, wie oft Serviceaufgaben gestartet werden, wenn sie wiederholt nicht gestartet werden können.

Wenn Aufgaben für einen Service wiederholt nicht in den RUNNING-Status übergehen (direkt von einem PENDING- zu einem STOPPED-Status), wird die Zeit zwischen den folgenden Neustartversuchen schrittweise bis zu einem Maximum von 15 Minuten erhöht. Diese Höchstdauer kann sich in Zukunft ändern. Durch dieses Verhalten werden die Auswirkungen von fehlschlagenden Aufgaben auf Ihre Amazon-ECS-Cluster-Ressourcen oder die Fargate-Infrastrukturkosten reduziert. Wenn Ihr Service die Drosselungslogik initiiert, erhalten Sie die folgende Service-Ereignismeldung:

(service service-name) is unable to consistently start tasks successfully.

Amazon ECS hindert einen fehlgeschlagenen Service niemals daran, es erneut zu versuchen. Es wird auch nicht versucht, es auf andere Weise zu verändern, außer der Erhöhung der Zeit zwischen den Neustarts. Die Service-Drosselungslogik stellt keine vom Benutzer einstellbaren Parameter bereit.

Wenn Sie Ihren Service auf eine neue Aufgabendefinition aktualisieren, kehrt der Service sofort zu einem normalen, ungedrosselten Zustand zurück. Weitere Informationen finden Sie unter Aktualisieren eines Services mit der Konsole.

Im Folgenden werden einige häufige Ursachen genannt, die diese Logik auslösen:

  • Fehlende Ressourcen für das Hosten Ihrer Aufgabe, z. B. Ports, Speicher oder CPU-Einheiten in Ihrem Cluster. In diesem Fall wird auch eine Benachrichtigung über unzureichende Ressourcen angezeigt.

  • Der Amazon-ECS-Container-Agent kann Ihr Docker-Image für die Aufgabe nicht abrufen. Dies kann an einem ungültigen Container-Image-Namen, -Image oder -Tag oder an einem Mangel an privater Registry-Authentifizierung oder -Berechtigungen liegen. In diesem Fall wird auch CannotPullContainerError in Ihren Fehlern für gestoppte Aufgaben angezeigt.

  • Ungenügender Speicherplatz in Ihrer Container-Instance zum Erstellen des Containers. In diesem Fall wird auch CannotCreateContainerError in Ihren Fehlern für gestoppte Aufgaben angezeigt. Weitere Informationen finden Sie unter CannotCreateContainerError: API error (500): devmapper.

Wichtig

Aufgaben, die angehalten werden, nachdem sie den RUNNING-Status erreicht haben, starten weder die Drosselungslogik noch die zugehörige Service-Ereignismeldung. Wenn beispielsweise die Zustandsprüfungen von Elastic Load Balancing für einen Service fehlgeschlagen sind, wird eine Aufgabe als fehlerhaft eingestuft und Amazon ECS deregistriert sie und stoppt die Aufgabe. Zu diesem Zeitpunkt werden die Aufgaben nicht gedrosselt. Auch wenn ein Container-Befehl einer Aufgabe sofort mit einem Beendigungscode ungleich Null beendet wird, erhält die Aufgabe bereits den RUNNING-Status. Aufgaben, die sofort fehlschlagen, weil Befehlsfehler nicht die Drosselung oder die Serviceereignismeldung verursachen.