search

cilium / design-cfps

Repo to store Cilium CFP design docs
Apache License 2.0
21 stars 19 forks source link

Adding xDS Adapter CFP #14

Open robscott opened 5 months ago

robscott commented 5 months ago

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

DerekTBrown commented 5 months ago

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?

DerekTBrown commented 5 months ago

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:

mikemorris commented 5 months ago

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

youngnick commented 4 months ago

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.