Request Routing based on Header

1,750 views
Skip to first unread message

Rama Rao

unread,
Nov 3, 2017, 9:41:10 PM11/3/17
to envoy-users
Hi,
Is there a way in Envoy to route a specific request to a given upstream cluster based on some request header? Our use case is to route all test requets to a test cluster based on request header set when in testing mode - basically test request overrides the request routing rule and points it to test cluster.

Thanks,
Rama

Rama Rao

unread,
Nov 4, 2017, 12:29:42 AM11/4/17
to envoy-users
I think this may help in this case.
https://github.com/envoyproxy/envoy/issues/199. Is that correct? Is there an example use of it some where?

Timothy Perrett

unread,
Nov 4, 2017, 6:35:07 PM11/4/17
to envoy-users

Rama Rao

unread,
Nov 4, 2017, 11:24:03 PM11/4/17
to Timothy Perrett, envoy-users
Thanks.. will try
--
You received this message because you are subscribed to the Google Groups "envoy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users...@googlegroups.com.
To post to this group, send email to envoy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-users/db2aed24-f28b-401b-bc20-5427e87e56f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rama Rao

unread,
Nov 6, 2017, 10:43:02 AM11/6/17
to Timothy Perrett, envoy-users
I have tried this. But looks like I need to pass "cluster_header" for every request. My goal was to only pass that header if it is a specific type of request for example a test request that should be routed to a test cluster.
So I tried with the following configuration
"routes": [
                   {
                      "timeout_ms": 0,
                      "prefix": "/grpc.sample.GrpcSampleService/",
                      "cluster_header": "test_cluster"
                    },
                    {
                      "timeout_ms": 0,
                      "prefix": "/grpc.sample.GrpcSampleService/",
                      "cluster":"service2"
                    }, 
]
So my assumption was , if the request has a header attribute "test_cluster", it should go to the cluster specified by "test_cluster" otherwise it should go to "service2" cluster. I thought it would match the first route and since it is not matched, it would fall through to the next route for the same prefix. However, it fails at the first route with 404 if test_cluster header is not specified.
How do you I achieve the case of if header is there go to cluster specified by header otherwise default to the next route? The way it is working, If I use cluster_header for one route definition of a prefix, I must use cluster_header to route to different cluster for the same prefix. So all requests to that prefix should have a cluster_header.

Thanks,
Rama

On Sun, Nov 5, 2017 at 8:53 AM, Rama Rao <ramarao...@gmail.com> wrote:
Thanks.. will try

On Sun, 5 Nov 2017 at 4:05 AM, Timothy Perrett <tper...@gmail.com> wrote:


On Friday, 3 November 2017 21:29:42 UTC-7, Rama Rao wrote:
I think this may help in this case.
https://github.com/envoyproxy/envoy/issues/199. Is that correct? Is there an example use of it some where?
On Sat, 4 Nov 2017 at 7:11 AM, Rama Rao <ramarao...@gmail.com> wrote:
Hi,
Is there a way in Envoy to route a specific request to a given upstream cluster based on some request header? Our use case is to route all test requets to a test cluster based on request header set when in testing mode - basically test request overrides the request routing rule and points it to test cluster.

Thanks,
Rama

--
You received this message because you are subscribed to the Google Groups "envoy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users+unsubscribe@googlegroups.com.

Matt Klein

unread,
Nov 6, 2017, 11:09:09 AM11/6/17
to Rama Rao, Timothy Perrett, envoy-users

Rama Rao

unread,
Nov 6, 2017, 11:30:03 AM11/6/17
to Matt Klein, Timothy Perrett, envoy-users
Ok. Thanks Matt. It works with out a cluster_header with just headers as per the below route definition

 "routes": [
                   {
                      "timeout_ms": 0,
                      "prefix": "/grpc.sample.GrpcSampleService/",
                      "cluster": "service2_v1",
                      "headers":[
                       {
                         "name":"test_cluster"

                       }
                      ]
                    },
                    {
                      "timeout_ms": 0,
                      "prefix": "/grpc.sample.GrpcSampleService/",
                      "cluster":"service2"
                    }
]

Rama Rao

unread,
Nov 9, 2017, 7:12:07 AM11/9/17
to Matt Klein, Timothy Perrett, envoy-users
One more question, is there a way to override host header based on some other header attribute so that that particular request goes to that host? We do not have prior info on this host - so we can not define a cluster for it
Thanks.. will try

To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users...@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-users/db2aed24-f28b-401b-bc20-5427e87e56f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "envoy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users...@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.

Matt Klein

unread,
Nov 9, 2017, 4:26:38 PM11/9/17
to Rama Rao, Timothy Perrett, envoy-users
No. All target hosts must be contained in a cluster and pre-defined asynchronously.

Again this is somewhat related to https://github.com/envoyproxy/envoy/issues/1606 which I'm probably going to tackle as my holiday programming project.

Thanks.. will try

To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users+unsubscribe@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-users/db2aed24-f28b-401b-bc20-5427e87e56f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "envoy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users+unsubscribe@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.

Rama Rao

unread,
Nov 9, 2017, 11:03:35 PM11/9/17
to Matt Klein, Timothy Perrett, envoy-users
Thanks. Will follow that issue :-)

Dan Richelson

unread,
Apr 27, 2018, 5:42:57 PM4/27/18
to envoy-users
Hi, I work with Rama and have picked up this task. We're currently still looking for a way to route a request to an individual host + port based on a header value. I see that the above-referenced issue:  https://github.com/envoyproxy/envoy/issues/1606 is still open. I'm wondering how other Envoy users are solving problems like this?
Thanks
Dan
Thanks.. will try

To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users...@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-users/db2aed24-f28b-401b-bc20-5427e87e56f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "envoy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users...@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.

Mark McBride

unread,
Apr 27, 2018, 7:54:46 PM4/27/18
to Dan Richelson, envoy-users
We do this by creating a broad service pool that does have knowledge of all hosts, but define default rules to limit "prod" traffic to hosts that match a given label selector. What's the concern with adding the new host to the cluster?

Dan Richelson

unread,
May 2, 2018, 2:29:29 PM5/2/18
to envoy-users
Mark- Do you mean k8s label? We're running in a mixed environment, so we can't rely on k8s labels. 

The problem we're trying to solve is this one: An ephemeral service spun up by an integration test system should be reachable via a header override. Basically we want forward proxy semantics for special one-off cases. We don't announce these ephemeral services and really prefer not to make a cluster for each ephemeral service, but they could go in some ad hoc cluster that serves this purpose. One approach is that envoy could map requests from one cluster to the 'ephemeral' cluster and dynamically add the endpoint based on the header contents.

Mark McBride

unread,
May 2, 2018, 2:36:00 PM5/2/18
to Dan Richelson, envoy-users
This information is provided by EDS, see https://www.envoyproxy.io/docs/envoy/v1.6.0/api-v2/api/v2/endpoint/endpoint.proto#envoy-api-msg-endpoint-lbendpoint. You can set whatever labels you want in the xDS server (or file). We do map k8s labels to endpoint metadata (as well as consul tags, EC2 tags, etc.), but you can do that a variety of ways.

If you have explicit subset rules no where production traffic is going, then having a header redirect to this integration test system is totally fine.

We effectively do this for our front end development workflow (using our product). Developers submit a PR, build a container and deploy it to k8s, with labels `stage=dev, version=<git branch>`. Our routing rules restrict customer traffic to only endpoints labeled with a stage of prod and an explicit version. We also have a cookie and header override to direct traffic to a specified version, regardless of stage. Code reviewers can use this to go look at the PR running live in prod, as they review the code for the implementation.

   ---Mark

Reply all
Reply to author
Forward
0 new messages