-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X-Request-Id gets overwritten by Istio (Envoy) #10875
Comments
Found the similar behavior with deployment on aws using kops. The reason was that by default kops uses 10.64.0.0/10 for pod network, which is not compatible with https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#x-forwarded-for For your case i think the problem is quite the same:
So if you want envoy to not overwrite your xff and x-request-id you have to set use_remote_address=false and ensure that your nginx ip address is in RFC1918 or RFC4193 |
Thank you for your answer @gerasym ! That's what we're trying to do here: setting |
We are running in the same problem and cluster behaviour when setting the |
We hit the same problem after the decision to generate x-request-id on the client side. This approach enables timed out requests tracing having client generated request id. |
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions. |
I believe what is needed is a way to set Envoy's |
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions. |
We are facing the same problem, we are going to map that header to another that does not get removed by the Istio ingress... We are looking forward for another solution because we really need that for idempotency purposes huraay PSD2. |
If you define the Trace Span template in Istio you can define Example:
You can find more info in the Istio docs in the following link. |
ping, and |
Repeating my comment from #12549: I was able to preserve the external request id with the following EnvoyFilter. I'm running Istio 1.3.0.
Thanks to envoyproxy/envoy#7140 |
Thanks @cdmurph32 . Also, folks on this thread, very sorry about the trouble caused by our settings in the gateway - but these were meant as a general purpose setting. The whole reason for creating the new EnvoyFilter API (not the old one specified in the OPs comment) is to overcome some of the issues. As @cdmurph32 points out, with the new API, you can customize the generated configuration to your hearts content. If there are deficiencies in the API (like being unable to set certain fields in the generated config), please file an issue and we would be happy to address them. |
Is there any guide to config |
Describe the bug
When implementing request tracing in our clusters we noticed that
x-request-id
s generated by nginx get overwritten by the Envoy proxy.Our internal nginx gateway(outside the k8s cluster) proxies requests to Istio's
31380
port with all the request headers, thex-forwarded-for
with nginx's ip appended and a generatedx-request-id
by nginx gateway.Having checked Envoy's header sanitizing we are trying to modify the proxy configuration for our Istio ingress and egress gateways so requests coming from our nginx gateway are recognised as internal requests and nginx, Istio and Envoy use the same
x-request-id
for a request and can be traced easily. Once we get them right, we'll move onto the sidecar proxies.After having a play with
EnvoyFilter
s we can see that the specified filter gets appended to existing ones and can be seen with:When issuing the command we see that another filter is created next to the default
http_connection_manager
.We can also see that the config option
use_remote_address
for envoy in the ingress gateway is set totrue
by Istio.(couldn't find anything in the repo that'd set it though)Is there a way to amend the ingress gateway proxy's
http_connection_manager
filter config without creating a new one with the same name with custom k8s objects provided by Istio or is there only a more messy way to modify the envoy config? We've found theenvoy-rev0.json
under/etc/istio/proxy
inside the ingress gateway container, but it looks a bit different to the output of theistioctl proxy-config listeners
command so we suppose envoy gets its configuration from somewhere else (too?).Expected behavior
Envoy proxy configuration is easily configurable via Istio objects. Requests coming from an internal nginx gateway outside the k8s cluster can be recognised as internal requests so
x-request-id
s don't get overwritten.Steps to reproduce the bug
Apply the following manifest to modify the envoy config used by the ingress gateway:
use the following to see the listeners:
Check the proxy-status and see its output:
The pilot's
discovery
container doesn't log out any warnings.Observe that requests to your cluster hang and report a
stream timeout
after a while.Version
Installation
istio_version=1.0.5
tracing_enabled=true
trace_sampling_rate=5
istio_proxy_include_ip_ranges=our internal nginx ip address
Environment
Kubernetes cluster running on VMs hosted internally.
Cluster state
istio-dump.zip
The text was updated successfully, but these errors were encountered: