Envoy 1.18+ Drops v2 xDS API Support: Compatibility Implications for Control Planes

Envoy 1.18 removed support for the v2 xDS API, requiring all configuration resources to conform to the v3 schema. Control planes that still emit v2 resources cause Envoy to reject the configuration at startup with a fatal version‑mismatch error, preventing the proxy from starting. This change eliminates any automatic fallback or migration mode, meaning that a mismatch between control‑plane output and Envoy version results in an immediate exit.

Operators planning upgrades must ensure that the control plane is already serving v3 resources before deploying Envoy 1.18+ sidecars, otherwise rolling upgrades cannot proceed without downtime. The lack of a translation layer raises questions about feasible upgrade paths and whether any interim compatibility mechanisms exist.

Which strategies allow a control plane to transition to v3 output without requiring a simultaneous Envoy upgrade? Are there any supported mechanisms, such as feature flags or proxy‑side adapters, that could enable Envoy 1.18+ to tolerate v2 resources during a migration window?