Résolution des problèmes AWS Batch - AWS Batch
AWS BatchAWS Batch sur Amazon EKS

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes AWS Batch

Vous devrez peut-être résoudre des problèmes liés à vos environnements informatiques, à vos files d'attente de tâches, à vos définitions de tâches ou à vos tâches. Ce chapitre explique comment résoudre ces problèmes dans votre AWS Batch environnement.

AWS Batch utilise les politiques, les rôles et les autorisations IAM et s'exécute sur l'infrastructure Amazon EC2, Amazon ECS et Amazon AWS Fargate Elastic Kubernetes Service. Pour résoudre les problèmes liés à ces services, consultez les rubriques suivantes :

AWS Batch

INVALIDenvironnement informatique

Il est possible que vous ayez mal configuré un environnement informatique géré. Si c'est le cas, l'environnement informatique entre dans un INVALID état et ne peut pas accepter de postes à des fins de placement. Les sections suivantes décrivent les causes possibles et la procédure de dépannage en fonction de la cause.

Nom de rôle ou ARN incorrect

La raison la plus courante pour laquelle un environnement informatique entre dans un INVALID état est que le rôle de AWS Batch service ou le rôle Amazon EC2 Spot Fleet porte un nom ou un nom de ressource Amazon (ARN) incorrect. Cela est plus courant dans les environnements informatiques créés à l'aide du AWS CLI ou des AWS SDK. Lorsque vous créez un environnement informatique dans le AWS Management Console, AWS Batch cela vous aide à choisir le service ou les rôles Spot Fleet appropriés. Supposons toutefois que vous saisissiez manuellement le nom ou l'ARN et que vous ne les saisissiez pas correctement. Ensuite, l'environnement de calcul qui en résulte l'est égalementINVALID.

Supposons toutefois que vous saisissiez manuellement le nom ou l'ARN d'une ressource IAM dans une AWS CLI commande ou dans le code de votre SDK. Dans ce cas, AWS Batch impossible de valider la chaîne. AWS Batch Il faut plutôt accepter la mauvaise valeur et tenter de créer l'environnement. Si la création de l'environnement AWS Batch échoue, celui-ci passe à un INVALID état et les erreurs suivantes s'affichent.

Pour un rôle de service non valide :

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

Pour un rôle de parc d'instances Spot non valide :

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

L'une des causes fréquentes de ce problème est le scénario suivant. Vous ne spécifiez le nom d'un rôle IAM que lorsque vous utilisez le AWS CLI ou les AWS SDK, au lieu du nom complet de la ressource Amazon (ARN). Selon la façon dont vous avez créé le rôle, l'ARN peut contenir un préfixe de aws-service-role chemin. Par exemple, si vous créez manuellement le rôle de AWS Batch service à l'aide des procédures décrites dansUtilisation de rôles liés à un service pour AWS Batch, l'ARN de votre rôle de service peut ressembler à ce qui suit.

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

Toutefois, si vous avez créé le rôle de service dans le cadre de l'assistant de première exécution de la console aujourd'hui, l'ARN de votre rôle de service peut ressembler à ce qui suit.

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

Ce problème peut également se produire si vous associez la politique de AWS Batch niveau de service (AWSBatchServiceRole) à un rôle non lié au service. Par exemple, vous pouvez recevoir un message d'erreur semblable au suivant dans ce scénario : 

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

Pour résoudre ce problème, effectuez l'une des opérations suivantes.

  • Utilisez une chaîne vide pour le rôle de service lorsque vous créez l'environnement de AWS Batch calcul.

  • Spécifiez le rôle de service au format suivant :arn:aws:iam::account_number:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch.

Lorsque vous spécifiez uniquement le nom d'un rôle IAM lorsque vous utilisez le AWS CLI ou les AWS SDK, cela AWS Batch suppose que votre ARN n'utilise pas le préfixe de aws-service-role chemin. C'est pourquoi nous vous recommandons de spécifier l'ARN complet pour vos rôles IAM lorsque vous créez des environnements informatiques.

Pour réparer un environnement informatique mal configuré de cette façon, consultezRéparation d'un environnement INVALID informatique.

Réparation d'un environnement INVALID informatique

Lorsqu'un environnement informatique est dans un INVALID état, mettez-le à jour pour réparer le paramètre non valide. Dans le cas Nom de rôle ou ARN incorrect contraire, mettez à jour l'environnement de calcul en utilisant le rôle de service approprié.

Pour réparer un environnement de calcul mal configuré

  1. Ouvrez la AWS Batch console à l'adresse https://console.aws.amazon.com/batch/.

  2. Dans la barre de navigation, sélectionnez le Région AWS à utiliser.

  3. Dans le panneau de navigation, choisissez Environnements de calcul.

  4. Sur la page Environnements de calcul, cochez la case en regard de l'environnement de calcul à modifier, puis choisissez Modifier.

  5. Sur la page Mettre à jour l'environnement de calcul, pour Rôle de service, choisissez le rôle IAM à utiliser avec votre environnement de calcul. La console AWS Batch affiche uniquement les rôles ayant la relation d'approbation appropriée pour les environnements de calcul.

  6. Choisissez Enregistrer pour mettre à jour votre environnement de calcul.

Offres d'emploi bloquées dans un RUNNABLE statut

Supposons que votre environnement informatique contienne des ressources informatiques, mais que vos tâches ne progressent pas au-delà de RUNNABLE leur statut. Dans ce cas, il est probable que quelque chose empêche le placement des tâches sur une ressource informatique et bloque vos files d'attente de tâches. Voici comment savoir si votre tâche attend son tour ou si elle est bloquée et bloque la file d'attente.

S'il AWS Batch détecte que vous avez une RUNNABLE tâche en tête et que vous bloquez la file d'attente, vous recevrez un événement de blocage de la part d'Amazon CloudWatch Events indiquant le motif du blocage. La même raison est également mise à jour dans le statusReason champ dans le cadre ListJobs d'appels d'DescribeJobsAPI.

Vous pouvez éventuellement configurer le jobStateTimeLimitActions paramètre par le biais CreateJobQueue d'actions UpdateJobQueued'API.

Note

À l'heure actuelle, la seule action que vous pouvez utiliser jobStateLimitActions.action est d'annuler une tâche.

Le jobStateTimeLimitActions paramètre est utilisé pour spécifier un ensemble d'actions exécutées AWS Batch sur des tâches dans un état spécifique. Vous pouvez définir un seuil de temps en secondes via le maxTimeSeconds champ.

Lorsqu'une tâche est dans un RUNNABLE état définistatusReason, AWS Batch exécute l'action spécifiée après son maxTimeSeconds expiration.

Par exemple, vous pouvez définir le jobStateTimeLimitActions paramètre pour qu'il attende jusqu'à 4 heures pour toute tâche dont l'RUNNABLEétat attend la disponibilité d'une capacité suffisante. Vous pouvez le faire en statusReason réglant sur 144000 avant d'annuler la tâche et de laisser la tâche suivante passer en tête de file d'attente. CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY maxTimeSeconds

Voici les raisons invoquées lorsqu' AWS Batch il détecte qu'une file d'attente de tâches est bloquée. Cette liste fournit les messages renvoyés par les actions ListJobs et DescribeJobs API. Il s'agit également des mêmes valeurs que vous pouvez définir pour le jobStateLimitActions.statusReason paramètre.

  1. Raison : tous les environnements informatiques connectés présentent des erreurs de capacité insuffisante. Sur demande, AWS Batch détecte les instances Amazon EC2 présentant des erreurs de capacité insuffisante. L'annulation de la tâche, manuellement ou en activant le jobStateTimeLimitActions paramètrestatusReason, permet à la tâche suivante de passer en tête de file d'attente.

    • statusReasonmessage lorsque la tâche est bloquée : CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]

    • reasonutilisé pour jobStateTimeLimitActions : CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    • statusReasonmessage après l'annulation de la tâche : Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    Remarque :

    1. Le rôle AWS Batch de service nécessite une autoscaling:DescribeScalingActivities autorisation pour que cette détection fonctionne. Si vous utilisez le rôle AWSServiceRoleForBatchlié à un service (SLR) ou la politique AWSBatchServiceRolePolicygérée, vous n'avez aucune action à effectuer car leurs politiques d'autorisation sont mises à jour.

    2. Si vous utilisez le SLR ou la politique gérée, vous devez ajouter les ec2:DescribeSpotFleetRequestHistory autorisations autoscaling:DescribeScalingActivities et afin de pouvoir recevoir les événements de file d'attente de tâches bloqués et le statut des tâches mis à jour lorsque vous êtes connectéRUNNABLE. En outre, AWS Batch a besoin de ces autorisations pour effectuer des cancellation actions via le jobStateTimeLimitActions paramètre, même si elles sont configurées dans la file d'attente des tâches.

    3. Dans le cas d'une tâche multinode parallel (MNP), si l'environnement de calcul Amazon EC2 à priorité élevée associé rencontre des insufficient capacity erreurs, il bloque la file d'attente même si un environnement de calcul de priorité inférieure rencontre cette erreur.

  2. Raison : Tous les environnements informatiques ont un maxvCpusparamètre inférieur aux exigences de la tâche. L'annulation de la tâche, manuellement ou en activant le jobStateTimeLimitActions paramètrestatusReason, permet à la tâche suivante de passer en tête de file d'attente. Vous pouvez éventuellement augmenter le maxvCpus paramètre de l'environnement informatique principal pour répondre aux besoins de la tâche bloquée.

    • statusReasonmessage lorsque la tâche est bloquée : MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.

    • reasonutilisé pour jobStateTimeLimitActions : MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

    • statusReasonmessage après l'annulation de la tâche : Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

  3. Raison : aucun environnement informatique ne possède d'instance répondant aux exigences du poste. Lorsqu'une tâche demande des ressources, AWS Batch détecte qu'aucun environnement informatique associé n'est en mesure de prendre en charge la tâche entrante. L'annulation de la tâche, manuellement ou en activant le jobStateTimeLimitActions paramètrestatusReason, permet à la tâche suivante de passer en tête de file d'attente. Vous pouvez éventuellement redéfinir les types d'instances autorisés dans l'environnement de calcul pour ajouter les ressources de travail nécessaires.

    • statusReasonmessage lorsque la tâche est bloquée : 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.

    • reasonutilisé pour jobStateTimeLimitActions : MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

    • statusReasonmessage après l'annulation de la tâche : Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

  4. Raison : Tous les environnements informatiques présentent des problèmes de rôle de service. Pour résoudre ce problème, comparez vos autorisations de rôle de service aux autorisations de rôle de service AWS Batch géré et corrigez les éventuelles lacunes.

    Il est recommandé d'utiliser le AWS Batch SLR dans les environnements informatiques afin d'éviter des erreurs similaires.

    L'annulation de la tâche, manuellement ou en activant le jobStateTimeLimitActions paramètrestatusReason, permet à la tâche suivante de passer en tête de file d'attente. Si le ou les problèmes liés au rôle de service ne sont pas résolus, il est probable que la prochaine tâche soit également bloquée. Il est préférable d'étudier et de résoudre ce problème manuellement.

    • statusReasonmessage lorsque la tâche est bloquée : MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

    • reasonutilisé pour jobStateTimeLimitActions : MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

    • statusReasonmessage après l'annulation de la tâche : Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS

  5. Raison : Tous les environnements informatiques ne sont pas valides. Pour plus d'informations, consultez la section Environnement de INVALID calcul. Remarque : Vous ne pouvez pas configurer une action programmable via le jobStateTimeLimitActions paramètre pour résoudre cette erreur.

    • statusReasonmessage lorsque la tâche est bloquée : ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. Raison : AWS Batch a détecté une file d'attente bloquée, mais n'est pas en mesure d'en déterminer la raison. Remarque : Vous ne pouvez pas configurer une action programmable via le jobStateTimeLimitActions paramètre pour résoudre cette erreur. Pour plus d'informations sur le dépannage, consultez Pourquoi mon AWS Batch travail est-il bloqué dans RUNNABLE ou dans AWS Re:post.

    • statusReasonmessage lorsque la tâche est bloquée : UNDETERMINED - Batch job is blocked, root cause is undetermined.

Si vous n'avez pas reçu d'événement de la part d' CloudWatch Events ou si vous avez reçu un événement pour une raison inconnue, voici quelques causes courantes de ce problème.

Le pilote de awslogs journal n'est pas configuré sur vos ressources informatiques

AWS Batch les tâches envoient leurs informations de journal à CloudWatch Logs. Dans ce cas, vous devez configurer vos ressources de calcul de manière à ce qu'elles utilisent le pilote de journal awslogs. Supposons que vous basiez votre AMI de ressources de calcul sur l'AMI optimisée pour Amazon ECS (ou Amazon Linux). Ce pilote est ensuite enregistré par défaut dans le ecs-init package. Supposons maintenant que vous utilisiez une autre AMI de base. Vous devez ensuite vérifier que le pilote de awslogs journal est spécifié comme pilote de journal disponible avec la variable d'ECS_AVAILABLE_LOGGING_DRIVERSenvironnement lorsque l'agent de conteneur Amazon ECS est démarré. Pour plus d’informations, consultez Spécification de l'AMI des ressources de calcul et Création d'une AMI de ressources de calcul.

Ressources insuffisantes

Si vos définitions de tâches spécifient plus de ressources de processeur ou de mémoire que ce que vos ressources de calcul peuvent allouer, vos tâches ne sont jamais placées. Supposons, par exemple, que votre tâche spécifie 4 GiB de mémoire et que vos ressources de calcul soient inférieures à celles disponibles. Il arrive alors que la tâche ne puisse pas être placée sur ces ressources informatiques. Dans ce cas, vous devez réduire la mémoire spécifiée dans la définition de tâche ou ajouter des ressources de calcul à votre environnement. Une partie de la mémoire est réservée à l'agent de conteneur Amazon ECS et à d'autres processus critiques du système. Pour plus d’informations, consultez Ressource de calcul Gestion de la mémoire.

Pas d'accès à Internet pour les ressources informatiques

Les ressources de calcul ont besoin de communiquer avec le point de terminaison de service Amazon ECS service. Cela peut être via un point de terminaison d'un VPC d'interface ou via vos ressources de calcul ayant des adresses IP publiques.

Pour plus d'informations sur les points de terminaison d'un VPC d'interface, veuillez consulter Points de terminaison d'un VPC d'interface Amazon ECS AWS PrivateLink) dans le Guide du développeur Amazon Elastic Container Service.

Si vous n'avez pas de point de terminaison d'un VPC d'interface configuré et que vos ressources de calcul n'ont pas d'adresses IP publiques, elles doivent utiliser la traduction d'adresse réseau (NAT) pour fournir cet accès. Pour de plus amples informations, veuillez consulter Passerelles NAT dans le Guide de l'utilisateur Amazon VPC. Pour plus d’informations, consultez Création d'un VPC.

Limite d'instances Amazon EC2 atteinte

Le nombre d'instances Amazon EC2 dans lesquelles votre compte peut être lancé Région AWS est déterminé par votre quota d'instances EC2. Certains types d'instances sont également soumis à un per-instance-type quota. Pour plus d'informations sur le quota d'instances Amazon EC2 de votre compte, notamment sur la manière de demander une augmentation de limite, consultez les limites de service Amazon EC2 dans le guide de l'utilisateur Amazon EC2.

L'agent de conteneur Amazon ECS n'est pas installé

L'agent de conteneur Amazon ECS doit être installé sur l'Amazon Machine Image (AMI) pour permettre l' AWS Batch exécution de tâches. L'agent de conteneur Amazon ECS est installé par défaut sur les AMI optimisées Amazon ECS. Pour plus d'informations sur l'agent de conteneur Amazon ECS, consultez la section relative à l'agent de conteneur Amazon ECS dans le guide du développeur Amazon Elastic Container Service.

Pour plus d'informations, voir Pourquoi mon AWS Batch travail est-il RUNNABLE bloqué ? dans Re:post.

Instances ponctuelles non étiquetées lors de la création

Le balisage des instances Spot pour les ressources de AWS Batch calcul est pris en charge depuis le 25 octobre 2017. Auparavant, la politique gérée par IAM recommandée (AmazonEC2SpotFleetRole) pour le rôle Amazon EC2 Spot Fleet ne contenait pas d'autorisations permettant de baliser les instances Spot lors du lancement. La nouvelle politique gérée par IAM recommandée s'appelleAmazonEC2SpotFleetTaggingRole. Il prend en charge le balisage des instances Spot au lancement.

Pour corriger le balisage des instances Spot lors de leur création, suivez la procédure suivante pour appliquer la politique de gestion IAM actuellement recommandée à votre rôle Amazon EC2 Spot Fleet. Ainsi, toutes les futures instances Spot créées avec ce rôle seront autorisées à appliquer des balises d'instance lors de leur création.

Pour appliquer la politique gérée par IAM actuelle à votre rôle Amazon EC2 Spot Fleet

  1. Ouvrez la console IAM à l’adresse https://console.aws.amazon.com/iam/.

  2. Choisissez Rôles, puis choisissez votre rôle Amazon EC2 Spot Fleet.

  3. Choisissez Attach policy (Attacher une politique).

  4. Sélectionnez l'AmazonEC2, SpotFleetTaggingRole puis choisissez Attach policy.

  5. Choisissez à nouveau votre rôle dans Amazon EC2 Spot Fleet pour supprimer la politique précédente.

  6. Sélectionnez le x à droite de la SpotFleetRole politique AmazonEC2, puis choisissez Détacher.

Les instances ponctuelles ne sont pas réduites

AWS Batch a introduit le rôle AWSServiceRoleForBatchlié au service le 10 mars 2021. Si aucun rôle n'est spécifié dans le serviceRole paramètre de l'environnement de calcul, ce rôle lié au service est utilisé comme rôle de service. Supposons toutefois que le rôle lié à un service soit utilisé dans un environnement de calcul EC2 Spot, mais que le rôle Spot utilisé n'inclut pas la politique gérée par SpotFleetTaggingRoleAmazonEC2. Dans ce cas, l'instance Spot n'est pas réduite. Par conséquent, vous recevrez un message d'erreur avec le message suivant : « Vous n'êtes pas autorisé à effectuer cette opération ». Procédez comme suit pour mettre à jour le rôle de flotte ponctuelle que vous utilisez dans le spotIamFleetRole paramètre. Pour plus d'informations, consultez les sections Utilisation de rôles liés à un service et Création d'un rôle pour déléguer des autorisations à un AWS service dans le Guide de l'utilisateur IAM.

Associez la politique SpotFleetTaggingRole gérée par AmazonEC2 à votre rôle Spot Fleet dans le AWS Management Console

Pour appliquer la politique gérée par IAM actuelle à votre rôle Amazon EC2 Spot Fleet

  1. Ouvrez la console IAM à l’adresse https://console.aws.amazon.com/iam/.

  2. Choisissez Rôles, puis choisissez votre rôle Amazon EC2 Spot Fleet.

  3. Choisissez Attach policy (Attacher une politique).

  4. Sélectionnez l'AmazonEC2, SpotFleetTaggingRole puis choisissez Attach policy.

  5. Choisissez à nouveau votre rôle dans Amazon EC2 Spot Fleet pour supprimer la politique précédente.

  6. Sélectionnez le x à droite de la SpotFleetRole politique AmazonEC2, puis choisissez Détacher.

Associez la politique SpotFleetTaggingRole gérée par Amazon EC2 à votre rôle Spot Fleet à l'aide du AWS CLI

Les exemples de commandes supposent que votre rôle Amazon EC2 Spot Fleet s'appelle AmazonEC2. SpotFleetRole Si votre rôle utilise un nom différent, ajustez les commandes en conséquence.

Pour associer la politique SpotFleetTaggingRole gérée par AmazonEC2 à votre rôle Spot Fleet

  1. Pour associer la politique IAM SpotFleetTaggingRole gérée par AmazonEC2 à votre SpotFleetRole rôle AmazonEC2, exécutez la commande suivante à l'aide du. AWS CLI

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

  2. Pour dissocier la politique IAM SpotFleetRole gérée par AmazonEC2 de votre SpotFleetRole rôle AmazonEC2, exécutez la commande suivante à l'aide du. AWS CLI

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

Impossible de récupérer les secrets de Secrets Manager

Si vous utilisez une AMI avec un agent Amazon ECS antérieur à la version 1.16.0-1, vous devez utiliser la variable de configuration de l'agent Amazon ECS ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true pour utiliser cette fonctionnalité. Vous pouvez l'ajouter au ./etc/ecs/ecs.config fichier d'une nouvelle instance de conteneur lorsque vous créez cette instance. Vous pouvez également l'ajouter à une instance existante. Si vous l'ajoutez à une instance existante, vous devez redémarrer l'agent ECS après l'avoir ajouté. Pour plus d'informations, consultez Configuration de l'agent du conteneur Amazon ECS dans le Manuel du développeur Amazon Elastic Container Service.

Impossible de contourner les exigences en ressources liées à la définition des tâches

Les remplacements de mémoire et de vCPU spécifiés dans la structure memory et les vcpus membres de la structure ContainerOverrides, qui ont été transmis à SubmitJob, ne peuvent pas remplacer les exigences en matière de mémoire et de vCPU spécifiées dans la structure ResourceRequirements de la définition de tâche.

Si vous essayez de contourner ces exigences en matière de ressources, le message d'erreur suivant peut s'afficher :

« Cette valeur a été soumise dans une clé obsolète et peut entrer en conflit avec la valeur fournie par les exigences en ressources de la définition de tâche. »

Pour corriger cela, spécifiez les exigences en matière de mémoire et de vCPU dans le membre ResourceRequirements de ContainerOverrides. Par exemple, si vos remplacements de mémoire et de vCPU sont spécifiés dans les lignes suivantes.

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

Modifiez-les comme suit :

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

Procédez de la même manière aux exigences en matière de mémoire et de vCPU spécifiées dans l'objet ContainerProperties dans la définition de la tâche. Par exemple, si vos exigences en matière de mémoire et de vCPU sont spécifiées dans les lignes suivantes.

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

Modifiez-les comme suit :

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

Message d'erreur lorsque vous mettez à jour le desiredvCpus paramètre

Le message d'erreur suivant s'affiche lorsque vous utilisez l' AWS Batch API pour mettre à jour le paramètre vCPU (desiredvCpus) souhaité.

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

Ce problème se produit si la desiredvCpus valeur mise à jour est inférieure à la desiredvCpus valeur actuelle. Lorsque vous mettez à jour la desiredvCpus valeur, les deux conditions suivantes doivent être vraies :

  • La desiredvCpus valeur doit être comprise entre les maxvCpus valeurs minvCpus et.

  • La desiredvCpus valeur mise à jour doit être supérieure ou égale à la desiredvCpus valeur actuelle.

AWS Batch sur Amazon EKS

INVALIDenvironnement informatique

Il est possible que vous ayez mal configuré un environnement informatique géré. Si c'est le cas, l'environnement informatique entre dans un INVALID état et ne peut pas accepter de postes à des fins de placement. Les sections suivantes décrivent les causes possibles et la procédure de dépannage en fonction de la cause.

Version non prise en charge Kubernetes

Un message d'erreur semblable au suivant peut s'afficher lorsque vous utilisez l'opération d'CreateComputeEnvironmentAPI ou l'opération d'UpdateComputeEnvironmentAPI pour créer ou mettre à jour un environnement de calcul. Ce problème se produit si vous spécifiez une Kubernetes version non prise en charge dansEC2Configuration.

At least one imageKubernetesVersion in EC2Configuration is not supported.

Pour résoudre ce problème, supprimez l'environnement informatique, puis recréez-le avec une Kubernetes version prise en charge.

Vous pouvez effectuer une mise à niveau de version mineure sur votre cluster Amazon EKS. Par exemple, vous pouvez mettre à niveau le cluster de 1.xx à 1.yy même si la version mineure n'est pas prise en charge.

Toutefois, l'état de l'environnement de calcul peut changer INVALID après une mise à jour majeure de la version. Par exemple, si vous effectuez une mise à niveau d'une version majeure de 1.xx vers2.yy. Si la version majeure n'est pas prise en charge par AWS Batch, un message d'erreur semblable au suivant s'affiche.

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

Pour résoudre ce problème, spécifiez une Kubernetes version prise en charge lorsque vous utilisez une opération d'API pour créer ou mettre à jour un environnement informatique.

AWS Batch sur Amazon, EKS prend actuellement en charge les Kubernetes versions suivantes :

  • 1.29

  • 1.28

  • 1.27

  • 1.26

  • 1.25

  • 1.24

  • 1.23

Le profil d'instance n'existe pas

Si le profil d'instance spécifié n'existe pas, le statut de l'environnement de calcul AWS Batch sur Amazon EKS est remplacé parINVALID. Vous voyez une erreur définie dans le statusReason paramètre qui ressemble à ce qui suit.

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

Pour résoudre ce problème, spécifiez ou créez un profil d'instance de travail. Pour de plus amples informations, veuillez consulter Rôle IAM de nœud Amazon EKS dans le Guide de l'utilisateur Amazon EKS.

Espace de Kubernetes noms non valide

Si AWS Batch sur Amazon EKS ne parvient pas à valider l'espace de noms de l'environnement de calcul, le statut de l'environnement de calcul est remplacé par. INVALID Par exemple, ce problème peut se produire si l'espace de noms n'existe pas.

Un message d'erreur semblable au suivant s'affiche dans le statusReason paramètre.

CLIENT_ERROR - Unable to validate Kubernetes Namespace

Ce problème peut se produire si l'une des conditions suivantes est vraie :

  • La chaîne d'Kubernetesespace de noms de l'CreateComputeEnvironmentappel n'existe pas. Pour plus d'informations, consultez CreateComputeEnvironment.

  • Les autorisations de contrôle d'accès basé sur les rôles (RBAC) requises pour gérer l'espace de noms ne sont pas correctement configurées.

  • AWS Batch n'a pas accès au point de terminaison du serveur Kubernetes d'API Amazon EKS.

Pour résoudre ce problème, consultez Vérifiez que le aws-auth ConfigMap est correctement configuré. Pour plus d’informations, consultez Commencer à utiliser AWS Batch Amazon EKS.

Environnement informatique supprimé

Supposons que vous supprimiez un cluster Amazon EKS avant de supprimer le cluster associé AWS Batch dans l'environnement informatique Amazon EKS. Ensuite, l'état de l'environnement de calcul est changé enINVALID. Dans ce scénario, l'environnement de calcul ne fonctionne pas correctement si vous recréez le cluster Amazon EKS portant le même nom.

Pour résoudre ce problème, supprimez puis recréez l'environnement de calcul AWS Batch sur Amazon EKS.

Les nœuds ne rejoignent pas le cluster Amazon EKS

AWS Batch sur Amazon EKS réduit un environnement de calcul s'il détermine que tous les nœuds n'ont pas rejoint le cluster Amazon EKS. Lorsque AWS Batch sur Amazon EKS réduit l'environnement de calcul, le statut de l'environnement de calcul est modifié enINVALID.

Note

AWS Batch ne modifie pas immédiatement l'état de l'environnement informatique afin que vous puissiez résoudre le problème.

Un message d'erreur semblable à l'un des suivants s'affiche dans le statusReason paramètre :

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.

Lorsque vous utilisez une AMI Amazon EKS par défaut, les causes les plus fréquentes de ce problème sont les suivantes :

AWS Batch sur Amazon EKS, le RUNNABLE statut de la tâche est bloqué

Un aws-auth ConfigMap est automatiquement créé et appliqué à votre cluster lorsque vous créez un groupe de nœuds gérés ou un groupe de nœuds à l'aide deeksctl. Un aws-auth ConfigMap est initialement créé pour permettre aux nœuds de rejoindre votre cluster. Toutefois, vous pouvez également utiliser le aws-auth ConfigMap pour ajouter un accès de contrôle d'accès basé sur les rôles (RBAC) aux utilisateurs et aux rôles.

Pour vérifier que le aws-auth ConfigMap est correctement configuré, procédez comme suit :

  1. Récupérez les rôles mappés dans : aws-auth ConfigMap

    $ kubectl get configmap -n kube-system aws-auth -o yaml

  2. Vérifiez que le roleARN est configuré comme suit.

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

    Note

    Vous pouvez également consulter les journaux du plan de contrôle Amazon EKS. Pour plus d'informations, consultez la section Connexion au plan de contrôle Amazon EKS dans le guide de l'utilisateur Amazon EKS.

Pour résoudre un problème lié au blocage d'une tâche dans un RUNNABLE statut, nous vous recommandons de kubectl réappliquer le manifeste. Pour plus d’informations, consultez Étape 1 : Préparation de votre cluster Amazon EKS pour AWS Batch. Vous pouvez également l'utiliser kubectl pour modifier manuellement le aws-authConfigMap. Pour plus d'informations, consultez la section Activation de l'accès des utilisateurs et des rôles IAM à votre cluster dans le guide de l'utilisateur Amazon EKS.

Vérifiez que le aws-auth ConfigMap est correctement configuré

Pour vérifier que le aws-auth ConfigMap est correctement configuré, procédez comme suit :

  1. Récupérez les rôles mappés dans le aws-authConfigMap.

    $ kubectl get configmap -n kube-system aws-auth -o yaml

  2. Vérifiez que le roleARN est configuré comme suit.

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

    Note

    Le chemin aws-service-role/batch.amazonaws.com/ a été supprimé de l'ARN du rôle lié au service. Cela est dû à un problème avec la carte aws-auth de configuration. Pour plus d'informations, consultez la section Les rôles dotés de chemins ne fonctionnent pas lorsque le chemin est inclus dans leur ARN dans le aws-authconfigmap.

    Note

    Vous pouvez également consulter les journaux du plan de contrôle Amazon EKS. Pour plus d'informations, consultez la section Connexion au plan de contrôle Amazon EKS dans le guide de l'utilisateur Amazon EKS.

Pour résoudre un problème lié au blocage d'une tâche dans un RUNNABLE statut, nous vous recommandons de kubectl réappliquer le manifeste. Pour plus d’informations, consultez Étape 1 : Préparation de votre cluster Amazon EKS pour AWS Batch. Vous pouvez également l'utiliser kubectl pour modifier manuellement le aws-authConfigMap. Pour plus d'informations, consultez la section Activation de l'accès des utilisateurs et des rôles IAM à votre cluster dans le guide de l'utilisateur Amazon EKS.

Les autorisations ou les liaisons RBAC ne sont pas correctement configurées

Si vous rencontrez des problèmes d'autorisation RBAC ou de liaison, vérifiez que le aws-batch Kubernetes rôle peut accéder à l'espace de Kubernetes noms :

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

Vous pouvez également utiliser la kubectl describe commande pour afficher les autorisations associées à un rôle de cluster ou à un espace de Kubernetes noms.

$ kubectl describe clusterrole aws-batch-cluster-role

Voici un exemple de sortie.

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

Voici un exemple de sortie.

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]

Pour résoudre ce problème, réappliquez les autorisations et rolebinding les commandes RBAC. Pour plus d'informations, voir Étape 1 : Préparation de votre cluster Amazon EKS pour AWS Batch.