Day 16: Envoy Proxy — xDS API

Phase 3 · Jul 16, 2026

Agenda (2–3 hours)

• Read (45 min): Envoy xDS API documentation (CDS, EDS, LDS, RDS); Envoy architecture documentation
• Study (45 min): Trace a request from Listener → Route → Cluster → Endpoint in the Envoy configuration model
• Practice (45 min): Write a static Envoy bootstrap config (YAML) that routes /api/users to one cluster and /api/orders to another; test with curl
• Challenge (30 min): How does Envoy handle a cluster member becoming unhealthy? Trace the Outlier Ejection algorithm

xDS: The Universal Data Plane API

xDS (x Discovery Service) is a family of gRPC-based APIs that control planes use to configure Envoy:

These compose: LDS references RDS; RDS references CDS; CDS references EDS.

Static Configuration Example

static_resources:
  listeners:
  - name: listener_0
    address: { socket_address: { address: 0.0.0.0, port_value: 8080 } }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          route_config:
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match: { prefix: "/api/users" }
                route: { cluster: users_cluster }
              - match: { prefix: "/api/orders" }
                route: { cluster: orders_cluster }
  clusters:
  - name: users_cluster
    load_assignment:
      cluster_name: users_cluster
      endpoints:
      - lb_endpoints:
        - endpoint: { address: { socket_address: { address: users-svc, port_value: 8080 } } }

HTTP Filters

Envoy HTTP filters run on every request through a filter chain:

http_filters:
- name: envoy.filters.http.jwt_authn       # Validate JWT
- name: envoy.filters.http.rbac            # Role-based access control
- name: envoy.filters.http.fault           # Fault injection (testing)
- name: envoy.filters.http.retry           # Retry policy
- name: envoy.filters.http.router          # Must be last: route to cluster

Filters are chained in order; each can inspect, modify, or reject the request. This is how Istio injects mTLS and telemetry — as filters, not code changes.

Health Checking and Outlier Ejection

Active health check: Envoy sends periodic health check requests to each endpoint.
Passive outlier ejection: Envoy monitors error rates and latency per endpoint:

• 5 consecutive 5xx responses → eject endpoint for 30 seconds
• Reconnect after ejection interval; if still failing → extend ejection

These happen at the data plane level — no control plane round-trip needed.

Key Takeaways

• xDS is a gRPC-based API family for dynamically configuring Envoy
• Listener → Route → Cluster → Endpoint is the request path model
• HTTP filter chains are where mTLS, JWT validation, retries, and tracing are applied
• Outlier ejection provides passive health monitoring at the data plane

Tomorrow: Istio architecture — how istiod orchestrates the mesh.