Open eilonmonday opened 2 years ago
Comment from support: I did some testing on my end with a similar configuration, and also was unable to get terminationGracePeriodSeconds to behave like you expected. It appears to us terminationGracePeriodSeconds will not delay the SIGTERM that your pods receive, instead it allows for a longer duration after the SIGTERM is sent for the underlying application to gracefully exit. The problem is that Envoy starts immediately shutting down and closing connections as soon as it receives a SIGTERM, so you will need to use a preStop hook to delay the period from when the pod is scheduled as unrouteable (i.e. it enters the terminating state) and when the SIGTERM is actually sent. Luckily, a lifecycle option for the main container, which would allow for a preStop hook, was added to the latest version of AES, and you can find resources for it here: https://github.com/emissary-ingress/emissary/pull/4030 https://github.com/emissary-ingress/emissary/blob/5f01e923a297182a08217b7651bfc1a77735391f/charts/emissary-ingress/values.yaml.in#L403 In the PR, there is an example that should work if the main container is running behind a load balancer that is slow to deregister pods.
Could you please try that and let us know?
chart: edge-stack-7.5.2 ambassador version: 2.4.2 EKS version: 1.23
I confirm that after adding lifecycle section for the main pod whatever you put there terminationGracePeriodSeconds works as intended
Describe the bug Doesn't matter what is the number we set as terminationGracePeriodSeconds, the pod is terminated after 2-3 seconds, even if it still has open connections...
To Reproduce Steps to reproduce the behavior: kubectl delete pod
Expected behavior I expect the pod to be alive for the time I set, or if it does not have an open connection to get terminated. but at the moment it is dead with the open connections...
chart: edge-stack-7.2.2 ambassador version: 2.1.2 EKS version: 1.20
Deployment yaml:
Pods logs right after I delete it: