1 回答
- 最新
- 投票最多
- 评论最多
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.
已回答 2 年前
相关内容
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 2 年前
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