Optimizing Istio Control Plane Performance: Reducing xDS Latency, Improving Success Rate, and Shortening Startup Time

Background Ctrip has a mature micro‑service governance system, but global business expansion and hybrid‑multi‑cloud scenarios demand standardized, decoupled, and portable infrastructure, making cloud‑native architectures and Service Mesh essential. The team focuses on deploying Istio at scale, encountering severe control‑plane performance issues such as high latency, opaque push results, insufficient monitoring, and memory leaks.

Methodology and Goals The optimization process follows three steps: (1) map core control‑plane flows and scenarios, (2) derive SLOs from user requirements, and (3) establish testing and measurement frameworks to validate results.

2.1 Core Link and Scenario Mapping

The core link involves detecting changes to Kubernetes resources and promptly propagating them to the relevant Envoy proxies. Key scenarios include: (a) whether xDS push latency meets requirements as change volume grows, (b) success of configuration delivery to each Envoy, and (c) time required for control‑plane startup after release or failure‑restart.

2.2 SLO Definition

For 30k ServiceEntry and 30k WorkloadEntry, P95 xDS push latency < 3 s, P99 < 5 s.

Measure Istio configuration delivery success rate.

Reduce service startup time to ≤ 5 min.

2.3 Test and Metric Framework A comprehensive test suite was built to create, update, and delete resources (e.g., WorkloadEntry, ServiceEntry) concurrently. Monitoring points were added to collect request counts, end‑to‑end push latency, error rates, and to expose APIs for querying push results.

3.1 Optimizing xDS Push Latency

(1) Problem Analysis CDS and RDS push latency exploded under >30 k EnvoyFilters and >5 k VirtualServices, with P99 reaching minutes.

(2) Reducing EnvoyFilter Patch Complexity The original O(n²) nested loops for matching EnvoyFilters to clusters were replaced by a bucket‑map approach, turning the complexity to O(n). Multiple maps (service, subset, port) were built, allowing O(1) lookup of matching filters per cluster.

The optimization reduced latency from minute‑level to seconds for both CDS and RDS. Similar bucket‑map logic can be applied to LDS and EDS if needed.

(3) Additional xDS Optimizations On‑demand push, gateway data splitting, and VirtualService reduction further accelerated routing builds.

3.2 Success‑Rate Measurement via Merkle Tree

By exposing the ledgerVersion (root hash of a Merkle tree) in DiscoveryResponse and tracking acked versions from Envoys, the team built an API to query which Envoys have applied a given configuration, enabling precise success‑rate calculation.

These metrics also support safe pod deletion by waiting for all Envoys to ack before removing finalizers.

3.3 Startup Time Optimization By revising in‑memory data structures and map mappings, the control‑plane startup time was dramatically reduced, though detailed steps are omitted.

4 Results and Outlook

4.1 Performance Improvements (Istio 1.7.5)

ServiceEntry

WorkloadEntry

Before

After

30k

30k

CDS P99 > 40 s

CDS P99 < 5 s

30k

30k

RDS P99 > 1.5 min

RDS P99 < 5 s

30k

30k

API query > 10 s

API query < 20 ms

4.2 Future Work Continue enhancing the measurement system (e.g., capture timestamps via Merkle tree), increase queue concurrency, and contribute findings back to the open‑source community.

The article concludes with a recruitment notice for cloud‑native talent, which is not part of the technical content.