1 réponse
- Le plus récent
- Le plus de votes
- La plupart des commentaires
2
First of all, it has to be noted containers should be designed to be eviction ready.
That said, what you described is not a task reboot. The blog post you referenced has the wrong or misleading information, unfortunately.
The Fargate scheduler report status periodically and the message indicate a healthy state of the tasks specified in your task definitions, for example in ECS.
Lastly, there are situations where task container(s) might be restarted or stopped, for example due to task maintenance.
If you want you can elaborate more about your specific situations where you saw your tasks being restarted.
répondu il y a 2 ans
Contenus pertinents
- demandé il y a un an
- demandé il y a un an
- demandé il y a un mois
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a 9 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
Thanks for the official answer. Yeah, containerized tasks must be resilient and stateless. I think it's the phrasing that got me thinking. "Service X has reached a steady state" indicates an event -- from an non-steady state to steady state, that just happened. It should rather be "Service X health check: HEALTHY" or on the similar lines.
Although containers are supposed to be resilient, it is an extremely misleading event description. Saying 'service <event_name> has reached a steady state' leads the user to believe Fargate has changed something, rather than simply done a health check and found a healthy response. Particularly given there is almost no information about Fargate doing scheduled checks, it would be very useful to have this updated, and better documentation on the Fargate page to reflect what is really happening. I did find the page detailing the status messages and what they mean, and I'll put it here for others who are searching: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html