Fehlerbehebung AWS Batch - AWS Batch

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.

Fehlerbehebung AWS Batch

Möglicherweise müssen Sie Probleme im Zusammenhang mit Ihren Datenverarbeitungsumgebungen, Auftragswarteschlangen, Auftragsdefinitionen oder Aufträgen beheben. In diesem Kapitel wird beschrieben, wie Sie solche Probleme in Ihrer AWS Batch Umgebung beheben.

AWS Batch verwendet IAM-Richtlinien, -Rollen und -Berechtigungen und läuft auf der Infrastruktur von Amazon EC2 AWS Fargate, Amazon ECS und Amazon Elastic Kubernetes Service. Informationen zur Behebung von Problemen im Zusammenhang mit diesen Services finden Sie im Folgenden:

AWS Batch

INVALID Datenverarbeitungsumgebung

Möglicherweise haben Sie eine verwaltete Datenverarbeitungsumgebung falsch konfiguriert. Wenn Sie dies tun, wechselt die Datenverarbeitungsumgebung in einen -INVALIDStatus und kann keine Aufträge für die Platzierung akzeptieren. In den folgenden Abschnitten werden die möglichen Ursachen und die Fehlerbehebung auf der Grundlage der Ursache beschrieben.

Falscher Rollenname oder ARN

Die häufigste Ursache dafür, dass eine Datenverarbeitungsumgebung in einen -INVALIDStatus übergeht, ist, dass die AWS Batch Servicerolle oder die Amazon EC2-Spot-Flottenrolle einen falschen Namen oder Amazon-Ressourcennamen (ARN) hat. Dies ist häufiger bei Datenverarbeitungsumgebungen, die mit der AWS CLI oder den AWS SDKs erstellt werden. Wenn Sie eine Datenverarbeitungsumgebung in der erstellen AWS Management Console, AWS Batch unterstützt Sie bei der Auswahl der richtigen Service- oder Spot-Flottenrollen. Angenommen, Sie geben den Namen oder den ARN manuell und falsch ein. Dann ist die resultierende Datenverarbeitungsumgebung ebenfalls INVALID.

Angenommen, Sie geben den Namen oder ARN für eine IAM-Ressource manuell in einen AWS CLI -Befehl oder Ihren SDK-Code ein. In diesem Fall AWS Batch kann die Zeichenfolge nicht validieren. Stattdessen muss den fehlerhaften Wert akzeptieren und versuchen, AWS Batch die Umgebung zu erstellen. Wenn die Umgebung AWS Batch nicht erstellen kann, wechselt die Umgebung in einen -INVALIDStatus, und es werden die folgenden Fehler angezeigt.

Bei einer ungültigen Servicerolle:

CLIENT_ERROR - Not authorized to perform sts:AssumeRole (Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied; Request ID: dc0e2d28-2e99-11e7-b372-7fcc6fb65fe7)

Bei einer ungültigen Spot-Flottenrolle:

CLIENT_ERROR - Parameter: SpotFleetRequestConfig.IamFleetRole is invalid. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidSpotFleetRequestConfig; Request ID: 331205f0-5ae3-4cea-bac4-897769639f8d) Parameter: SpotFleetRequestConfig.IamFleetRole is invalid

Eine häufige Ursache für dieses Problem ist das folgende Szenario. Sie geben den Namen einer IAM-Rolle nur an, wenn Sie die AWS CLI oder die AWS SDKs anstelle des vollständigen Amazon-Ressourcennamens (ARN) verwenden. Je nachdem, wie Sie die Rolle erstellt haben, enthält der ARN möglicherweise ein aws-service-role Pfadpräfix. Wenn Sie beispielsweise die AWS Batch Servicerolle manuell mit den Verfahren in erstellenVerwenden von serviceverknüpften Rollen für AWS Batch, könnte Ihr Servicerollen-ARN wie folgt aussehen.

arn:aws:iam::123456789012:role/AWSBatchServiceRole

Wenn Sie die Servicerolle jedoch heute als Teil des Assistenten zur ersten Ausführung der Konsole erstellt haben, könnte Ihr Servicerollen-ARN wie folgt aussehen.

arn:aws:iam::123456789012:role/aws-service-role/AWSBatchServiceRole

Dieses Problem kann auch auftreten, wenn Sie die AWS Batch Service-Level-Richtlinie (AWSBatchServiceRole) an eine Nicht-Servicerolle anfügen. In diesem Szenario erhalten Sie beispielsweise möglicherweise eine Fehlermeldung, die der folgenden ähnelt:

CLIENT_ERROR - User: arn:aws:sts::account_number:assumed-role/batch-replacement-role/aws-batch is not authorized to perform: action on resource ...

Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben.

  • Verwenden Sie eine leere Zeichenfolge für die Servicerolle, wenn Sie die AWS Batch Datenverarbeitungsumgebung erstellen.

  • Geben Sie die Servicerolle im folgenden Format an: arn:aws:iam::account_number:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch.

Wenn Sie nur den Namen einer IAM-Rolle angeben, wenn Sie die AWS CLI oder die AWS SDKs verwenden, AWS Batch geht davon aus, dass Ihr ARN das aws-service-role Pfadpräfix nicht verwendet. Aus diesem Grund empfehlen wir Ihnen, beim Erstellen von Datenverarbeitungsumgebungen den vollständigen ARN für Ihre IAM-Rollen anzugeben.

Informationen zum Reparieren einer auf diese Weise falsch konfigurierten Datenverarbeitungsumgebung finden Sie unter Reparieren einer -INVALIDRechenumgebung.

Reparieren einer -INVALIDRechenumgebung

Wenn sich eine Datenverarbeitungsumgebung in einem -INVALIDStatus befindet, aktualisieren Sie sie, um den ungültigen Parameter zu reparieren. Falscher Rollenname oder ARNAktualisieren Sie für ein die Datenverarbeitungsumgebung mit der richtigen Servicerolle.

So Reparieren Sie eine falsch konfigurierte Datenverarbeitungsumgebung
  1. Öffnen Sie die - AWS Batch Konsole unter https://console.aws.amazon.com/batch/.

  2. Wählen Sie in der Navigationsleiste die zu AWS-Region verwendende aus.

  3. Wählen Sie im Navigationsbereich Datenverarbeitungs-Umgebungen aus.

  4. Wählen Sie auf der Seite Datenverarbeitungs-Umgebungen das Optionsfeld neben der zu bearbeitenden Datenverarbeitungsumgebung und dann Bearbeiten aus.

  5. Wählen Sie auf der Seite Computing-Umgebung aktualisieren für Servicerolle die IAM-Rolle aus, die Sie mit Ihrer Computing-Umgebung verwenden möchten. Die AWS Batch -Konsole zeigt nur mit der richtigen Vertrauensstellung für Datenverarbeitungsumgebungen an.

  6. Wählen Sie Speichern aus, um Ihre Datenverarbeitungsumgebung zu aktualisieren.

Jobs hängen in einem -RUNNABLEStatus fest

Angenommen, Ihre Datenverarbeitungsumgebung enthält Rechenressourcen, aber Ihre Aufträge gehen nicht über den RUNNABLE Status hinaus. Dann ist es wahrscheinlich, dass etwas verhindert, dass die Aufträge auf einer Rechenressource platziert werden und dazu führen, dass Ihre Auftragswarteschlangen blockiert werden. So können Sie wissen, ob Ihr Auftrag auf seine Drehung wartet oder hängen bleibt und die Warteschlange blockiert.

Wenn AWS Batch erkennt, dass Sie einen RUNNABLE Auftrag an der Spitze haben und die Warteschlange blockieren, erhalten Sie ein blockiertes Auftragswarteschlangenereignis von Amazon CloudWatch Events mit dem Grund. Derselbe Grund wird auch als Teil von - ListJobs und DescribeJobs-API-Aufrufen in das statusReason Feld aktualisiert.

Optional können Sie den jobStateTimeLimitActions Parameter über die UpdateJobQueue API-Aktionen CreateJobQueue und konfigurieren.

Anmerkung

Derzeit können Sie mit nur einen Auftrag jobStateLimitActions.action abbrechen.

Der jobStateTimeLimitActions Parameter wird verwendet, um eine Reihe von Aktionen anzugeben, die für Aufträge in einem bestimmten Status AWS Batch ausführt. Sie können einen Zeitschwellenwert in Sekunden über das maxTimeSeconds Feld festlegen.

Wenn sich ein Auftrag in einem -RUNNABLEZustand mit dem definierten befunden hatstatusReason, AWS Batch führt die Aktion aus, die nach maxTimeSeconds verstrichen ist.

Sie können beispielsweise den jobStateTimeLimitActions Parameter so einstellen, dass er bis zu 4 Stunden wartet, bis jeder Auftrag im RUNNABLE Status verfügbar ist. Sie können dies tun, indem Sie statusReason auf CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY und maxTimeSeconds auf 144 000 festlegen, bevor Sie den Auftrag abbrechen und dem nächsten Auftrag erlauben, zum Anfang der Auftragswarteschlange zu gelangen.

Im Folgenden sind die Gründe aufgeführt, die AWS Batch angibt, wenn erkannt wird, dass eine Auftragswarteschlange blockiert ist. Diese Liste enthält die Nachrichten, die von den - ListJobs und DescribeJobs-API-Aktionen zurückgegeben werden. Dies sind auch die gleichen Werte, die Sie für den jobStateLimitActions.statusReason Parameter definieren können.

  1. Grund: Alle verbundenen Datenverarbeitungsumgebungen haben Fehler mit unzureichender Kapazität. Wenn angefordert, AWS Batch erkennt Amazon EC2-Instances, bei denen Fehler mit unzureichender Kapazität auftreten. Wenn Sie den Auftrag entweder manuell abbrechen oder den jobStateTimeLimitActions Parameter auf setzenstatusReason, kann der nachfolgende Auftrag an den Anfang der Warteschlange verschoben werden.

    • statusReason Nachricht, während der Auftrag hängen bleibt: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]

    • reason wird für verwendetjobStateTimeLimitActions: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    • statusReason -Meldung, nachdem der Auftrag abgebrochen wurde: Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    Hinweis:

    1. Die AWS Batch Servicerolle benötigt die autoscaling:DescribeScalingActivities Berechtigung, damit diese Erkennung funktioniert. Wenn Sie die AWSServiceRoleForBatch serviceverknüpfte Rolle (SLR) oder die AWSBatchServiceRolePolicy -verwaltete Richtlinie verwenden, müssen Sie keine Maßnahmen ergreifen, da ihre Berechtigungsrichtlinien aktualisiert werden.

    2. Wenn Sie die SLR oder die verwaltete Richtlinie verwenden, müssen Sie die ec2:DescribeSpotFleetRequestHistory Berechtigungen autoscaling:DescribeScalingActivities und hinzufügen, damit Sie blockierte Auftragswarteschlangenereignisse und aktualisierten Auftragsstatus erhalten können, wenn Sie sich in befindenRUNNABLE. Darüber hinaus AWS Batch benötigt diese Berechtigungen, um cancellation Aktionen über den -jobStateTimeLimitActionsParameter auszuführen, auch wenn sie in der Auftragswarteschlange konfiguriert sind.

    3. Im Falle eines parallelen Auftrags mit mehreren Knoten (MNP) blockiert die Amazon EC2-Datenverarbeitungsumgebung insufficient capacity Fehler, auch wenn in einer Datenverarbeitungsumgebung mit niedrigerer Priorität dieser Fehler auftritt.

  2. Grund: Alle Datenverarbeitungsumgebungen haben einen maxvCpus Parameter, der kleiner ist als die Auftragsanforderungen. Wenn Sie den Auftrag entweder manuell abbrechen oder den jobStateTimeLimitActions Parameter auf setzenstatusReason, kann der nachfolgende Auftrag an den Anfang der Warteschlange verschoben werden. Optional können Sie den maxvCpus Parameter der primären Datenverarbeitungsumgebung erhöhen, um die Anforderungen des blockierten Auftrags zu erfüllen.

    • statusReason Nachricht, während der Auftrag hängen bleibt: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.

    • reason wird für verwendetjobStateTimeLimitActions: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

    • statusReason -Meldung, nachdem der Auftrag abgebrochen wurde: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

  3. Grund: Keine der Datenverarbeitungsumgebungen verfügt über Instances, die die Auftragsanforderungen erfüllen. Wenn ein Auftrag Ressourcen anfordert, AWS Batch erkennt , dass keine angefügte Rechenumgebung in der Lage ist, den eingehenden Auftrag zu verarbeiten. Wenn Sie den Auftrag entweder manuell abbrechen oder den jobStateTimeLimitActions Parameter auf setzenstatusReason, kann der nachfolgende Auftrag an den Anfang der Warteschlange verschoben werden. Optional können Sie die zulässigen Instance-Typen der Datenverarbeitungsumgebung neu definieren, um die erforderlichen Auftragsressourcen hinzuzufügen.

    • statusReason Nachricht, während der Auftrag hängen bleibt: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT - The job resource requirement (vCPU/memory/GPU) is higher than that can be met by the CE(s) attached to the job queue.

    • reason wird für verwendetjobStateTimeLimitActions: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

    • statusReason -Nachricht nach dem Abbrechen des Auftrags: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

  4. Grund: Alle Datenverarbeitungsumgebungen haben Probleme mit der Servicerolle. Um dies zu beheben, vergleichen Sie Ihre Servicerollenberechtigungen mit den AWS Batch Berechtigungen der verwalteten Servicerolle und beheben Sie etwaige Lücken.

    Es hat sich bewährt, die AWS Batch SLR für Datenverarbeitungsumgebungen zu verwenden, um ähnliche Fehler zu vermeiden.

    Wenn der Auftrag entweder manuell oder durch Festlegen des jobStateTimeLimitActions Parameters auf abgebrochen wirdstatusReason, kann der nachfolgende Auftrag an den Anfang der Warteschlange verschoben werden. Ohne das/die Problem(e) mit der Servicerolle zu lösen, wird wahrscheinlich auch der nächste Auftrag blockiert. Es empfiehlt sich, dieses Problem manuell zu untersuchen und zu beheben.

    • statusReason Nachricht, während der Auftrag hängen bleibt: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

    • reason wird für verwendetjobStateTimeLimitActions: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

    • statusReason -Nachricht nach dem Abbrechen des Auftrags: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

  5. Grund: Alle Datenverarbeitungsumgebungen sind ungültig. Weitere Informationen finden Sie unter INVALID Datenverarbeitungsumgebung. Hinweis: Sie können eine programmierbare Aktion nicht über den -jobStateTimeLimitActionsParameter konfigurieren, um diesen Fehler zu beheben.

    • statusReason Nachricht, während der Auftrag hängen bleibt: ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. Grund: AWS Batch hat eine blockierte Warteschlange erkannt, kann aber den Grund nicht ermitteln. Hinweis: Sie können eine programmierbare Aktion nicht über den -jobStateTimeLimitActionsParameter konfigurieren, um diesen Fehler zu beheben. Weitere Informationen zur Fehlerbehebung finden Sie unter Warum bleibt mein AWS Batch Auftrag in RUNNABLE auf im re:Post hängen AWS.

    • statusReason Nachricht, während der Auftrag hängen bleibt: UNDETERMINED - Batch job is blocked, root cause is undetermined.

Falls Sie kein Ereignis von - CloudWatch Ereignissen oder das Ereignis mit unbekanntem Grund erhalten haben, sind hier einige häufige Ursachen für dieses Problem.

Der awslogs Protokolltreiber ist nicht für Ihre Rechenressourcen konfiguriert

AWS Batch -Aufträge senden ihre Protokollinformationen an - CloudWatch Protokolle. Um die entsprechende Funktion zu aktivieren, müssen Sie Ihre Datenverarbeitungsressourcen so konfigurieren, dass sie den awslogs-Protokolltreiber verwenden. Angenommen, Sie basieren Ihr Rechenressourcen-AMI auf dem Amazon-ECS-optimierten AMI (oder Amazon Linux). Dann wird dieser Treiber standardmäßig mit dem -ecs-initPaket registriert. Angenommen, Sie verwenden ein anderes Basis-AMI. Anschließend müssen Sie überprüfen, ob der awslogs Protokolltreiber als verfügbarer Protokolltreiber mit der ECS_AVAILABLE_LOGGING_DRIVERS Umgebungsvariablen angegeben wird, wenn der Amazon-ECS-Container-Agent gestartet wird. Weitere Informationen finden Sie unter AMI-Spezifikation für Rechenressourcen und Erstellen eines AMI für Rechenressourcen.

Unzureichende Ressourcen

Wenn Ihre Auftragsdefinitionen mehr CPU- oder Arbeitsspeicherressourcen angeben, als Ihre Rechenressourcen zuweisen können, werden Ihre Aufträge niemals platziert. Angenommen, Ihr Auftrag gibt 4 GiB Arbeitsspeicher an und Ihre Rechenressourcen verfügen über weniger als die verfügbare Speicherkapazität. Dann kann der Auftrag nicht auf diese Rechenressourcen platziert werden. In diesem Fall müssen Sie den angegebenen Speicher in Ihrer Auftragsdefinition reduzieren oder Ihrer Umgebung größere Datenverarbeitungsressourcen hinzufügen. Ein Teil des Speichers ist für den Amazon-ECS-Container-Agenten und andere kritische Systemprozesse reserviert. Weitere Informationen finden Sie unter DatenverarbeitungsressourceSpeicherverwaltung.

Kein Internetzugang für Rechenressourcen

Datenverarbeitungsressourcen benötigen einen externen Netzwerkzugriff, um mit dem Amazon-ECS-Service-Endpunkt zu kommunizieren. Dies kann über einen Schnittstellen-VPC-Endpunkt oder über Ihre Datenverarbeitungsressourcen mit öffentlichen IP-Adressen sein.

Weitere Informationen zu Interface-VPC-Endpunkten finden Sie unter Amazon-ECS-Schnittstellen-VPC-Endpunkte (AWS PrivateLink) im Amazon Elastic Container Service-Entwicklerhandbuch.

Wenn Sie keinen Schnittstellen-VPC-Endpunkt konfiguriert haben und Ihre Datenverarbeitungsressourcen keine öffentlichen IP-Adressen haben, müssen Sie Netzwerkadressübersetzung (Network Address Translation, NAT) verwenden, um diesen Zugriff zur Verfügung zu stellen. Weitere Informationen finden Sie unter NAT-Gateways im Amazon VPC-Benutzerhandbuch. Weitere Informationen finden Sie unter Erstellen einer VPC.

Amazon EC2-Instance-Limit erreicht

Die Anzahl der Amazon EC2-Instances, die Ihr Konto in einem starten kann, AWS-Region wird durch Ihr EC2-Instance-Kontingent bestimmt. Bestimmte Instance-Typen haben ebenfalls ein per-instance-type Kontingent. Weitere Informationen zum Amazon EC2-Instance-Kontingent Ihres Kontos, einschließlich der Anforderung einer Limiterhöhung, finden Sie unter Amazon EC2 Service Limits im Amazon EC2-Benutzerhandbuch für Linux-Instances.

Amazon-ECS-Container-Agent ist nicht installiert

Der Amazon-ECS-Container-Agent muss auf dem Amazon Machine Image (AMI) installiert sein, damit Aufträge AWS Batch ausgeführt werden können. Der Amazon-ECS-Container-Agent ist standardmäßig auf Amazon-ECS-optimierten AMIs installiert. Weitere Informationen zum Amazon-ECS-Container-Agenten finden Sie unter Amazon-ECS-Container-Agent im Entwicklerhandbuch für Amazon Elastic Container Service.

Weitere Informationen finden Sie unter Warum bleibt mein AWS Batch Auftrag im RUNNABLE Status hängen? in re:Post .

Spot-Instances werden bei der Erstellung nicht markiert

Das Markieren von Spot-Instances für AWS Batch Rechenressourcen wird ab dem 25. Oktober 2017 unterstützt. Zuvor enthielt die empfohlene von IAM verwaltete Richtlinie (AmazonEC2SpotFleetRole) für die Amazon EC2 Spot-Flottenrolle keine Berechtigungen zum Markieren von Spot-Instances beim Start. Die neue empfohlene von IAM verwaltete Richtlinie heißt AmazonEC2SpotFleetTaggingRole. Es unterstützt das Markieren von Spot-Instances beim Start.

Um das Spot-Instance-Tagging bei der Erstellung zu reparieren, gehen Sie wie folgt vor, um die aktuell empfohlene von IAM verwaltete Richtlinie auf Ihre Amazon EC2-Spot-Flottenrolle anzuwenden. Auf diese Weise verfügen alle zukünftigen Spot-Instances, die mit dieser Rolle erstellt werden, über Berechtigungen zum Anwenden von Instance-Tags, wenn sie erstellt werden.

So wenden Sie die aktuelle von IAM verwaltete Richtlinie auf Ihre Amazon EC2-Spot-Flottenrolle an
  1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.

  2. Wählen Sie Rollen und dann Ihre Amazon EC2-Spot-Flottenrolle aus.

  3. Wählen Sie Richtlinie anfügen aus.

  4. Wählen Sie AmazonEC2SpotFleetTaggingRole und dann Richtlinie anfügen aus.

  5. Wählen Sie erneut Ihre Amazon EC2-Spot-Flottenrolle aus, um die vorherige Richtlinie zu entfernen.

  6. Wählen Sie das x rechts neben der AmazonEC2SpotFleetRole-Richtlinie und wählen Sie Trennen aus.

Spot-Instances werden nicht herunterskaliert

AWS Batch hat die AWSServiceRoleForBatch serviceverknüpfte Rolle am 10. März 2021 eingeführt. Wenn im serviceRole Parameter der Datenverarbeitungsumgebung keine Rolle angegeben ist, wird diese serviceverknüpfte Rolle als Servicerolle verwendet. Angenommen, die serviceverknüpfte Rolle wird jedoch in einer EC2-Spot-Datenverarbeitungsumgebung verwendet, aber die verwendete Spot-Rolle enthält nicht die von AmazonEC2SpotFleetTaggingRole verwaltete Richtlinie. Dann wird die Spot-Instance nicht herunterskaliert. Infolgedessen erhalten Sie die Fehlermeldung „Sie sind nicht berechtigt, diesen Vorgang auszuführen“. Führen Sie die folgenden Schritte aus, um die Spot-Flottenrolle zu aktualisieren, die Sie im -spotIamFleetRoleParameter verwenden. Weitere Informationen finden Sie unter Verwenden von serviceverknüpften Rollen und Erstellen einer Rolle zum Delegieren von Berechtigungen an einen - AWS Service im IAM-Benutzerhandbuch.

Hängen Sie von AmazonEC2SpotFleetTaggingRole verwaltete Richtlinie an Ihre Spot-Flotten-Rolle in der an AWS Management Console

So wenden Sie die aktuelle von IAM verwaltete Richtlinie auf Ihre Amazon EC2-Spot-Flottenrolle an
  1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.

  2. Wählen Sie Rollen und dann Ihre Amazon EC2-Spot-Flottenrolle aus.

  3. Wählen Sie Richtlinie anfügen aus.

  4. Wählen Sie AmazonEC2SpotFleetTaggingRole und dann Richtlinie anfügen aus.

  5. Wählen Sie erneut Ihre Amazon EC2-Spot-Flottenrolle aus, um die vorherige Richtlinie zu entfernen.

  6. Wählen Sie das x rechts neben der AmazonEC2SpotFleetRole-Richtlinie und wählen Sie Trennen aus.

Anfügen einer von AmazonEC2SpotFleetTaggingRole verwalteten Richtlinie an Ihre Spot-Flotten-Rolle mit der AWS CLI

Die Beispielbefehle gehen davon aus, dass Ihre Amazon EC2-Spot-Flottenrolle den Namen AmazonEC2SpotFleetRole hat. Wenn Ihre Rolle einen anderen Namen verwendet, passen Sie die Befehle an.

So fügen Sie die von AmazonEC2SpotFleetTaggingRole verwaltete Richtlinie an Ihre Spot-Flottenrolle an
  1. Um die von AmazonEC2SpotFleetTaggingRole verwaltete IAM-Richtlinie an Ihre AmazonEC2SpotFleetRole-Rolle anzuhängen, führen Sie den folgenden Befehl mit aus AWS CLI.

    $ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetTaggingRole \ --role-name AmazonEC2SpotFleetRole
  2. Um die von AmazonEC2SpotFleetRole verwaltete IAM-Richtlinie von Ihrer AmazonEC2SpotFleetRole-Rolle zu trennen, führen Sie den folgenden Befehl mit aus AWS CLI.

    $ aws iam detach-role-policy \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetRole \ --role-name AmazonEC2SpotFleetRole

Secrets Manager-Secrets können nicht abgerufen werden

Wenn Sie ein AMI mit einem Amazon-ECS-Agenten verwenden, der älter als Version 1.16.0-1 ist, müssen Sie die Amazon-ECS-Agent-Konfigurationsvariable verwenden, ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true um diese Funktion zu verwenden. Sie können sie der ./etc/ecs/ecs.config Datei zu einer neuen Container-Instance hinzufügen, wenn Sie diese Instance erstellen. Oder Sie können sie einer vorhandenen Instance hinzufügen. Wenn Sie es einer vorhandenen Instance hinzufügen, müssen Sie den ECS-Agenten neu starten, nachdem Sie ihn hinzugefügt haben. Weitere Informationen finden Sie unter Amazon ECS Container Agent Configuration im Entwicklerhandbuch zum Amazon Elastic Container Service.

Ressourcenanforderungen für Auftragsdefinitionen können nicht überschrieben werden

Der Arbeitsspeicher und die vCPU-Überschreibungen, die in der memory containerOverrides-Struktur angegeben sind und vcpus Mitglieder der containerOverrides-Struktur, die an übergeben werdenSubmitJob, können die Speicher- und vCPU-Anforderungen, die in der resourceRequirements-Struktur in der Auftragsdefinition angegeben sind, nicht überschreiben. containerOverrides

Wenn Sie versuchen, diese Ressourcenanforderungen zu überschreiben, wird möglicherweise die folgende Fehlermeldung angezeigt:

„Dieser Wert wurde in einem veralteten Schlüssel übermittelt und kann mit dem Wert in Konflikt geraten, der durch die Ressourcenanforderungen der Auftragsdefinition bereitgestellt wird.“

Um dies zu korrigieren, geben Sie die Speicher- und vCPU-Anforderungen im resourceRequirements-Mitglied des containerOverrides an. Zum Beispiel, wenn Ihre Speicher- und vCPU-Überschreibungen in den folgenden Zeilen angegeben sind.

"containerOverrides": { "memory": 8192, "vcpus": 4 }

Ändern Sie sie wie folgt:

"containerOverrides": { "resourceRequirements": [ { "type": "MEMORY", "value": "8192" }, { "type": "VCPU", "value": "4" } ], }

Nehmen Sie die gleiche Änderung an den Speicher- und vCPU-Anforderungen vor, die im containerProperties-Objekt in der Auftragsdefinition angegeben sind. Zum Beispiel, wenn Ihre Speicher- und vCPU-Anforderungen in den folgenden Zeilen angegeben sind.

{ "containerProperties": { "memory": 4096, "vcpus": 2, }

Ändern Sie sie wie folgt:

"containerProperties": { "resourceRequirements": [ { "type": "MEMORY", "value": "4096" }, { "type": "VCPU", "value": "2" } ], }

Fehlermeldung beim Aktualisieren der desiredvCpus Einstellung

Die folgende Fehlermeldung wird angezeigt, wenn Sie die AWS Batch -API verwenden, um die gewünschte vCPUs (desiredvCpus)-Einstellung zu aktualisieren.

Manually scaling down compute environment is not supported. Disconnecting job queues from compute environment will cause it to scale-down to minvCpus.

Dieses Problem tritt auf, wenn der aktualisierte desiredvCpus Wert kleiner als der aktuelle desiredvCpus Wert ist. Wenn Sie den desiredvCpus Wert aktualisieren, müssen beide der folgenden Bedingungen erfüllt sein:

  • Der desiredvCpus Wert muss zwischen den maxvCpus Werten minvCpus und liegen.

  • Der aktualisierte desiredvCpus Wert muss größer oder gleich dem aktuellen desiredvCpus Wert sein.

AWS Batch auf Amazon EKS

INVALID Datenverarbeitungsumgebung

Möglicherweise haben Sie eine verwaltete Datenverarbeitungsumgebung falsch konfiguriert. Wenn Sie dies tun, wechselt die Datenverarbeitungsumgebung in einen -INVALIDStatus und kann keine Aufträge für die Platzierung akzeptieren. In den folgenden Abschnitten werden die möglichen Ursachen und die Fehlerbehebung auf der Grundlage der Ursache beschrieben.

Nicht unterstützte Kubernetes Version

Möglicherweise wird eine Fehlermeldung angezeigt, die der folgenden ähnelt, wenn Sie den CreateComputeEnvironment -API-Vorgang oder den -UpdateComputeEnvironmentAPI-Vorgang verwenden, um eine Computing-Umgebung zu erstellen oder zu aktualisieren. Dieses Problem tritt auf, wenn Sie eine nicht unterstützte Kubernetes Version in angebenEC2Configuration.

At least one imageKubernetesVersion in EC2Configuration is not supported.

Um dieses Problem zu beheben, löschen Sie die Datenverarbeitungsumgebung und erstellen Sie sie dann mit einer unterstützten Kubernetes Version neu.

Sie können ein Nebenversions-Upgrade auf Ihrem Amazon-EKS-Cluster durchführen. Sie können den Cluster beispielsweise von 1.xx auf aktualisieren, 1.yy auch wenn die Nebenversion nicht unterstützt wird.

Der Status der Datenverarbeitungsumgebung kann sich jedoch INVALID nach einer Hauptversionsaktualisierung in ändern. Wenn Sie beispielsweise ein Hauptversions-Upgrade von 1.xx auf durchführen2.yy. Wenn die Hauptversion von nicht unterstützt wird AWS Batch, wird eine Fehlermeldung ähnlich der folgenden angezeigt.

reason=CLIENT_ERROR - ... EKS Cluster version [2.yy] is unsupported

Um dieses Problem zu beheben, geben Sie eine unterstützte Kubernetes Version an, wenn Sie eine API-Operation zum Erstellen oder Aktualisieren einer Computing-Umgebung verwenden.

AWS Batch auf Amazon EKS unterstützt derzeit die folgenden Kubernetes Versionen:

  • 1.29

  • 1.28

  • 1.27

  • 1.26

  • 1.25

  • 1.24

  • 1.23

Instance-Profil ist nicht vorhanden

Wenn das angegebene Instance-Profil nicht vorhanden ist, wird der Status der AWS Batch auf Amazon EKS-Datenverarbeitungsumgebung in geändertINVALID. Im statusReason Parameter wird ein Fehler angezeigt, der dem folgenden ähnelt.

CLIENT_ERROR - Instance profile arn:aws:iam::...:instance-profile/<name> does not exist

Um dieses Problem zu beheben, geben Sie ein funktionierendes Instance-Profil an oder erstellen Sie es. Weitere Informationen finden Sie unter IAM-Rolle für Amazon EKS-Knoten im Amazon EKS-Benutzerhandbuch.

Ungültiger Kubernetes Namespace

Wenn AWS Batch in Amazon EKS den Namespace für die Datenverarbeitungsumgebung nicht validieren kann, wird der Status der Datenverarbeitungsumgebung in geändertINVALID. Dieses Problem kann beispielsweise auftreten, wenn der Namespace nicht vorhanden ist.

Im statusReason Parameter wird eine Fehlermeldung angezeigt, die der folgenden ähnelt.

CLIENT_ERROR - Unable to validate Kubernetes Namespace

Dieses Problem kann auftreten, wenn eine der folgenden Bedingungen zutrifft:

  • Die Kubernetes Namespace-Zeichenfolge im CreateComputeEnvironment Aufruf ist nicht vorhanden. Weitere Informationen finden Sie unter CreateComputeEnvironment.

  • Die erforderlichen RBAC-Berechtigungen (Role-Based Access Control) zur Verwaltung des Namespace sind nicht korrekt konfiguriert.

  • AWS Batch hat keinen Zugriff auf den Amazon-EKSKubernetes-API-Server-Endpunkt.

Informationen zum Beheben dieses Problems finden Sie unter Überprüfen Sie, ob die korrekt konfiguriert aws-auth ConfigMap ist. Weitere Informationen finden Sie unter Erste Schritte mit AWS Batch in Amazon EKS.

Gelöschte Datenverarbeitungsumgebung

Angenommen, Sie löschen einen Amazon-EKS-Cluster, bevor Sie den AWS Batch in der Amazon-EKS-Datenverarbeitungsumgebung angefügten löschen. Anschließend wird der Status der Datenverarbeitungsumgebung in geändertINVALID. In diesem Szenario funktioniert die Datenverarbeitungsumgebung nicht richtig, wenn Sie den Amazon-EKS-Cluster mit demselben Namen neu erstellen.

Um dieses Problem zu beheben, löschen Sie die AWS Batch in der Amazon-EKS-Datenverarbeitungsumgebung und erstellen Sie sie dann neu.

Knoten treten dem Amazon-EKS-Cluster nicht bei

AWS Batch auf Amazon EKS skaliert eine Datenverarbeitungsumgebung herunter, wenn festgestellt wird, dass nicht alle Knoten dem Amazon-EKS-Cluster beigetreten sind. Wenn AWS Batch Amazon EKS die Datenverarbeitungsumgebung herunterskaliert, wird der Status der Datenverarbeitungsumgebung in geändertINVALID.

Anmerkung

AWS Batch ändert den Status der Datenverarbeitungsumgebung nicht sofort, sodass Sie das Problem debuggen können.

Im statusReason Parameter wird eine Fehlermeldung angezeigt, die einer der folgenden ähnelt:

Your compute environment has been INVALIDATED and scaled down because none of the instances joined the underlying ECS Cluster. Common issues preventing instances joining are the following: VPC/Subnet configuration preventing communication to ECS, incorrect Instance Profile policy preventing authorization to ECS, or customized AMI or LaunchTemplate configurations affecting ECS agent.

Your compute environment has been INVALIDATED and scaled down because none of the nodes joined the underlying Amazon EKS Cluster. Common issues preventing nodes joining are the following: networking configuration preventing communication to Amazon EKS Cluster, incorrect Amazon EKS Instance Profile or Kubernetes RBAC policy preventing authorization to Amazon EKS Cluster, customized AMI or LaunchTemplate configurations affecting Amazon EKS/Kubernetes node bootstrap.

Bei Verwendung eines standardmäßigen Amazon-EKS-AMI sind die häufigsten Ursachen für dieses Problem die folgenden:

AWS Batch in Amazon-EKS-Auftrag bleibt im RUNNABLE Status hängen

Ein aws-auth ConfigMap wird automatisch erstellt und auf Ihren Cluster angewendet, wenn Sie eine verwaltete Knotengruppe oder eine Knotengruppe mit erstelleneksctl. Ein aws-auth ConfigMap wird zunächst erstellt, damit Knoten Ihrem Cluster beitreten können. Sie verwenden jedoch auch die , aws-authConfigMap um Benutzern und Rollen Zugriff auf die rollenbasierte Zugriffskontrolle (RBAC) hinzuzufügen.

So überprüfen Sie, ob korrekt konfiguriert aws-auth ConfigMap ist:

  1. Rufen Sie die zugeordneten Rollen in der aws-auth abConfigMap:

    $ kubectl get configmap -n kube-system aws-auth -o yaml
  2. Stellen Sie sicher, dass wie folgt konfiguriert roleARN ist.

    rolearn: arn:aws:iam::aws_account_number:role/AWSServiceRoleForBatch

    Anmerkung

    Sie können auch die Protokolle der Amazon-EKS-Steuerebene überprüfen. Weitere Informationen finden Sie unter Amazon-EKS-Steuerebenenprotokollierung im Amazon-EKS-Benutzerhandbuch.

Um ein Problem zu beheben, bei dem ein Auftrag in einem -RUNNABLEStatus hängen bleibt, empfehlen wir Ihnen, zu verwenden, kubectl um das Manifest erneut anzuwenden. Weitere Informationen finden Sie unter Schritt 1: Vorbereiten Ihres Amazon-EKS-Clusters für AWS Batch. Oder Sie können verwenden, kubectl um die manuell zu bearbeitenaws-authConfigMap. Weitere Informationen finden Sie unter Aktivieren des IAM-Benutzer- und Rollenzugriffs auf Ihren Cluster im Amazon-EKS-Benutzerhandbuch.

Überprüfen Sie, ob die korrekt konfiguriert aws-auth ConfigMap ist

So überprüfen Sie, ob korrekt konfiguriert aws-auth ConfigMap ist:

  1. Rufen Sie die zugeordneten Rollen in der aws-auth abConfigMap.

    $ kubectl get configmap -n kube-system aws-auth -o yaml
  2. Stellen Sie sicher, dass wie folgt konfiguriert roleARN ist.

    rolearn: arn:aws:iam::aws_account_number:role/AWSServiceRoleForBatch

    Anmerkung

    Der Pfad aws-service-role/batch.amazonaws.com/ wurde aus dem ARN der serviceverknüpften Rolle entfernt. Dies liegt an einem Problem mit der aws-auth Konfigurationszuordnung. Weitere Informationen finden Sie unter Rollen mit Pfaden funktionieren nicht, wenn der Pfad in ihrem ARN enthalten ist im aws-authconfigmap.

    Anmerkung

    Sie können auch die Protokolle der Amazon-EKS-Steuerebene überprüfen. Weitere Informationen finden Sie unter Amazon-EKS-Steuerebenenprotokollierung im Amazon-EKS-Benutzerhandbuch.

Um ein Problem zu beheben, bei dem ein Auftrag in einem -RUNNABLEStatus hängen bleibt, empfehlen wir Ihnen, zu verwenden, kubectl um das Manifest erneut anzuwenden. Weitere Informationen finden Sie unter Schritt 1: Vorbereiten Ihres Amazon-EKS-Clusters für AWS Batch. Oder Sie können verwenden, kubectl um die manuell zu bearbeitenaws-authConfigMap. Weitere Informationen finden Sie unter Aktivieren des IAM-Benutzer- und Rollenzugriffs auf Ihren Cluster im Amazon-EKS-Benutzerhandbuch.

RBAC-Berechtigungen oder -Bindungen sind nicht richtig konfiguriert

Wenn RBAC-Berechtigungen oder Bindungsprobleme auftreten, überprüfen Sie, ob die aws-batch Kubernetes Rolle auf den Kubernetes Namespace zugreifen kann:

$ kubectl get namespace namespace --as=aws-batch
$ kubectl auth can-i get ns --as=aws-batch

Sie können auch den kubectl describe Befehl verwenden, um die Autorisierungen für eine Clusterrolle oder einen Kubernetes Namespace anzuzeigen.

$ kubectl describe clusterrole aws-batch-cluster-role

Es folgt eine Beispielausgabe.

Name: aws-batch-cluster-role Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- configmaps [] [] [get list watch] nodes [] [] [get list watch] pods [] [] [get list watch] daemonsets.apps [] [] [get list watch] deployments.apps [] [] [get list watch] replicasets.apps [] [] [get list watch] statefulsets.apps [] [] [get list watch] clusterrolebindings.rbac.authorization.k8s.io [] [] [get list] clusterroles.rbac.authorization.k8s.io [] [] [get list] namespaces [] [] [get]
$ kubectl describe role aws-batch-compute-environment-role -n my-aws-batch-namespace

Es folgt eine Beispielausgabe.

Name: aws-batch-compute-environment-role Labels: <none> Annotations: <none> PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- pods [] [] [create get list watch delete patch] serviceaccounts [] [] [get list] rolebindings.rbac.authorization.k8s.io [] [] [get list] roles.rbac.authorization.k8s.io [] [] [get list]

Um dieses Problem zu beheben, wenden Sie die RBAC-Berechtigungen und -rolebindingBefehle erneut an. Weitere Informationen finden Sie unter Schritt 1: Vorbereiten Ihres Amazon-EKS-Clusters für AWS Batch.