(Redirecting our previous post here)
We are in the process of deploying sidecars for our service mesh using Istio v1.0.0 and had questions about some behavior we have noticed while configuring outgoing traffic.
To configure which outgoing traffic is intercepted by our sidecars, we have been using the “-i” (include IP ranges) parameter which controls this. We have seen the following behavior:
- With “-i” set to “*”, all outgoing traffic is funneled through the sidecar, eliciting 404s when attempting to access any external services (e.g. google). Adding service entries for these external services to allow access works. We confirmed that virtual service routing for internal services in our cluster also works as expected.
- With the “-i” parameter removed entirely, thereby soliciting the default configuration, all outgoing traffic bypasses the sidecar, allowing us to access external services freely within the application container without the use of ServiceEntries. However, virtual service routing does not appear to take place. Requests to hosts in the virtual service definition still go out to the internet, because they resolve to a public IP.
Our primary goal by introducing sidecars is to monitor service-to-service communication, so we’d like to configure the sidecars to intercept traffic to services internal to our mesh and allow all other traffic to external services to bypass the sidecar. We’d also like to avoid defining service entries for all external services that we access. Based on our investigation and the docs, it appears that the only way to do both of these is to set “-i” to include all of the IP ranges that the hostnames in the virtual service definition can resolve to.
We have the following questions:
- Is the virtual service behavior as outlined above expected given the configuration of outgoing traffic intercepted by the sidecar?
- Is using the “-i” option to specify the IP ranges of the virtual service hostnames required to support virtual service routing?
- Is there a way to configure the sidecar so that virtual service routing happens before the sidecar allows all other outgoing traffic?
Thanks for your time!