Learn Envoy Proxy - Dynamic Configuration with xDS

#Introduction

So far all configuration has been written statically in the bootstrap. Episode 9 changes your way of thinking: dynamic configuration with xDS lets Envoy receive listeners, routes, clusters, endpoints, and even certificates directly from a control plane — without restarts and without downtime.

This concept is the foundation of modern service meshes. When Istio adds a new service, the Envoy sidecar needs no manual configuration; the control plane pushes the change over xDS. You'll understand the five xDS services, how Envoy subscribes, and how control planes integrate everything.

#xDS Principles: The Five Core Services

#One Protocol Family

xDS is a family of gRPC protocols control planes use to send configuration to Envoy. Its five core services:

• CDS (Cluster Discovery Service): sends cluster definitions and their policies.
• LDS (Listener Discovery Service): sends new listener lists.
• RDS (Route Discovery Service): sends routes and virtual hosts.
• EDS (Endpoint Discovery Service): sends the list of endpoints per cluster.
• SDS (Secret Discovery Service): sends TLS certificates and keys.

The relationships among these services matter: LDS can reference RDS, CDS references EDS, and transport sockets reference SDS. Any small change on the control plane results in an update in one of these services.

#SotW vs Delta

There are two delivery modes:

• SotW (State of the World): the control plane sends the entire resource state every time something changes.
• Delta: only the differences since the last update are sent, saving bandwidth at large scale.

Most modern control planes support both and negotiate the mode when the first connection opens.

#Envoy as an xDS Client

#Bootstrap with Dynamic Resources

To become an xDS client, Envoy's bootstrap must contain dynamic_resources pointing to the control plane:

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
      connect_timeout: 1s
      type: STATIC
      http2_protocol_options: {}
      load_assignment:
        cluster_name: xds_cluster
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: control-plane.internal
                      port_value: 18000

The dynamic_resources block tells Envoy to fetch LDS and CDS through ADS (Aggregated Discovery Service) — a single gRPC stream carrying all resource types. The xds_cluster cluster connects Envoy to the control plane at control-plane.internal:18000.

#The xDS Subscription Flow

When Envoy starts, it opens a stream to the control plane and subscribes:

1. Envoy sends a subscribe for LDS.
2. The control plane replies with a listener list that references RDS.
3. Envoy subscribes to RDS and CDS.
4. CDS triggers EDS for each cluster's endpoints.
5. SDS is used when a listener or cluster uses a dynamic transport socket.

Whenever the control plane decides something changed, it sends an update on the same stream. Envoy applies that change live.

curl -s localhost:9901/config_dump | grep -A2 '"@type": "type.googleapis.com/envoy.admin.v3.*Config'
curl -s localhost:9901/config_dump?resource=dynamic

The endpoint config_dump?resource=dynamic shows only the resources received from the control plane — a quick way to tell which are static and which are dynamic.

#Integration with Control Planes

#Istio, Gloo, and Contour

Three popular control planes use xDS differently:

• Istio (istiod): manages the entire mesh config, including mTLS via SDS, and sends complete config to every Envoy sidecar.
• Gloo Edge/Gateway: uses Envoy as the gateway and translates API Gateway CRDs into xDS config.
• Contour: an Envoy control plane for Kubernetes, translating Ingress and HTTPProxy into xDS.

All these control planes write in the same "language": the xDS protocol that Envoy understands. Your skill at reading Envoy config applies everywhere.

#Building a Simple Control Plane

To understand the protocol more deeply, you can build a small xDS server yourself. One of the fastest ways:

go run github.com/envoyproxy/go-control-plane/examples/... 

The go-control-plane library provides an xDS server implementation in Go. With the examples from that repository, you can see directly how listeners, routes, and clusters are sent to Envoy as protobufs.

#Testing with Docker

To try dynamic config without building your own server, run Envoy with a dynamic config pointing to a dockerized control plane:

docker run -d --name envoy-xds \
  -v ~/envoy-lab/configs/xds-bootstrap.yaml:/etc/envoy/envoy.yaml \
  -p 10000:10000 -p 9901:9901 \
  envoyproxy/envoy:v1.31.0

The docker run command with an xDS bootstrap makes Envoy try to connect to the control plane. If it fails, look at the docker logs envoy-xds output to see the xDS stream and error messages.

#Debugging xDS Connections

#Finding Subscription Problems

When the control plane is unreachable, Envoy keeps running but can't load new listeners. The first check:

curl -s localhost:9901/server_info
curl -s localhost:9901/config_dump?resource=dynamic | head -20

The server_info command shows the last connection time with the control plane. If the last_updated field doesn't advance when config changes, there's a problem in the ADS stream — usually a wrong control plane address or gRPC protocol not enabled on the xDS cluster.

#Patterns to Watch Out For

Some common pitfalls when working with xDS:

• The xDS cluster must use HTTP/2, so don't forget http2_protocol_options.
• Resource names in config must match control plane names exactly.
• Don't mix dynamic and static resources with the same name.
• Version info is a big logging help; get used to setting version_info on control plane updates.

#Closing

Episode 9 opened the door to dynamic configuration: the five xDS services, Envoy as a client subscribing to changes, and integration with control planes like Istio, Gloo, and Contour.

Key takeaways:

• xDS consists of CDS, LDS, RDS, EDS, and SDS that reference each other.
• Envoy subscribes to resources via one ADS stream or separate streams.
• The dynamic_resources bootstrap replaces static config as the primary source.
• ADS allows listener, route, and cluster changes without restarts.
• Istio, Gloo, and Contour all speak xDS to Envoy.
• config_dump?resource=dynamic distinguishes dynamic resources from static ones.

In the next episode, episode 10, we'll discuss rate limiting and traffic control — the rate limit filter and external rate limit service, retry, timeout, and fault injection configuration, plus circuit breaking and resource limits.