How the Proxy Gets Smart
Envoy is a powerful proxy, but it starts with no knowledge of your infrastructure. It does not know where your services are, what ports to listen on, or what routing rules to apply. It needs to be told — and it needs to be told dynamically, without restarts.
It receives this configuration from the control plane using a family of APIs collectively called xDS (x Discovery Services). Each API manages a different aspect of Envoy's configuration:
| API | Full Name | What It Configures |
|---|---|---|
| LDS | Listener Discovery Service | What ports Envoy opens and listens on |
| RDS | Route Discovery Service | How to route requests (e.g., /api/v1 → backend cluster) |
| CDS | Cluster Discovery Service | The upstream service groups Envoy can forward traffic to |
| EDS | Endpoint Discovery Service | The specific IP addresses of pods within each cluster |
Think of it as layers of a phone system. LDS tells Envoy which phone lines to pick up. RDS tells it which department to transfer the call to. CDS tells it which departments exist. EDS gives it the direct extension numbers of the people in each department.
When a new pod starts, istiod detects it via the Kubernetes API, generates updated EDS entries with the pod's IP, and pushes that update to all relevant Envoy sidecars — typically within a few hundred milliseconds. No restarts, no config file edits, no human intervention.
The xDS protocol is also an open standard. This means you can run Envoy as a standalone proxy and point it at any xDS-compatible control plane — not just Istio. This portability is why Envoy has become the de facto data plane for the entire service mesh ecosystem.
Interviewers often ask: "What is the difference between the control plane and data plane in a service mesh?" A strong answer distinguishes what each layer does and why they are separated. The control plane (e.g., istiod) manages configuration and certificates; the data plane (Envoy sidecars) handles actual packet processing. The separation allows configuration changes to propagate without restarting proxies or touching application code. Follow up by mentioning xDS as the protocol that connects them — this signals genuine depth.