Containers-roadmap: [ECS] [request]: Seperate LoadBalancer traffic distribution from lifecycle mgmt.

Created on 14 May 2019  路  3Comments  路  Source: aws/containers-roadmap

Tell us about your request
Separate load balancer health check to serve traffic but not killing the tasks and the let the container health checks kill the tasks if required. This should help to not kill tasks that are currently under load. On ECS side, you would need to configure the behavior of how tasks are killed. We experienced issues where the ECS containers where under heavy load and could not serve LB health checks temporary, which resulted in LB to kill tasks because it considered them unhealthy.

Which service(s) is this request for?
Fargate, ECS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Today it is not possible to separate the idea of "is a task able to receive traffic" and "is a task alive and working". First this needs to be separated and second managed by different parties. While the LB only would be responsible to serve traffic, the ECS system should decide if a tasks needs restarting.

Are you currently working around this issue?
no solution

Additional context
K8S has a similar concept.

Attachments
-

ECS Proposed

Most helpful comment

In other words, we want the same Function as Kubernetes' Readiness Probes.

We also have an application where only one ECS task behaves as an under heavy load Role, and if that task goes down, the Role fails over to another ECS task.

As a workaround, we run a cron every minute to deregister-targets the ECS task for the specific role of the application from the target group to stop traffic from LB.

All 3 comments

@adlemich Thanks for the suggestion! Is this the same feature as https://github.com/aws/containers-roadmap/issues/251? Or do you view them as different?

Hi. I think they are related, both require a decoupling of the automation between ECS container status and load distribution. So a container may have a state "paused" or "overloaded" or other states where it is required to not send more traffic to it, while it is actually in a healthy state. In my case, it is required that the LB cannot kill an ECS task because of an overloaded situation at the task, which might required additional steps for a solution

In other words, we want the same Function as Kubernetes' Readiness Probes.

We also have an application where only one ECS task behaves as an under heavy load Role, and if that task goes down, the Role fails over to another ECS task.

As a workaround, we run a cron every minute to deregister-targets the ECS task for the specific role of the application from the target group to stop traffic from LB.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sarath9985 picture sarath9985  路  3Comments

clareliguori picture clareliguori  路  3Comments

talawahtech picture talawahtech  路  3Comments

tabern picture tabern  路  3Comments

miztch picture miztch  路  3Comments