estudy 한국어/English

xDS Protocol, Control Plane (Istio Pilot)

505 단어·3 분·원문(.md)

The core mechanism that enables Istiod (Control Plane) to orchestrate thousands of Envoy proxies (data plane) seamlessly is the xDS API. It is thanks to this protocol that Envoy can change its configuration in real-time without requiring restarts.

xDS Protocol #

xDS is an abbreviation for Discovery Service (I'm not sure why it's not just "DS," but adding an "x" makes it cool, like Elon Musk or a Nintendo model, anyway). It is a collection of APIs that Envoy uses to dynamically receive its configuration values from external Istiod.

  • LDS (Listener Discovery Service): Which ports to open and listen on, L4 filter chain configuration for listeners
  • RDS (Route Discovery Service): Where to send requests, virtual hosts, path-based routing rules
  • CDS (Cluster Discovery Service): What is the destination service group? In terms of roles: service names, load balancing policies, TLS policies, etc.
  • EDS (Endpoint Discovery Service): What are the actual IP addresses of the destination, list of actual pod IPs for load balancing

LRCE refers to the four main components we previously learned about in Envoy.

The reason for this hierarchical structure is that EDS (Endpoint) changes very frequently whenever pods are created or deleted. In contrast, LDS (port) does not change (Service). The purpose of separating them is to efficiently propagate only the changed parts. This is also known as Incremental xDS. Super cool.

Eventual Consistency: Configuration Propagation Lag #

When a user executes k apply -f virtualservice.yaml, there is a short time lag until it is reflected in all Envoys.

  1. Config Watch: Istiod detects configuration changes from the Kubernetes API server
  2. Push: Istiod analyzes the changes and sends xDS updates to all relevant Envoys via a gRPC stream.
  3. Ack/Nack: Envoy applies the configuration and responds with success (Ack) or failure (Nack).

In large-scale clusters with thousands of nodes, this process can lead to eventual consistency issues, and it's important to understand the fleeting moments when old and new configurations coexist during propagation.

Sidecar Injection #

How does it intercept traffic coming into a pod? The secret to Envoy being able to intercept all packets without executing application code lies in iptables manipulation.

  • Mutation: When a pod is created, the Istio webhook automatically injects the istio-proxy container and the istio-init container.
  • init-container: istio-init sets up iptables rules within the pod's network namespace.
  • interception: By these rules, all TCP traffic entering and exiting the container is forcibly redirected to Envoy, which is listening on ports 15001 (outbound) and 15006 (inbound).

Debugging #

If you've applied a configuration but it's not working, you need to check if the Control Plane's intent and the Data Plane's actual state are consistent.

Check Status: istioctl proxy status

  • SYNCED: Istiod and Envoy configurations match
  • STALE: Istiod sent the configuration, but Envoy is still applying it or hasn't responded

Dump Actual Configuration: istioctl proxy-config <type> <pod-name>

  • clusters: Check the list of backends known to Envoy
  • routes: Verify if routing rules were created as intended
  • endpoints: Check the list of IP addresses where actual traffic can go
DevOps/xds.md