Learn Envoy Proxy - Core Concepts & Main Architecture

#Introduction

Now we dive into Envoy's brain. Episode 2 covers core concepts and main architecture: the five core components you'll meet in every configuration — listener, filter chain, cluster, route, and endpoint — and how they all fit together in a single bootstrap file.

Beyond the components, you need to understand two major roles in the Envoy ecosystem: the control plane that makes decisions, and the data plane that executes them. The two are connected through the xDS protocol — the common language that Istio, Gloo, and other control planes use to talk to Envoy. Master this episode and all the following ones will feel like variations on the same pattern.

#The Five Core Architecture Components

#Listener and Filter Chain

A listener is the entry point for traffic: it listens on an address and port, for example 0.0.0.0:10000. Each listener can have one or more filter chains — sequences of filters that process connections before forwarding. For HTTP, the first filter is usually http_connection_manager, which turns TCP bytes into routable HTTP requests.

#Route and Virtual Host

Once an HTTP request is formed, a route determines where it's sent. Routes are grouped into virtual hosts, which are selected based on the Host header or domain. Inside a virtual host are match rules: based on path prefix, exact path, or specific headers. A route references a cluster — the collection of backends that handle the request.

#Cluster and Endpoint

A cluster is an abstraction of a single backend service, complete with load balancing policy and health checks. Inside a cluster are endpoints — the list of IP addresses and ports of the actual backend instances. When Envoy decides to send a request to a cluster, it picks one endpoint according to the configured load balancing algorithm.

curl -s localhost:9901/config_dump | head -40

The curl localhost:9901/config_dump command displays the active configuration as JSON: the list of listeners, filter chains, and clusters. This is the best way to visualize the five components above on a running Envoy.

#The Envoy Configuration Model

#The Bootstrap File

All Envoy configuration starts from a bootstrap file: a single YAML file that tells Envoy where to listen, which clusters to talk to, and how to load other configuration. Its main structure:

node:
  id: envoy-lab
  cluster: lab-cluster
static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
  clusters:
    - name: service_backend
      connect_timeout: 0.25s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
admin:
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

The configuration above contains node as Envoy's identity, static_resources for the listeners and clusters written directly, and admin for the management interface on port 9901. The static_resources block is the keyword that distinguishes static config from dynamic config.

#Static vs Dynamic

There are two ways to supply configuration:

• Static: all listeners, clusters, and routes are written directly in the bootstrap. Simple, suitable for labs and small deployments.
• Dynamic: the bootstrap only contains instructions for fetching configuration from a control plane via xDS. This is what production and service meshes use.

We'll practice both models: static in episodes 3 through 8, then dynamic in episode 9.

#Control Plane, Data Plane, and xDS

#Two Separate Sides

The data plane is Envoy itself: the proxy that actually processes traffic. The control plane is a separate component that decides policy — which services exist, at what addresses, and what retry and TLS policies apply. The control plane never touches traffic; it only sends configuration.

This separation lets policies change without touching the data plane, and lets the data plane scale independently of policy logic.

#The xDS Family

xDS is a collection of protocols that control planes use to send configuration. The five most important ones:

• LDS: Listener Discovery Service, sends the list of listeners.
• RDS: Route Discovery Service, sends routes and virtual hosts.
• CDS: Cluster Discovery Service, sends cluster definitions.
• EDS: Endpoint Discovery Service, sends the list of endpoints per cluster.
• SDS: Secret Discovery Service, sends TLS certificates and keys.

docker exec envoy-lab sh -c "ls /etc/envoy"
docker logs envoy-lab 2>&1 | tail -5

The docker logs envoy-lab command shows Envoy's startup logs. In episode 9, the same logs will show the subscription process to LDS, RDS, and CDS from a control plane.

#The Journey of One Request Through Envoy

#Request Flow

Let's assemble all the components into a single flow:

1. The client opens a TCP connection to port 10000, the listener port.
2. The listener's filter chain, especially http_connection_manager, parses the HTTP request.
3. Envoy selects a virtual host based on the Host header.
4. The matching route determines the destination cluster.
5. Envoy picks one endpoint from the cluster via the load balancing algorithm.
6. A connection is made to the endpoint, the request is forwarded, and the response returns to the client.

curl -s localhost:9901/stats | grep "^listener" | head -8

The listener statistics in the admin interface show how many connections were accepted, requests processed, and errors occurred. By understanding the flow above, you can map every number in that output to one of the stages of a request's journey.

#Closing

Episode 2 gave you a map of Envoy's architecture: the five core components assembled in a bootstrap, two configuration models, and the xDS protocol connecting control plane with data plane. The path of a single request is now clear, from listener to endpoint.

Key takeaways:

• Listeners accept traffic, filter chains process it, routes decide where it goes.
• A cluster is the backend abstraction; endpoints are the real instance addresses.
• The bootstrap file is the starting point of all Envoy configuration.
• Config can be static (written directly) or dynamic (fetched via xDS).
• The main xDS services: LDS, RDS, CDS, EDS, and SDS.
• The control plane decides policy; the data plane executes traffic.

In the next episode, episode 3, we'll discuss installation and hello Envoy — downloading the binary or running the container, assembling a minimal configuration for simple HTTP proxying, and verifying traffic through Envoy with curl. It's time to start writing config and watching Envoy work.