Spike: Evaluate xDS protocol for Istio Gateway integration

[shaneutt]

Objective

Validate that Praxis can deploy as an Istio Gateway using xDS for dynamic configuration. Produce a go/no-go recommendation with a concrete plan or documented blockers.

Supersedes the approach in #226. Istio supports a simplified xDS resource protocol for non-Envoy data planes, avoiding the full Envoy proto surface.

Background

Praxis uses YAML file config with ArcSwap hot-reload, sufficient standalone but unable to integrate with istiod.

Istio's xDS server supports non-Envoy proxies via standard delta ADS transport with a flat resource schema instead of Envoy's 2000+ proto files. Prior research confirmed istiod has a dedicated code path for this, translating Gateway API resources into types that map cleanly to Praxis's config model.

Deliverables

1. Validate Istio support maturity

• Confirm istiod handles Gateway, HTTPRoute, GRPCRoute, TCPRoute, TLSRoute via non-Envoy path
• Confirm node identity format and metadata are stable
• Determine maturity (alpha/beta/GA)
• Identify Gateway API conformance coverage

2. Prototype xDS connectivity

• KIND cluster with istiod
• Minimal pod connecting as a non-Envoy proxy, logging received resources
• Create Gateway + HTTPRoute, observe resources pushed
• Document which fields are populated vs. empty

3. Assess translation feasibility

• Map received resources to Praxis Config; identify gaps and mismatches
• Evaluate route match coverage
• Assess dynamic listener problem (Pingora run_forever()) — restart acceptable?
• Estimate complexity from real data

4. Identify blockers and risks

• Pingora dynamic listener binding
• Proto schema stability across Istio upgrades
• mTLS requirements for xDS connection
• Resource ordering guarantees

5. Go/no-go

• Go: refined plan with updated estimates
• No-go: blockers and alternatives