Amazon-ECS-Dienstleistungen - 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.

Amazon-ECS-Dienstleistungen

Sie können einen Amazon-ECS-Service verwenden, um eine bestimmte Anzahl von Instances einer Aufgabendefinition gleichzeitig in einem Amazon-ECS-Cluster auszuführen und zu verwalten. Wenn eine Ihrer Aufgaben ausfällt oder anhält, startet der Amazon-ECS-Service-Scheduler eine andere Instance Ihrer Aufgabendefinition, um sie zu ersetzen. Dies trägt dazu bei, dass die von Ihnen gewünschte Anzahl von Aufgaben im Service erhalten bleibt.

Sie können Ihren Service optional auch hinter einem Load Balancer ausführen. Der Load Balancer verteilt den Datenverkehr über die mit dem Service verbundenen Aufgaben.

Service-Scheduler-Konzepte

Wir empfehlen die Verwendung des Service-Schedulers für lang laufende zustandslose Services und Anwendungen. Der Service Scheduler stellt sicher, dass die von Ihnen angegebene Einplanungsstrategie einhalten wird, und plant Aufgaben neu ein, wenn eine Aufgabe fehlschlägt. Wenn beispielsweise die zugrunde liegende Infrastruktur ausfällt, plant der Service-Scheduler eine Aufgabe neu ein. Sie können Strategien zur Aufgabenplatzierung und Einschränkungen verwenden, um die Platzierung und Beendigung von Aufgaben durch den Scheduler anzupassen. Wenn eine Aufgabe in einem Service gestoppt wird, startet der Scheduler eine neue Aufgabe, die diese ersetzt. Dieser Vorgang wird so lange fortgesetzt, bis Ihr Service die gewünschte Anzahl von Aufgaben erreicht hat, basierend auf der Planungsstrategie, die der Service verwendet. Die Planungsstrategie des Services wird auch als Servicetyp bezeichnet.

Der Service-Scheduler ersetzt auch Aufgaben, die nach einem Fehlschlagen einer Container-Zustandsprüfung oder einer Load-Balancer-Zielgruppen-Zustandsprüfung als fehlerhaft eingestuft wurden. Dieser Ersatz hängt von den Parametern maximumPercent und desiredCount der Servicedefinition ab. Wenn eine Aufgabe als fehlerhaft markiert ist, startet der Service-Scheduler zunächst eine Ersatzaufgabe. Wenn die Ersatzaufgabe den Zustand HEALTHY hat, stoppt der Service-Scheduler die fehlerhafte Aufgabe. Wenn die Ersatzaufgabe den Zustand UNHEALTHY hat, stoppt der Scheduler entweder die fehlerhafte Ersatzaufgabe oder die vorhandene fehlerhafte Aufgabe, sodass die Gesamtanzahl der Aufgaben auf einen Wert gleich desiredCount eingestellt wird. Wenn der Parameter maximumPercent den Scheduler daran hindert, zuerst eine Ersatzaufgabe zu starten, stoppt der Scheduler fehlerhafte Aufgaben einzeln nach dem Zufallsprinzip, um Kapazität freizugeben, und startet dann eine Ersatzaufgabe. Der Start- und Stoppvorgang wird fortgesetzt, bis alle fehlerhaften Aufgaben durch fehlerfreie Aufgaben ersetzt wurden. Sobald alle fehlerhaften Aufgaben ersetzt wurden und nur noch fehlerfreie Aufgaben ausgeführt werden, werden, wenn die Gesamtzahl der Aufgaben desiredCount übersteigt, die fehlerfreien Aufgaben nach dem Zufallsprinzip angehalten, bis die Gesamtzahl der Aufgaben gleich desiredCount ist. Weitere Informationen zu maximumPercent und desiredCount finden Sie unter Servicedefinitionsparamater.

Anmerkung

Dieses Verhalten gilt nicht für Aufgaben, die von Services ausgeführt und verwaltet werden, die den Bereitstellungstyp fortlaufende Aktualisierung verwenden. Während einer fortlaufenden Aktualisierung beendet der Service-Scheduler zuerst fehlerhafte Aufgaben und startet dann Ersatzaufgaben.

Der Service-Scheduler enthält eine Logik, die die Häufigkeit des Neustarts von Aufgaben drosselt, wenn Aufgaben wiederholt nicht gestartet werden. Wenn eine Aufgabe gestoppt wird, ohne dass sie in einen RUNNING-Status eingetreten ist, beginnt der Service-Scheduler, die Startversuche zu verlangsamen, und sendet eine Service-Ereignismeldung aus. Dieses Verhalten verhindert, dass unnötige Ressourcen für fehlgeschlagene Aufgaben verwendet werden, bevor Sie das Problem beheben können. Nachdem der Service aktualisiert wurde, nimmt der Service-Scheduler sein normales Planungsverhalten wieder auf. Weitere Informationen finden Sie unter Service-Drosselungslogik und Service-Ereignismeldungen.

Es gibt zwei Strategien für Service-Scheduler:

  • REPLICA: Die Replica-Einplanungsstrategie platziert und die gewünschte Anzahl von Aufgaben in Ihrem Cluster und behält sie bei. Standardmäßig verteilt der Service-Scheduler Aufgaben über Availability Zones. Mit Aufgabenplatzierungsstrategien und -bedingungen können Sie festlegen, wie Aufgaben platziert und beendet werden. Weitere Informationen finden Sie unter Replikat.

  • DAEMON: Die Daemon-Einplanungsstrategie stellt genau eine Aufgabe auf jeder aktiven Container-Instance bereit, die alle von Ihnen in Ihrem Cluster angegebenen Platzierungsbedingungen für die Aufgaben erfüllt. Bei Verwendung dieser Strategie ist es nicht erforderlich, eine gewünschte Anzahl von Aufgaben oder eine Aufgabenplatzierungsstrategie anzugeben oder Auto-Scaling-Richtlinien zu verwenden. Weitere Informationen finden Sie unter Daemon.

    Anmerkung

    Fargate-Aufgaben unterstützen die DAEMON-Einplanungsstrategie nicht.

Daemon

Die Daemon-Planungsstrategie stellt genau eine Aufgabe auf jeder aktiven Container-Instance bereit, die alle Platzierungseinschränkungen für die Aufgaben in Ihrem Cluster erfüllt. Der Service-Scheduler wertet auch die Aufgabenplatzierungsbeschränkungen für laufende Aufgaben aus und stoppt Aufgaben, die die Platzierungsbeschränkungen nicht erfüllen. Wenn Sie diese Strategie verwenden, müssen Sie keine gewünschte Anzahl von Aufgaben oder eine Aufgabenplatzierungsstrategie angeben oder Service-Auto-Scaling-Richtlinien verwenden.

Amazon ECS reserviert Container-Instance-Computing-Ressourcen, einschließlich CPU, Arbeitsspeicher und Netzwerkschnittstellen für die Daemon-Aufgaben. Wenn Sie einen Daemon-Service in einem Cluster mit anderen Replikat-Services starten, priorisiert Amazon ECS die Daemon-Aufgabe. Das bedeutet, dass die Daemon-Aufgabe die erste Aufgabe ist, die auf den Instances gestartet wird, und die letzte Aufgabe, die beendet wird. Diese Strategie stellt sicher, dass die Ressourcen nicht von anhängigen Replikationsaufgaben verwendet werden und für die Daemon-Aufgaben verfügbar sind.

Der Daemon-Service-Scheduler platziert keine Aufgaben auf Instances mit dem Status DRAINING. Wenn eine Container-Instance in einen DRAINING-Status übergeht, werden die darauf befindlichen Daemon-Aufgaben gestoppt. Der Service-Scheduler stellt sicher, dass Daemon-Aufgaben als letzte beendet werden, nachdem alle Replikataufgaben gestoppt wurden. Der Service Scheduler überwacht auch, ob Ihrem Cluster neue Container-Instances hinzugefügt werden, und fügt diesen die Daemon-Aufgaben hinzu.

Wenn eine Bereitstellungskonfiguration angegeben ist, muss der Parameter für den maximalen Prozentsatz gleich 100 sein. Der Standardwert für einen Daemon-Service für maximumPercent ist 200 %. Der Standardwert für einen Daemon-Service für minimumHealthyPercent ist 0 %.

Sie müssen den Service neu starten, wenn Sie die Platzierungseinschränkungen für den Daemon-Service ändern. Amazon ECS aktualisiert dynamisch die Ressourcen, die auf qualifizierten Instances für die Daemon-Aufgabe reserviert sind. Bei vorhandenen Instances versucht der Scheduler, die Aufgabe auf der Instance zu platzieren.

Eine neue Bereitstellung beginnt, wenn die Aufgabengröße oder die Reservierung von Containerressourcen in der Aufgabendefinition geändert wird. Amazon ECS nimmt die aktualisierten CPU- und Speicherreservierungen für den Daemon auf und sperrt diese Kapazität für die Daemon-Aufgabe.

Wenn für einen der oben genannten Fälle nicht genügend Ressourcen vorhanden sind, geschieht Folgendes:

  • Die Aufgabenplatzierung schlägt fehl.

  • Ein CloudWatch Ereignis wird generiert.

  • Amazon ECS versucht weiterhin, die Aufgabe für die Instance zu planen, indem er darauf wartet, dass Ressourcen verfügbar sind.

  • Amazon ECS gibt alle reservierten Instances frei, die die Platzierungseinschränkungskriterien nicht mehr erfüllen, und stoppt die entsprechenden Daemon-Aufgaben.

Die Daemon-Scheduling-Strategie kann in folgenden Fällen verwendet werden:

  • Ausführen von Anwendungscontainern

  • Ausführen von Support-Containern für Protokollierungs-, Überwachungs- und Tracing-Aufgaben

Aufgaben, die den Starttyp Fargate oder die Bereitstellungs-Controller-Typen CODE_DEPLOY oder EXTERNAL verwenden, unterstützen die Daemon-Scheduling-Strategie nicht.

Wenn der Service-Scheduler Aufgaben stoppt, versucht er, eine Ausgewogenheit in den Availability Zones in Ihrem Cluster herzustellen. Der Scheduler verwendet die folgende Logik:

  • Wenn eine Platzierungsstrategie definiert ist, wählen Sie mit dieser Strategie die zu beendenden Aufgaben aus. Wenn beispielsweise für einen Service eine Strategie für die Verteilung der Availability Zone definiert wurde, wird eine Aufgabe ausgewählt, die die verbleibenden Aufgaben mit der besten Verteilung belässt.

  • Wenn keine Platzierungsstrategie definiert ist, verwenden Sie die folgende Logik, um das Gleichgewicht zwischen den Availability Zones in Ihrem Cluster aufrechtzuerhalten:

    • Sortiert die gültigen Container-Instances. Geben Sie den Instances den Vorrang, die in ihrer jeweiligen Availability Zone die größte Anzahl an laufenden Aufgaben für diesen Service haben. Wenn beispielsweise in Zone A eine Serviceaufgabe läuft und in den Zonen B und C jeweils zwei Serviceaufgaben laufen, werden Container Instances in Zone B oder C als optimal für die Terminierung angesehen.

    • Stoppen Sie die Aufgabe auf einer Container-Instance in einer optimalen Availability Zone, basierend auf den vorherigen Schritten. Bevorzugung von Container-Instances mit der größten Anzahl von ausgeführten Aufgaben für diesen Service.

Replikat

Die Planungsstrategie replica platziert und bewahrt die gewünschte Anzahl von Aufgaben in Ihrem Cluster.

Für einen Service, der Aufgaben auf Fargate ausführt, verwendet der Service-Scheduler, wenn er neue Aufgaben startet oder laufende Aufgaben stoppt, den bestmöglichen Ansatz, um ein Gleichgewicht zwischen den Availability Zones herzustellen. Sie müssen keine Aufgabenplatzierungsstrategien oder Beschränkungen angeben.

Wenn Sie einen Service erstellen, der Aufgaben auf EC2-Instances ausführt, können Sie optional Strategien und Einschränkungen für die Aufgabenplatzierung angeben, um die Entscheidungen zur Aufgabenplatzierung anzupassen. Wenn keine Strategien oder Einschränkungen für die Aufgabenplatzierung angegeben werden, verteilt der Service Scheduler die Aufgaben standardmäßig über Availability Zones. Der Scheduler verwendet die folgende Logik:

  • Bestimmt, welche der Container-Instances in Ihrem Cluster die Aufgabendefinition Ihres Services unterstützen können (z. B. erforderliche CPU, Arbeitsspeicher, Ports und Container-Instance-Attribute).

  • Bestimmt, welche Container-Instances alle Platzierungseinschränkungen erfüllen, die für den Service definiert sind.

  • Wenn Sie einen Replikat-Service haben, der von einem Daemon-Service abhängt (z. B. eine Daemon-Log-Router-Aufgabe, die ausgeführt werden muss, bevor Aufgaben die Protokollierung nutzen können), erstellen Sie eine Einschränkung für die Aufgabenplatzierung, die sicherstellt, dass die Daemon-Service-Aufgaben vor den Replikat-Service-Aufgaben auf der EC2-Instance platziert werden. Weitere Informationen finden Sie unter Beispielbedingungen.

  • Wenn es eine definierte Platzierungsstrategie gibt, verwenden Sie diese Strategie, um eine Instance aus den verbleibenden Kandidaten auszuwählen.

  • Wenn es keine definierte Platzierungsstrategie gibt, verwenden Sie die folgende Logik, um Tasks auf die Availability Zones in Ihrem Cluster zu verteilen:

    • Sortiert die gültigen Container-Instances. Gibt den Instances Vorrang, die in ihrer jeweiligen Availability Zone die geringste Anzahl von laufenden Aufgaben für diesen Service haben. Wenn beispielsweise Zone A über eine ausgeführte Serviceaufgabe verfügt und die Zonen B und C jeweils über keine, werden gültige Container-Instances in Zone B oder C als optimal für eine Platzierung erachtet.

    • Platziert die neue Serviceaufgabe auf einer gültigen Container-Instance in einer optimalen Availability Zone, basierend auf den vorherigen Schritten. Begünstigt Container-Instances mit der geringsten Anzahl von ausgeführten Aufgaben für diesen Service.

Zusätzliche Service-Konzepte

  • Sie können Ihren Service optional auch hinter einem Load Balancer ausführen. Weitere Informationen finden Sie unter Service-Load Balancing.

  • Sie können optional eine Bereitstellungskonfiguration für Ihren Service festlegen. Eine Bereitstellung wird durch das Aktualisieren der Aufgabendefinition eines Services eingeleitet. Während einer Bereitstellung verwendet der Service Scheduler die Parameter mindestens fehlerfreie Prozentsatz und maximaler Prozentsatz, um die Bereitstellungsstrategie zu ermitteln. Weitere Informationen finden Sie unter Servicedefinitionsparameter.

  • Sie können Ihren Service optional so konfigurieren, dass er Amazon-ECS-Service Discovery verwendet. Service Discovery verwendet die AWS Cloud Map Autonaming-APIs, um DNS-Einträge für die Aufgaben Ihres Services zu verwalten. Dadurch sind sie in Ihrer VPC auffindbar. Weitere Informationen finden Sie unter Serviceerkennung.

  • Wenn Sie einen Service löschen und noch Aufgaben ausgeführt werden, die eine Bereinigung erfordern, wechselt der Service von einem ACTIVE- in einen DRAINING-Status, und der Service ist nicht mehr in der Konsole oder in der ListServices-API-Operation sichtbar. Nachdem alle Aufgaben entweder in den STOPPING- oder STOPPED-Status übergegangen ist, ändert sich der Servicestatus von DRAINING zu INACTIVE. Sie können Services im DRAINING- oder INACTIVE-Status anzeigen, indem Sie den API-Vorgang DescribeServices verwenden. In Zukunft werden jedoch INACTIVE-Services möglicherweise bereinigt und von der Amazon-ECS-Datensatzverwaltung gelöscht. DescribeServices-Aufrufe für diese Services geben dann einen ServiceNotFoundException-Fehler zurück.

  • Die Bake-Zeit ist ein Zeitraum nach dem Aufskalieren einer neuen Serviceversion und dem Abskalieren der alten Serviceversion. Während dieser Zeit überwacht Amazon ECS weiterhin den der Bereitstellung zugeordneten Alarm. Amazon ECS berechnet diesen Zeitraum basierend auf der Alarmkonfiguration, die der Bereitstellung zugeordnet ist.

    Die Bake-Zeit gilt nur, wenn Sie CloudWatch Alarme verwenden, um Bereitstellungsfehler zu erkennen. Weitere Informationen finden Sie unter Methoden zur Fehlererkennung.