[READ ONLY MIRROR] Envoy REST/proto API definitions and documentation. (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

24 lines
1.6 KiB

Initialization
==============
How Envoy initializes itself when it starts up is complex. This section explains at a high level
how the process works. All of the following happens before any listeners start listening and
accepting new connections.
* During startup, the :ref:`cluster manager <arch_overview_cluster_manager>` goes through a
multi-phase initialization where it first initializes static/DNS clusters, then predefined
:ref:`SDS <arch_overview_dynamic_config_sds>` clusters. Then it initializes
:ref:`CDS <arch_overview_dynamic_config_cds>` if applicable, waits for one response (or failure),
and does the same primary/secondary initialization of CDS provided clusters.
* If clusters use :ref:`active health checking <arch_overview_health_checking>`, Envoy also does a
single active HC round.
* Once cluster manager initialization is done, :ref:`RDS <arch_overview_dynamic_config_rds>` and
:ref:`LDS <arch_overview_dynamic_config_lds>` initialize (if applicable). The server
doesn't start accepting connections until there has been at least one response (or failure) for
LDS/RDS requests.
* If LDS itself returns a listener that needs an RDS response, Envoy further waits until an RDS
response (or failure) is received. Note that this process takes place on every future listener
addition via LDS and is known as :ref:`listener warming <config_listeners_lds>`.
* After all of the previous steps have taken place, the listeners start accepting new connections.
This flow ensures that during hot restart the new process is fully capable of accepting and
processing new connections before the draining of the old process begins.