Envoy can be configured from a static local file or dynamically through xDS. What is xDS, and what configuration does an xDS-driven Envoy still have to read from a local file?

## What problem xDS solves A classic reverse proxy is configured by a file. You edit it, you signal the process, it re-reads the file. That model assumes configuration changes rarely and that a human wrote it. In a dynamic environment — instances appearing and disappearing, routes shifting during a deploy — a file plus a reload is the wrong shape: the file has to be regenerated by something, written to every host, and every proxy has to be told to re-read it, with no feedback about whether it worked. Envoy inverts this. It exposes a set of gRPC/REST APIs, collectively called **xDS**, that it *consumes* as a client. Some other process — the control plane, or management server — implements the server side and pushes configuration to each connected proxy. Envoy applies each update in place on the running process. ## The resource types Each discovery service carries one kind of resource: - **LDS** — Listener Discovery Service: the listeners (sockets and their filter chains). - **RDS** — Route Discovery Service: the route configurations an HTTP listener refers to by name. - **CDS** — Cluster Discovery Service: the upstream clusters. - **EDS** — Endpoint Discovery Service: the actual endpoint addresses backing a cluster. - **SDS** — Secret Discovery Service: TLS certificates and keys, so private keys never have to sit in a config file on disk. There are more (runtime layers, extension configs, scoped routes), but these five are what interviewers mean by xDS. Each is delivered as a stream of typed resources, and each is optional — you can run any mix of static and dynamic configuration. ## The bootstrap stays static The one thing that cannot come over xDS is the description of how to reach the management server. Envoy reads a bootstrap file at startup (`-c bootstrap.yaml`) containing: ```yaml node: id: sidecar-1 cluster: checkout dynamic_resources: lds_config: { ads: {}, resource_api_version: V3 } cds_config: { ads: {}, resource_api_version: V3 } ads_config: api_type: GRPC transport_api_version: V3 grpc_services: - envoy_grpc: { cluster_name: xds_cluster } static_resources: clusters: - name: xds_cluster # ... address of the control plane ``` The cluster named by an xDS `ConfigSource` must be defined in `static_resources`; it is bootstrapped, not discovered. The `node` block matters too — the control plane usually decides *what* to send based on the node id and metadata the proxy presents on connect. ## Transport options `api_type` selects how updates arrive: `GRPC` (a streaming bidirectional connection, the normal choice), `DELTA_GRPC` (the incremental variant), or `REST` (Envoy polls a URL on a `refresh_delay`). Streaming gRPC is what makes push semantics possible — the server sends when something changes rather than waiting to be asked. `transport_api_version: V3` pins the API version; v2 was removed from Envoy some years ago. A `ConfigSource` can also be `path` — a file Envoy watches. That is still "dynamic" configuration in Envoy's sense (it goes through the same update machinery, acknowledgements and warming) even though no control plane is involved, and it is a common way to run xDS-style config without writing a gRPC server. ## What is still not dynamic Three things need a process restart: 1. **Bootstrap changes** — node id, admin port, the xDS cluster's address, most `layered_runtime` wiring. 2. **A new binary or a new set of compiled-in extensions.** 3. **Anything below Envoy** — the container image, the mounted filesystem. For these Envoy offers *hot restart*: a new process starts with an incremented `--restart-epoch`, takes over the listening sockets from the old process over a unix domain socket, inherits its stats, and the old process drains and exits. That is a separate mechanism from xDS and is used far less often once xDS is in place, because the things people used to restart for are now pushed. ## The mental model to carry into an interview Static file configuration answers "what should this proxy do?" once, at start. xDS answers it continuously, and makes the proxy a *data plane* — a thing whose behaviour is owned by a control plane rather than by whoever last edited a file on the box. Every other xDS question (ordering, acceptance and rejection, warming) falls out of that: once configuration is a stream of updates into a live process, you need a way to sequence them, a way to say "I rejected that", and a way to avoid switching to a new version before it is ready.