Can we Geo Target Backends with GCP's L7 HTTPS Load Balancer based on User Geography?

Question

I have three different GKE clusters distributed across three different regions. All three clusters are behind three different L7 HTTPS Load Balancers. The services in all three clusters are accessible via three different URLs:

www.us.someservice.com
www.eu.someservice.com
www.asia.someservice.com

All three cluster have some services that are region specific. For example: an user from US cannot full fill some particular requests from services in EU or ASIA.

Our current requirement is to use only one L7 HTTPS LB and one domain www.someservice.com for all three regional clusters.

However we want to geo target the incoming requests. Let's say an user from US hits www.someservice.com, then their request should be routed to the GKE cluster in the US region and we want to have this pattern for all other users from different region (as shown in the image below).

Is there a way to make this routing possible in the L7 HTTPS LB in GCP? I was going through the URL Mapping, Host and Path rules but couldn't fins anything related to geo targeting requests!

Answer 1

By default, the load balancer will automatically route the request to the closes region:

https://cloud.google.com/load-balancing/docs/https#cross-region_load_balancing

it uses a global external IP address and can intelligently route requests from users to the closest backend instance group or NEG, based on proximity. For example, if you set up instance groups in North America, Europe, and Asia, and attach them to a load balancer's backend service, user requests around the world are automatically sent to the VMs closest to the users,

Answer 2

With Global HTTP(S) Load Balancers, traffic is distributed to the closest backends. The traffic distribution is managed by Google (you cannot specify send RU traffic to ASIA).

Answer 3

It's not possible as described here in the limitations

Combining multiple Ingress resources into a single Google Cloud load balancer is not supported

You can maybe build something manually, but I can't guarantee the evolution, the latency and the reliability of this manual (i.e. out of kubernetes ingress controler) configuration.