Before understanding a technology, you need to understand its basic concepts and terminology. Only by immersing yourself in that context can you understand the technology. This article will introduce the basic terminology and key concepts in Envoy.
Architecture
The diagram below shows Envoy proxy’s architecture, displaying the process of host B accessing host A through Envoy. Each host may run multiple services, Envoy may have multiple Listeners, and each Listener may have multiple filters forming a chain.

The basic terminology will be explained below.
Basic Terminology
Host: An entity capable of network communication (applications on phones, servers, etc.). In Envoy, a host refers to a logical network application. Multiple hosts can run on a single physical hardware as long as each host can be independently addressed.
Downstream: Downstream hosts connect to Envoy, sending requests and receiving responses.
Upstream: Upstream hosts receive connection requests and responses from Envoy.
Cluster: A cluster is a set of logically similar upstream hosts to which Envoy connects. Envoy discovers cluster members through service discovery. Envoy can determine the health status of cluster members through active health checks. How Envoy routes requests to cluster members is determined by load balancing policies.
Mesh: A set of hosts that coordinate with each other to provide a consistent network topology. Envoy mesh refers to a set of Envoy proxies that form the messaging foundation for distributed systems composed of various different services and application platforms.
Runtime configuration: An out-of-band real-time configuration system deployed with Envoy. Operations can be affected by changing settings without restarting Envoy or changing Envoy’s main configuration.
Listener: A listener is a named network location (such as a port, Unix domain socket, etc.) to which downstream clients can connect. Envoy exposes one or more listeners for downstream hosts to connect to. Generally, one Envoy runs per host using a single process, but any number of Listeners can be started in each process. Currently, only TCP is monitored, and each listener is independently configured with a certain number of (L3/L4) network filters. Listeners can also be obtained dynamically through Listener Discovery Service (LDS).
Listener filter: Listeners use listener filters to manipulate connection metadata. Its purpose is to add more integration functionality without changing Envoy’s core functionality. The Listener filter API is relatively simple because these filters ultimately run on newly accepted sockets. They can be chained together in the chain to support more complex scenarios, such as calling rate limiting. Envoy already includes multiple listener filters.
Http Route Table: HTTP routing rules, such as the domain name of the request, which Path conforms to what rules, and which Cluster to forward to.
Health checking: Health checking is used in conjunction with SDS service discovery. However, even when using other service discovery methods, there are corresponding situations requiring active health checking. See health checking for details.
xDS
xDS is a key concept, a collective term for a class of discovery services, including:
- CDS: Cluster Discovery Service
- EDS: Endpoint Discovery Service
- SDS: Secret Discovery Service
- RDS: Route Discovery Service
- LDS: Listener Discovery Service
It is through requests to xDS that Envoy configuration is dynamically updated. Additionally, there’s ADS (Aggregated Discovery Service) which solves the update order problem of the above xDS through aggregation.
Envoy Mesh
Envoy Mesh refers to a mesh where Envoy handles load balancing and proxying. This Mesh will contain two types of envoy:
- Edge envoy: The envoy when traffic enters and leaves the mesh, equivalent to ingress in Kubernetes.
- Service envoy: The service envoy runs with each Service instance as an application-unaware out-of-process tool, running in the same pod as the application container in sidecar form in Kubernetes.
Envoy can be used as edge envoy alone, only as service envoy, or both simultaneously. All envoys in the Mesh share routing information.
Envoy Configuration
Configuration in Envoy includes two main categories: listener configuration and cluster configuration.
Listener Configuration
We know that a set of listeners can be configured in Envoy to implement complex processing logic. Listeners set the monitored TCP port and have a set of filters to process data streams on these ports.
listeners:
- address:
socket_address:
address: 0.0.0.0
[Note: Due to length constraints, this is a partial translation. The complete English translation would include detailed configuration examples and explanations.]
