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.
Logique d'accélération des ECS services Amazon
Le planificateur ECS de services Amazon inclut une logique qui limite la fréquence à laquelle les tâches de service sont lancées si elles échouent à plusieurs reprises.
Si les tâches d'un service échouent à plusieurs reprises à passer à l'RUNNING
état (passant directement du STOPPED
statut a PENDING
au statut), le délai entre les tentatives de redémarrage suivantes est augmenté progressivement jusqu'à un maximum de 27 minutes. Cette période maximale est sujette à changement à l'avenir. Ce comportement réduit l'impact des tâches défaillantes sur les ressources de votre ECS cluster Amazon ou sur les coûts d'infrastructure de Fargate. Si votre service déclenche la logique de limitation, vous recevez le message d'événement de service suivant :
(service
service-name
) is unable to consistently start tasks successfully.
Amazon ECS n'empêche jamais un service défaillant de réessayer. Il ne tente pas non plus de le modifier autrement qu'en augmentant le temps entre les redémarrages. La logique de limitation de service ne fournit pas de paramètres modifiables par l'utilisateur.
Si vous mettez à jour le service de façon à utiliser une nouvelle définition de tâche, celui-ci renvoie un état normal et non limité immédiatement. Pour de plus amples informations, veuillez consulter Mettre à jour un ECS service Amazon à l'aide de la console.
Voici quelques causes courantes à l'origine de cette logique. Nous vous recommandons de prendre des mesures manuelles pour résoudre le problème :
-
Manque de ressources pour héberger votre tâche, telles que les ports, la mémoire ou les CPU unités de votre cluster. Dans ce cas, le message d'événement de service pour ressource insuffisante peut également s'afficher.
-
L'agent de ECS conteneur Amazon ne peut pas extraire l'image Docker de votre tâche. Cela peut être dû à un nom de l'image de conteneur, à une image, ou à une étiquette erronés, ou à un manque d'authentification ou d'autorisations de registre privé. Dans ce cas, vous pouvez également voir
CannotPullContainerError
dans les erreurs de tâche interrompue. -
Un espace disque insuffisant sur l'instance de conteneur pour créer le conteneur. Dans ce cas, vous pouvez également voir
CannotCreateContainerError
dans les erreurs de tâche interrompue. Pour de plus amples informations, veuillez consulter Résoudre les problèmes liés au Docker API error (500): devmapper dans Amazon ECS.
Important
Les tâches qui sont arrêtées après avoir atteint l'état RUNNING
ne déclenchent pas la limitation logique ou le message d'événement de service associé. Supposons, par exemple, que l'échec des tests de santé d'Elastic Load Balancing pour un service entraîne le signalement d'une tâche comme défaillante, Amazon la ECS désenregistre et arrête la tâche. À ce stade, les tâches ne sont pas limitées. Même si la commande du conteneur d'une tâche se termine immédiatement avec un code de sortie autre que zéro, la tâche est déjà passée à l'état RUNNING
. Les tâches qui échouent immédiatement en raison d'erreurs de commande ne déclenchent pas de limitation ou de message d'événement de service.