Delay HC activation until SDS is initialized
#17.529 aberto em 28 de jul. de 2021
Métricas do repositório
- Stars
- (27.997 stars)
- Métricas de merge de PR
- (Mesclagem média 8d) (378 fundiu PRs em 30d)
Description
Description: Recently, we noticed that during the Envoy initialization, there is a race condition between when TLS is configured on a upstream cluster (like validation context) and when active healthcheck begins on that cluster, and it will take around 60s for the Envoy to initialize. In this case, we find that Envoy initiates the first healthcheck on the upstream cluster before the validation context is retrieved, resulting in a health check connection failure and the healthcheck interval will fall back to the no_traffic_interval (because there is no traffic on the cluster). While for Envoy cluster which uses STATIC_DNS and EDS this appears to not delay Envoy initialization, it appears that Envoy cluster using LOGICAL_DNS will wait out the no_traffic_interval to healthcheck again before it considers itself fully initialized.
I have create a same issue https://github.com/envoyproxy/envoy/issues/15977 before, but that issue was closed without a fix. The most close fix is this commit https://github.com/envoyproxy/envoy/pull/16236 but it wasn't be merged.