IssueTracker

Hello Kévin

Thank you for contacting Google Cloud Platform Support. I understand you are having an issue with internal load balancing and I will do my best to advise you.

Internal load balancers are regional resources, the scope of an internal TCP/UDP load balancer is regional, not global. This means that an internal TCP/UDP load balancer cannot span multiple regions. Within a single region, the load balancer services all zones. [1]

A feature request exists to enable an internal load balancer which can handle requests from multiple regions[2]. But I can neither provide you with an ETA for its implementation, nor a guarantee that it will ever be supported. If you would like to create your own feature request, follow the link to Google issue tracker to search or create feature request [3].

Your VMs are able to talk to each other from one region to another as they are connected through the same VPC. Resources within a VPC network can communicate with one another using internal (private) IPv4 addresses, subject to applicable network firewall rules.[4] However, for ILB the behaviour is handled differently due to the regional nature of the ILB(s).

The reason VM instances attached to a network with a specific address mask getting assigned IP with /32 mask is a design requirement of GCP. However, let me explain why VM instances are assigned with the /32 mask on Google Compute Engine (GCE). Please note that the /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communication is established, and everything works.

In addition to that, network masks are enforced at the network layer, not the host layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway), this might further clarify why VM instances are assigned with a /32 netmask, when they are attached to a subnet, for example, /24 mask.

I hope that makes things clearer for you. If you have any other questions or concerns about your issue, please do not hesitate to contact me by replying to this message. I will be more than happy to help at that time.

[1]ILB Scope: https://cloud.google.com/load-balancing/docs/internal/#protocols_scheme_and_scope
[2]Feature Request for multi-region ILB: https://issuetracker.google.com/111021512
[3]Create and Search feature requests: https://cloud.google.com/support/docs/issue-trackers#search_and_create_feature_requests_by_product
[4]VPC Specifications: https://cloud.google.com/vpc/docs/vpc#specifications

Thanks for your quick reply on ILB and thank you also for details on networking on gcp.

I hope that this feature request https://issuetracker.google.com/111021512 will be considered :).

I am surprised that it has been designed like this because it's a pretty big drawbacks compared to AWS for example.

Do you know if there is another solution for me to interconnect local service to another region except create loadbalancer in a dedicated instance ?

Thanks in advance,
Kévin
 

I have the exact same feature request to access ILB from multi regions. It would be great if Google can prioritize this feature. Thanks.

Hi, please take a look at my update to the public feature request:

https://b.corp.google.com/issues/111021512#comment37

You'll be pleased to note that GKE 1.16 allows you to annotate a service of type LoadBalancer such that it is both internal and globally accessible.  We can close out this issue now.

Unfortunately this is still not resolved as of beta 2

@7 So would you like it to be more “jumpy” and that it follows the upward movement of the finger a little more? I seem to have problems understanding your issue. :/

Yes, once you let go of the screen it currently instantly loses all momentum and collapses into the app icon; this was not the case in all other versions of android including android 12. I believe this is the result of some changes to multitasking.

Sorry for the late response

@comment#9 OK, I got it now! I think it's, because of an earlier very bad animation that could happen when swiping up to close apps too strongly. It looked like absolute rubbish. So I decided to make a bug report about it and Google seemingly implemented the fix, which causes the now less irritating, but still not optimal closing animation momentum.


It's issue 194684696. I'm not sure if it's public, though... The issue is called "Minimizing apps too fast via gesture is badly animated".


This is pretty ironic, I guess. I was pleased with the change. But now you aren't anymore! But, trust me, you wouldn't want to see what was possible before this build...

I kind of doubt it though, with the amount of bounces and momentum conservation that is part of Material Design 3 it seems strange to just remove all momentum of a prominent animation just to fix a bug with swiping too much. Of course I don't know for sure, but I feel like this is still unintended, and that the intended solution still has momentum but is capped past a certain point to avoid the super fast collapse from off screen you'd get before if you swipe too much. I remember versions like android 11 had a much more toned down momentum conservation, but they still had some

Thank you for reporting this issue. We’ve shared this with our product and engineering team and will continue to provide updates as more information becomes available.

The issue reported here is working as intended.