Drosselungslogik für Amazon ECS-Services

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 Dienst wiederholt nicht in den RUNNING Status wechseln (also direkt von einem in einen PENDING STOPPED Status wechseln), wird die Zeit zwischen aufeinanderfolgenden Neustartversuchen schrittweise auf maximal 27 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 Amazon ECS-Service mithilfe der Konsole.

Im Folgenden sind einige der häufigsten Ursachen aufgeführt, die diese Logik auslösen. Wir empfehlen, dass Sie manuelle Maßnahmen ergreifen, um das Problem zu beheben:

• 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 Fehlerbehebung beim Docker API error (500): devmapper in Amazon ECS.

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.