Speeding up Istio: Our Journey Implementing Delta xDS - Aditya S Prerepa, Tetrate & John Howard
Channel: CNCF [Cloud Native Computing Foundation]
Date: 2021-10-30

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Speeding up Istio: Our Journey Implementing Delta xDS - Aditya S Prerepa, Tetrate & John Howard, Google

xDS is the way config is distributed to Envoy. Most of the ways the xDS API is implemented today (and in Istio) is through the state-of-the-world design. If one out of a thousand clusters changes and Envoy needs to know about the change, most control planes (including Istio) will send all of the thousand clusters to reflect the configuration change. On top of that, every configuration type is converged into one stream with Istio (ADS), which does not do the network any favors. This is the “quick and dirty” way, when logically, there should be no reason to send configuration when it hasn’t changed. This is what the delta xDS API aims to solve. Delta (or incremental) xDS is a variant of ADS/xDS, which has a different interface. If one configuration changes, that is the only configuration that will be sent. Istio is having quite a journey implementing delta xDS, sending only the “deltas” in configuration changes. Especially in a service mesh like Istio, which is the largest and most in-use mesh, there are quite a few caveats that need to be covered. This talk will be about the journey of Istio in implementing delta xDS, along with the expected benefits & apparent struggles that we had, along with guidance for future implementers of this amazing API.