open-consul/agent/proxycfg
Freddy ec38cf3206
Fixup discovery chain handling in transparent mode (#10168)
Co-authored-by: R.B. Boyer <4903+rboyer@users.noreply.github.com>

Previously we would associate the address of a discovery chain target
with the discovery chain's filter chain. This was broken for a few reasons:

- If the upstream is a virtual service, the client proxy has no way of
dialing it because virtual services are not targets of their discovery
chains. The targets are distinct services. This is addressed by watching
the endpoints of all upstream services, not just their discovery chain
targets.

- If multiple discovery chains resolve to the same target, that would
lead to multiple filter chains attempting to match on the target's
virtual IP. This is addressed by only matching on the upstream's virtual
IP.

NOTE: this implementation requires an intention to the redirecting
virtual service and not just to the final destination. This is how
we can know that the virtual service is an upstream to watch.

A later PR will look into traversing discovery chains when computing
upstreams so that intentions are only required to the discovery chain
targets.
2021-05-04 08:45:19 -06:00
..
manager.go proxycfg: use rpcclient/health.Client instead of passing around cache name 2021-03-12 11:46:04 -05:00
manager_test.go connect: do not set QuerySource.Node 2021-04-27 19:03:16 -04:00
proxycfg.go Proxy Config Manager (#4729) 2018-10-10 16:55:34 +01:00
snapshot.go Rename "cluster" config entry to "mesh" (#10127) 2021-04-28 16:13:29 -06:00
state.go Fixup discovery chain handling in transparent mode (#10168) 2021-05-04 08:45:19 -06:00
state_test.go Fixup discovery chain handling in transparent mode (#10168) 2021-05-04 08:45:19 -06:00
testing.go Support Incremental xDS mode (#9855) 2021-04-29 13:54:05 -05:00