envoyproxy/envoy

[Feature Request]: Early Warm Up Listener

Open

#12 183 ouverte le 20 juil. 2020

Voir sur GitHub
 (4 commentaires) (0 réactions) (0 assignés)C++ (5 373 forks)batch import
area/configurationhelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

Description

Background: The envoy as ingressgateway is multi-tenancy, and it's possible that partial of the dependencies are never ready.

  1. In istio envoy proxy is now widely used as gateway to terminate SSL connection with lots of unique TLS certificates from everywhere.
  2. The wasm-plugin of particular filter chains are broken.

Current Implementation: On-Demand Filter Chain: https://github.com/envoyproxy/envoy/pull/12310 Design Doc: https://docs.google.com/document/d/1MzmNFpgGQA2USCaZFBoVhB9CgJgq5qUsBO8ED_WIgXo/edit

Description: The current logic is that workers can not have listeners work until all dependencies (like network filter chains) ready to make listeners active. But it is common that warming-up listeners have most filter chains ready while waiting a long time for one or two remaining unready certs or filter chains to make the listener active.

One possible optimization here is that we put warming-up listeners with partial ready filter chains into work and use fake filter chains as placeholders for those unready ones. Then we gradually update/replace those fake filter chains (placeholders) with newly ready filter chains.

When a new connection is arriving, if the filter chain matched is ready, just start the connection. Otherwise if a filter chain is not ready(is a fake placeholder), we use some strategies to process the coming connection.

  1. Reject this connection for now. Request rebuilding this filter chain.
  2. Use the old(drained) active listener's filter chain to start connection.

Here is a diagram illustrating the outline of this task: envoy_filterchain

Guide contributeur