Only consider virtual IPs for transparent proxies #10162
Conversation
Initially we were loading every potential upstream address into Envoy and then routing traffic to the logical upstream service. The downside of this behavior is that traffic meant to go to a specific instance would be load balanced across ALL instances. Traffic to specific instance IPs should be forwarded to the original destination and if it's a destination in the mesh then we should ensure the appropriate certificates are used.
github-actions
bot
added
theme/envoy/xds
|
🤔 This PR has changes in the |
| @@ -32,6 +32,8 @@ import ( | |||
| "github.com/hashicorp/consul/sdk/iptables" | |||
| ) | |||
|
|
|||
| const virtualIPTag = "virtual" | |||
There was a problem hiding this comment.
Would this be better off in agent/structs?
There was a problem hiding this comment.
If we don't need to export it now, I think it's desirable to be able to keep it locally unexported. We can always move it and export it later, but if we don't need to it's one less thing that has to be changed when we need to split up the agent/structs package.
|
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/361369. |
Initially we were loading every potential upstream address into Envoy and then routing traffic to the logical upstream service. The downside of this behavior is that traffic meant to go to a specific instance would be load balanced across ALL instances. Traffic to specific instance IPs should be forwarded to the original destination and if it's a destination in the mesh then we should ensure the appropriate certificates are used. This PR makes transparent proxying a Kubernetes-only feature for now since support for other environments requires generating virtual IPs, and Consul does not do that at the moment.
Initially we were loading every potential upstream address into Envoy
and then routing traffic to the logical upstream service. The downside
of this behavior is that traffic meant to go to a specific instance
would be load balanced across ALL instances.
Traffic to specific instance IPs should be forwarded to the original
destination and if it's a destination in the mesh then we should ensure
the appropriate certificates are used.
This PR makes transparent proxying a Kubernetes-only feature for now
since support for other environments requires generating virtual IPs,
and Consul does not do that at the moment.