cilium
Adding xDS Adapter CFP
This is a follow up from the original proposal doc I wrote and corresponds with https://github.com/cilium/cilium/issues/30235.
Note: I'm not quite sure how to fill out impacts and key questions yet, it's possible those will come more naturally with more review of this proposal?
/cc @joestringer @youngnick
Could you provide some more detail around where the proposed xDS Adapter would sit in the Cilium stack? I could see how this would inform some of the interface API design decisions.
In particular, I would like to hear your thoughts around how the xDS Adapter would interact with the embedded Envoy instance. For instance, does the xDS adapter proxy/cache requests from Envoy to an upstream server, or is Envoy communicating directly with upstream xDS servers?
One other thought: Would it make sense to explore an approach that supports only a single backend (rather than trying to reconcile between several sources). Basically:
- Cilium would have either a KVStore/Local API/xDS Mode
- There could be external tooling that would help migrate between modes (eg. an xDS implementation that reads from existing Cilium CRs).
Would it make sense to explore an approach that supports only a single backend
While https://github.com/cilium/cilium/issues/30283 is a separate proposal to build a full alternative xDS interface, my understanding is that the narrow scope of this proposal is part of the attraction, as it allows xDS to be used just where it provides a specific benefit, as @youngnick mentions in https://github.com/cilium/design-cfps/pull/14#discussion_r1464368619
In particular, I would like to hear your thoughts around how the xDS Adapter would interact with the embedded Envoy instance. For instance, does the xDS adapter proxy/cache requests from Envoy to an upstream server, or is Envoy communicating directly with upstream xDS servers?
The xDS adapter in this CFP is totally orthogonal to the built-in Envoy instance, except in so far as it would take endpoints from somewhere else, and make them available to as Cilium endpoints to be used in Envoy config like any other one. But that's a very indirect link, and code-wise they will be completely separate.
@robscott we now have statuses for CFPs https://github.com/cilium/design-cfps#status. Are you still trying to move this towards implementable or is it dormant for now?
FYI, there's an implementation submitted for reviews at https://github.com/cilium/cilium/pull/34484.
Next step on this CFP is a refresh from the latest developments, onus is on @robscott for the update. Marking draft until then.
@robscott with https://github.com/cilium/cilium/pull/34484 merged, would you mind updating this design doc for merging?