Warum bleibt meine Amazon ECS-Aufgabe im Status AUSSTEHEND hängen?

Kurzbeschreibung

Die folgenden Szenarien führen dazu, dass Amazon ECS-Aufgaben im Status AUSSTEHEND hängen bleiben:

• Der Docker-Daemon reagiert nicht.
• Im Cluster gibt es eine Ressourcenbeschränkung.
• Das Docker-Image ist groß.
• Der Amazon ECS-Container-Agent hat während eines Aufgabenstarts die Konnektivität mit dem Amazon ECS-Service verloren.
• Der Amazon ECS-Container-Agent benötigt lange, um eine bestehende Aufgabe zu beenden.
• Du hast das Amazon Virtual Private Cloud (Amazon VPC)-Routing nicht richtig konfiguriert.
• Ein essenzieller Container hängt von nicht essenziellen Containern ab, die sich nicht im FEHLERFREIEN Zustand befinden.
• Die AWS Identity and Access Management (IAM, Identitäts- und Zugriffsmanagement)-Rolle, die du den Amazon ECS-Aufgaben zugeordnet hast, fehlt oder ist falsch.
• Es gibt Probleme mit der Bildkompatibilität mit der von dir ausgewählten Windows-Version.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Der Docker-Daemon reagiert nicht oder es besteht eine Ressourcenbeschränkung im Cluster

Prüfe in der Aufgabendefinition, ob die Aufgabe mehr Speicher oder CPU anfordert, als die Instance unterstützen kann. Passe die Container-Instance-Ressourcen an deine Bedürfnisse an.

Gehe bei CPU-Problemen wie folgt vor:

1. Verwende Amazon CloudWatch-Metriken, um zu überprüfen, ob die Container-Instance das maximale CPU-Kontingent überschritten hat.
2. Erhöhe die Größe der Container-Instance nach Bedarf.

Gehe bei Speicherproblemen wie folgt vor:

1. Führe den free-Befehl aus, um zu sehen, wie viel Speicher für das System verfügbar ist.
2. Erhöhe die Größe der Container-Instance nach Bedarf.

Gehe bei E/A-Problemen wie folgt vor:

1. Führe den Befehl iotop aus.
2. Identifiziere in jedem Service jene Aufgaben, die die meisten Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) verwenden.
3. Verwende Einschränkungen und Strategien für die Aufgabenplatzierung, um diese Aufgaben auf verschiedene Container-Instances zu verteilen.
   -oder-
   Verwende CloudWatch, um einen Alarm für deine Burst-Balance-Metriken im Amazon Elastic Block Store (Amazon EBS) zu erstellen. Verwende dann eine AWS Lambda-Funktion oder deine eigene benutzerdefinierte Logik, um die Aufgaben auszugleichen.

Das Docker-Image ist groß

Das Herunterladen großer Bilder dauert länger und erhöht die Zeit, in der sich die Aufgabe im Status AUSSTEHEND befindet.

Um die Übergangszeit zu beschleunigen, stelle den Parameter ECS_IMAGE_PULL_BEHAVIOR so ein, dass das Bild-Caching verwendet wird. Setze beispielsweise den Parameter ECS_IMAGE_PULL_BEHAVIOR in /etc/ecs/ecs.config auf prefer-cached. Wenn du prefer-cached verwendest, ruft Amazon ECS das Bild per Fernzugriff ab, wenn kein zwischengespeichertes Bild vorhanden ist. Andernfalls verwendet Amazon ECS das zwischengespeicherte Bild auf der Instance.

Der Amazon ECS-Container-Agent hat während eines Starts die Konnektivität mit dem Amazon ECS-Service verloren

Führe die folgenden Befehle auf der Container-Instance aus, die auf deiner Amazon Linux-Version basieren, um den Status und die Konnektivität des Amazon ECS-Container-Agents zu überprüfen.

Amazon Linux 1:

sudo status ecs
sudo docker ps -f name=ecs-agent

Amazon Linux 2:

sudo systemctl status ecs
sudo docker ps -f name=ecs-agent

Wenn der Status in der Ausgabe inaktiv ist, wird der Agent getrennt. Um dieses Problem zu beheben, führe die folgenden Befehle aus, um den Container-Agent neu zu starten.

Amazon Linux 1:

sudo stop ecs
sudo start ecs

Amazon Linux 2:

sudo systemctl stop ecs
sudo systemctl start ecs

Du erhältst eine Ausgabe, die der folgenden Meldung ähnelt:

ecs start/running, process abcd

Um die Agent-Konnektivität zu ermitteln, überprüfe die folgenden Protokolle während des jeweiligen Zeitrahmens auf Schlüsselwörter wie Fehler, warn (Warnung) oder agent transition state (Agent-Übergangsstatus):

• Sieh dir das Amazon ECS-Container-Agent-Protokoll unter /var/log/ecs/ecs-agent.log.yyyy-mm-dd-hh an.
• Sieh dir das Amazon ECS-Initialisierungsprotokoll unter /var/log/ecs/ecs-init.log an.
• Sieh dir die Docker-Protokolle unter /var/log/docker an.

Identifiziere anhand der Informationen in den Protokollen die Hauptursache der Konnektivitätsprobleme.

Hinweis: Du kannst zudem den Amazon ECS-Protokollsammler verwenden, um allgemeine Betriebssystemprotokolle, Docker-Protokolle und Container-Agent-Protokolle für Amazon ECS zu sammeln.

Um den lokalen Aufgabenstatus in Echtzeit in der Container-Instance abzurufen, führe den folgenden Befehl aus, um die Metadaten der Aufgaben, die ausgeführt werden, in der Container-Instance anzuzeigen:

curl http://localhost:51678/v1/metadata

Du erhältst eine Ausgabe, die der folgenden ähnelt:

{  "Cluster": "CLUSTER_ID",
  "ContainerInstanceArn": "arn:aws:ecs:REGION:ACCOUNT_ID:container-instance/TASK_ID",
  "Version": "Amazon ECS Agent - AGENT "
}

Stelle in der Ausgabe sicher, dass die Ausgabenumgebungsvariablen, die CPU, der Speicher und die IAM-Rollenkonfiguration korrekt sind. Stelle außerdem sicher, dass die Aufgabe über die erforderlichen Secrets verfügt.

Führe den folgenden Befehl aus, um detaillierte Informationen zu allen Aufgaben anzuzeigen, die im Service ausgeführt werden:

curl http://localhost:51678/v1/tasks

Du erhältst eine Ausgabe, die der folgenden ähnelt:

{  "Tasks": [
    {
      "Arn": "arn:aws:ecs:REGION:ACCOUNT_ID:task/TASK_ID",
      "DesiredStatus": "RUNNING",
      "KnownStatus": "RUNNING",
      ... ...
    }
  ]
}

Prüfe in den vorangegangenen Befehlsausgaben, ob es Unterschiede zwischen dem lokalen Agent und dem Amazon ECS-Service gibt. Verwende diese Informationen, um herauszufinden, wo und warum die Aufgabe feststeckt.

Der Amazon ECS-Container-Agent benötigt lange, um eine bestehende Aufgabe anzuhalten

Wenn Amazon ECS neue Aufgaben sendet, um vom Status AUSSTEHEND in den Status WIRD AUSGEFÜHRT… zu starten, hat der Container-Agent möglicherweise bereits Aufgaben, die angehalten werden müssen. In diesem Fall startet der Agent die neuen Aufgaben erst, wenn er die vorhandenen Aufgaben zuerst anhält.

Um das Stopp- und Start-Timeout des Containers auf Container-Instance-Ebene zu steuern, passe die Umgebungsvariablen für die Variablen ECS_CONTAINER_STOP_TIMEOUT und ECS_CONTAINER_START_TIMEOUT in /etc/ecs/ecs.config an. ECS_CONTAINER_STOP_TIMEOUT legt die Zeitspanne fest, die vergeht, bevor Amazon ECS die Container zwangsweise beendet, wenn sie nicht automatisch beendet werden. Der Standardwert für das Stopp-Timeout für Linux und Windows beträgt 30 Sekunden. ECS_CONTAINER_START_TIMEOUT legt die Zeitspanne fest, die vergeht, bis der Amazon ECS-Container-Agent nicht mehr versucht, den Container zu starten. Der Standard-Wert für das Start-Timeout beträgt 3 Minuten für Linux und 8 Minuten für Windows.

Wenn deine Agent-Version 1.26.0 oder höher ist, kannst du die Parameter für das Stopp- und Start-Timeout-in jeder Aufgabe definieren. Beachte, dass die Aufgabe möglicherweise in den Status ANGEHALTEN wechselt, wenn du den Parameter änderst. Beispiel: Container-Instance A ist davon abhängig, dass Container-Instance B den Status ABSCHLIESSEN, ERFOLG oder FEHLERFREI erreicht. Du hast keinen startTimeout-Wert für Container-Instance B angegeben. Wenn Container-Instance B innerhalb der Timeout-Zeit nicht den erforderlichen Zustand erreicht, startet Container-Instance A nicht.

Ein Beispiel für Container-Abhängigkeit findest du unter Example: Container dependency (Beispiel: Container-Abhängigkeit) auf der GitHub-Website.

Du hast das Amazon VPC-Routing nicht richtig konfiguriert

Überprüfe die Konfiguration für das VPC-Subnetz, in dem die Amazon ECS- oder AWS Fargate-Aufgaben ausgeführt werden. Das Subnetz muss Zugriff auf Amazon ECS oder Amazon Elastic Container Registry (Amazon ECR) haben. Um Konfigurationsprobleme zu beheben, stelle sicher, dass die Routing-Tabelle für das Subnetz über ein Internet-Gateway oder ein NAT-Gateway verfügt. Wenn du eine Aufgabe in einem Subnetz startest, das keine ausgehende Route zum Internet hat, verwende AWS PrivateLink. Diese Konfiguration ermöglicht dir den Zugriff auf Amazon ECS-APIs mit privaten IP-Adressen.

Stelle außerdem sicher, dass deine Sicherheitsgruppenregeln eingehende und ausgehende Kommunikation über die erforderlichen Ports der Konfiguration zulassen.

Eine äußerst wichtige Container-Instance hängt von nicht essenziellen Container-Instances ab, die sich nicht im Zustand FEHLERFREI befinden

Wenn sich eine nicht essenzielle Container-Instance, von der eine essenzielle Container-Instance abhängt, nicht im Zustand FEHLERFREI befindet, bleibt die Aufgabe im Status WIRD ASUGEFÜHRT... hängen. Du erhältst die Meldung „stoppedReason“:„Service ABCXYZ: task last status remained in PENDING too long“.

Um dieses Problem zu beheben, stelle sicher, dass die nicht essenziellen Container-Instances erwartungsgemäß funktionieren. Wenn du das zugrunde liegende Problem nicht lösen kannst, aktualisiere die Aufgabendefinition für die Container-Instances und setze den essenziellen Parameter auf true (wahr). Wenn die Aufgabe immer noch angehalten ist, überprüfe den Grund für das Anhalten. Weitere Schritte zur Fehlerbehebung findest du unter Warum wurde meine Amazon ECS-Aufgabe angehalten?

Die IAM-Rolle fehlt oder ist falsch konfiguriert

Wenn sich die Aufgabe in einer Container-Instance befindet, die nicht über die erforderlichen Berechtigungen verfügt, erhältst du eine Fehlermeldung, die dem folgenden Beispiel ähnelt:

„(service test) failed to launch a task with (error ECS was unable to assume the role 'arn:aws:iam::111111111111:role/test-fTa-T3J4hVnyL53E' that was provided for this task. Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role.)“

Um dieses Problem zu beheben, stelle sicher, dass die Container-Instance über die erforderlichen Berechtigungen verfügt.

Wenn du außerdem kein Amazon ECS-optimiertes Amazon Machine Image (AMI) für die Container-Instances verwendest, überprüfe die Amazon ECS-Agent-Konfigurationen.

Es gibt Probleme mit der Bildkompatibilität mit der von dir ausgewählten Windows-Version

Aufgaben schlagen fehl, wenn das Bild, das du in Windows Fargate-Aufgaben verwendest, nicht mit deiner Plattform kompatibel ist. Um zu überprüfen, ob dein Bild mit dem Windows-Serverhost kompatibel ist, findest du auf der Microsoft-Website unter Versionskompatibilität von Windows-Containern. Überprüfe dann die Voraussetzungen für die Ausführung der Windows-Aufgaben.

Stelle außerdem sicher, dass die von dir definierte Bild-URL korrekt ist.

Ähnliche Informationen

Container-Abhängigkeit

amazon-ecs-agent auf der GitHub-Webseite