Every request through Arion crosses the same four resources — listener, filter chain, route, cluster — and knowing which is which tells you where to configure anything.
A listener binds an address and port and accepts connections. For each connection it selects one filter chain by the chain's match criteria (destination port, SNI, source addresses). The chain's network filters run in order; for HTTP the last one is the HTTP connection manager, which runs a second list of HTTP filters ending in the router. The router matches the request against the route table — virtual hosts by domain, then routes by path and headers — and the winning route names a cluster, which load-balances the request across its endpoints.
The resources mean the same thing however they arrive: written in an envoy_bootstrap section of Arion's config file, or streamed from a control plane over xDS.
Key terms
| Term | Meaning |
|---|---|
| Listener | A bound address:port that accepts connections and owns filter chains. See listeners. |
| Filter chain | An ordered list of network filters, selected per connection by its match. See the filter chain. |
| Network filter | An L4 stage — tcp_proxy, or the HTTP connection manager. |
| HTTP filter | An L7 stage inside the HTTP connection manager; the last one is always the router. |
| Route | A match (domain, path, headers) plus an action, usually "send to this cluster". See routing. |
| Cluster | A named group of endpoints with a load-balancing policy. See upstreams. |
| Endpoint | One upstream address:port inside a cluster. |
| xDS | Envoy's discovery protocol, delivering all of the above from a control plane. See xDS control planes. |
Next
- Architecture — the runtime behind this picture.
- Life of a request — the same path, step by step.
- The filter chain — attachment points and ordering.
- Configuration model — the file and xDS forms.