-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Allow configuring envoy connection draining #252
Comments
Notes on deregistration delay here: aws/containers-roadmap#1039 |
how far are we with this? |
@MattiasKurvits We're currently working on building a solution around this. We'll post here when we have more details to share. |
In AppMesh Envoy version > Closing the issue, feel free to reopen or cut a new issue if this feature doesn't solve your use case. |
If you want to see App Mesh implement this idea, please upvote with a 👍.
Tell us about your request
Allow configuring envoy connection draining
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/draining
Which integration(s) is this request for?
This could be Fargate, ECS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Currently we are using ALB target groups with ECS for draining connections. This helps us avoid 5xx errors during scale-ins/deployments.
With move to appmesh, it would be great if we could use envoy's connection draining functionality. The default behaviour for envoy is to close connections immediately. Appmesh should support configuring envoy's graceful drain period and send a request to this endpoint after the task enters the
DEACTIVATING
state, wait fordrain-time-s
and proceed to sending SIGTERM to the container.ref: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/draining
Are you currently working around this issue?
By using target group
deregistration_delay
, which is unnecessary complicating our architecture because we only use this feature of the target group.Additional context
Evaluating move to appmesh
The text was updated successfully, but these errors were encountered: